Week2_Design_ender

.pdf

School

University of Toronto *

*We aren’t endorsed by this school

Course

106

Subject

Mechanical Engineering

Date

Apr 3, 2024

Type

pdf

Pages

Uploaded by AmbassadorFang201

Week2_Design_ender January 21, 2022 0.1 APS106 Lecture Notes - Week 2, Lecture 3 1 An Engineering Design Process for Programming As you have seen in APS111/112, a key part of engineering is the design of objects, processes, and systems. From an engineering perspective, programming is the design, implementation, testing, and documentation of a piece of software that solves a particular problem. The software might be part of a larger system (e.g., the avionics software of an aircraft, the accounting or human resources software of a business), but it represents the solution to a design problem (or part of a design problem). We will therefore approach programing as an engineering design process and adapt the process you have already seen. 1

1.1 An Engineering Design Process (for programming) 1.1.1 1. Define the Problem Develop a clear and detailed problem statement. Be clear on what needs to be done. Sometimes the problem will be easy enough (especially as you are learning programming) that the initial problem statement given by the client/prof is suffcient. More often, the problem is complex enough that forming a complete, explicit definition is a challenge itself and sometimes (even, often) the client doesn’t really understand the problem him/herself. In such cases, research and iteration with the client is necessary. 1.1.2 2. Define Test Cases Work out specific test cases for which you know the answer. This will help in the solidifying the problem definition and provide you with tests once you have working code. Try to cover a reasonable span of possible cases that may come up. Think about strange cases that might break the code. Think about reasonable measures of effciency, speed, and memory size. 1.1.3 3. Generate Many Creative Solutions Think about solutions and write them down. Try to be as creative as possible. A “solution” at this stage is two things: 1. An Algorithm Plan : a list of a few (from 4 or 5 to a dozen) steps that your algorithm will execute to solve the problem. These are high-level steps that can correspond to many lines of code. In real projects, these steps will themselves be subject to the design process (i.e. they will in turn be broken down into sub-steps perhaps may layers deep). 2. A Programming Plan : a list of steps you will take in programming the algorithm. Some- times this will be the form of programming, testing, and debugging each of the algorithm steps in order. But it doesn’t have to be that way. Especially for larger systems, the al- gorithm steps may be designed and implemented by different people in parallel or you may choose to program, test, and debug the hardest step first to make sure you understand the problem enough. Or you may decide to do the easiest steps first. The point is that you program not by trying to write all the code at once and then hoping it all works. Rather, you divide it up into a number of steps and make sure each step is implemented and works as you proceed. 1.1.4 4. Select a Solution Evaluate the algorithm and programming plans you have generated. Does it appear that this solu- tion will truly solve the problem? You may write some prototype code to understand if particular design ideas will work. Pick the best solution. If it is good enough, continue to Step 5, otherwise return to an earlier step (maybe even Step 1 as you have uncovered new parts of the problem definition). 1.1.5 5. Implement the Solution Follow your chosen programming plan to implement the code. For each step in your programming plan, you should ensure that the code is working: it runs some “sub-tests” correctly. Even though 2

it doesn’t solve the whole problem, it should produce intermediate results that you can verify are correct. If it doesn’t, you should debug it before moving onto the next step. Implementation in- cludes the documentation in the code: functions should have well-written docstrings and comments should be used – it is better to over-comment than under-comment. 1.1.6 6. Perform Final Testing Evaluate the solution against the test metrics, ensuring everything is in order. If the solution is not satisfactory, you need to either return to Step 5 to debug the code or return to Step 1 to develop a better understanding of the problem. 1.2 Final Remark: Design is Iterative The above seems very proper and linear. Real programming isn’t. Real programming is a but chaotic because you are creating something that doesn’t yet exist and figuring out how to solve the problem as you go. Having some structure will help you not get lost. One of the most essential parts of all engineering design processes is iteration. Programming is no different. In fact, iteration may be even more important in programming because it is relatively inexpensive to write prototype code (compared to, say, building a prototype engine). This means that steps in the process are repeated over and over, in a loop. You might realize that you need to jump back to an earlier step because you missed a key requirement or because you mistakenly thought that you understood how to program a particular step. Each iteration brings with it an increased level of understanding of the problem that deepens your knowledge. Iteration may allow you to conceive solutions that were not initially apparent. 2 Design Project # 1: Forward Kinematics 2.1 Problem Background If you have a robotic arm (e.g., the Canadarm) with joints, it is important to be able to calculate where the end of the arm (i.e., the part usually used for picking something up) will be based on the characteristics of the arm (e.g., the length of the components) and the angles of its joints. Forward kinematics is the use of the kinematic equations of a robot to compute the position of the end of the arm (end-effector) from specified values for the joint parameters. Forward kinematics is 3

used heavily in robotics, computer games, and animation. 2.2 1. Define the Problem Given a robotic arm with two degrees of freedom (see above diagram), determine the position (x,y) of the effector given the component-arm lengths and joint angles. We need to find the x and y coordinates of the end of the arm. Those coordinates will obviously depend on the location of the base of the arm. And so a relevant question to the client is if we can define our own coordinate system or if there is a larger system that this arm is part of. Let’s assume that we can define our own coordinate system. Something to think about: how expensive will it be if this assumption is wrong? Will we have to throw away all our work and start again? Or is there likely to be an easy way to take a solution with a fixed coordinate system and reuse it in an externally specified coordinate system? 2.3 2. Define Test Cases 2.3.1 Test Case 1 len1 = 1, len2 = 1, ang1 = 60, ang2 = 30 End effector position x = 0.5, y = 1.87 2.3.2 Test Case 2 len1 = 1, len2 = 1, ang1 = 60, ang2 = -30 4

End effector position x = 1.37, y = 1.37 Where do these test cases come from? Either the client gives them to you or you have to figure out from first principles (or research) how to calculate the answers by hand. 2.4 3. Generate Many Creative Solutions Based on simple physics and math, we can obtain the ( ∆ x 1 , ∆ y 1 ) position of the end of the first component arm. ∆ x 1 = L 1 cos ( θ 1 ) (1) ∆ y 1 = L 1 sin ( θ 1 ) (2) Then we can obtain the ( ∆ x 2 , ∆ y 2 ) position for arm 2. ∆ x 2 = L 2 cos ( θ 2 + θ 1 ) (3) ∆ y 2 = L 2 sin ( θ 2 + θ 1 ) (4) Finally we can find the (x,y) position by adding up the components. x = ∆ x 1 + ∆ x 2 (5) y = ∆ y 1 + ∆ y 2 (6) These steps nicely form an Algorithm Plan 1. Get arm lengths and angles from the user. 2. Calculate (x,y) position of the end of arm 1. 3. Calculate the (x,y) position of the end of arm 2. 5

Your preview ends here

Eager to read complete document? Join bartleby learn and gain access to the full version