ADAMS仿真实例

A Report Submitted in Partial Fulfillment of theRequirements for SYDE 461ContentsContents ii Table of Figures iv 1Project Summary 11.1 Problem statement (1)1.2 Phase 1 goals (2)2Design Process 4 3Results Achieved 83.1 PCB modifications (8)3.2 Mechanical issues resolved (9)Limit switches (10)Hip motor encoders (11)3.3 Gait research (12)3.4 ADAMS simulation (13)3.5 Communication testing (15)4Future Plans 175Tentative Schedule 19 Appendix A C3 Meeting Minutes 22 C3 meeting #1 (22)C3 meeting #2 (25)C3 meeting #3 (29)Table of FiguresFigure 1: Black-Box System (4)Figure 2: Detailed System Diagram (5)Figure 3: Limit Switch Placement (10)Figure 4: Hip motor encoder (11)Figure 5: ADAMS model of Hexplorer (14)1Project SummaryHexplorer is an evolutionary project intended to research and develop a small, six-legged, autonomous walking robot. The project encompasses all design areas required to make a robot move, including Printed Circuit Board (PCB) design, mechanical design and walking algorithms. Since its initial conception in 1996, the Hexplorer project has seen much change and several improvements.The present Hexplorer configuration is composed of a circular body with six legs mounted equidistant from each other around the circumference of the body. Each leg has three degrees of freedom and therefore requires three separate DC motors to articulate i ts motion. Each leg has its own “leg” PCB with an integrated DSP that controls the leg‟s three motors. The overall motion of the robot is achieved using a single “brain” board, also with an integrated DSP, responsible for sending commands to each of the individual leg boards.1.1Problem statementAs of September 2002, Hexplorer was incapable of autonomous motion. Only two of the six legs were functional, and furthermore, the legs movements were completely controlled by the leg boards rather than beingdirected by the brain board and actuated by the leg boards. Since improvements had recently been made to many of Hexplorer‟s subsystems including a complete re-design of the legs and the integration of new DSPs on all the circuit boards, it was decided that only minor changes would be needed to be made to get the robot to walk. Thus, the problem facing this year‟s design group was to fix any and all mechanical and software problems with Hexplorer, which would allow the robot to walk.The problem statement for this project is as follows:To better understand the intricacies involved in a locomotion machine, and to experiment with sophisticated GAIT algorithms, the Hexplorer 2002 team will remedy any problems with the existing robot, to allow it to autonomously navigate an even surface.1.2Phase 1 goalsIt was decided to have all mechanical and circuit board issues with the robot resolved by December 2002. This would leave the team to implement and design advanced walking algorithms for the robot during the following term.After careful investigation it was shown that to advance Hexplorer to a level where it could be used as a gait-testing platform would require three major tasks.1.Understand and correct the problems with the PCBs responsible forcontrolling Hexplorer‟s movement.2.Repair any mechanical issues preventing the legs of Hexplorer frommoving – including limit switches and motor encoders.3.Research gait algorithms and create a simulation of Hexplorer toallow for designing and testing of these algorithms without damage to the actual robot.With these detailed goals in mind, the team set out to create a sound research platform that could later be used to develop and test complex and autonomous walking gait algorithms.2Design ProcessSince the principal problem f acing this year‟s Hexplorer team was that the robot would not move; a thorough systems approach was required. The team, having no previous experience with this robot, thought of this problem as a …black box‟. Inputs were fed into the system, but nothing was being returned. With detailed research and analysis, this …black-box‟ was subsequently broken down into smaller, recognizable components. Figure 1 shows the original problem facing the Hexplorer 2002 design team.‘BLACK-BOX’Figure 1: Black-box systemThe first step to recognizing the underlying problems was to separate the problem into smaller, more manageable components. The team worked together with the supervisor to identify the major components limiting the motion of Hexplorer. From information passed on by previous Hexplorer teams, and rigorous testing, the team was able to isolate the system components shown in Figure 2.‘BLACK-BOX’Figure 2: Detailed system diagramUsing Figure 2 as a guide, the main areas for malfunction were identified. The possible problematic areas are circled on the diagram. The team was next able to focus its efforts on investigating the following situations.The first problem with the robot was that seven circuit boards were not all in perfect working order. From the strictly hardware perspective, a board was considered functional if the board was able to 1) download code and 2) run the code. Unfortunately, none of the boards were able to download code. The previous Hexplorer team had labeled some of the circuit boards as either “Working” or “Not Working”, but they did not indicate why the “Not Working” boards were not working. The problem with to downloading code could have been localized in either the circuit board DSPs, the other components on the board, of the method used to download the code. Thesolution strategy for this problem involved isolating the problem area and resolving the issue.The second problem with the robot was that hip encoders were apparently not working. This problem could be attributed to either the shaft not being connected to the encoder, the encoder was not providing a signal to the PCB, or the PCB was not properly interpreting the signal. As with the first problem, the solution strategy involved isolation the problem area and resolving the issue.The third problem involved the four limit switches on each of the legs. Some of the limit switches were missing, and furthermore, not all the limit switches were guaranteed to be operational. Therefore, each limit switch would have to be tested and the missing and faulty limit switches would have to be replaced.The fourth and final identified problem involved the communication between the brain board and the leg boards. Although the foundations for this communication have been implemented in both the leg and brain DSP code, the test programs provided by the previous group did not involve the brain specifying foot locations to each of the legs. The most that the previous group was able to accomplish in terms of this communication was a simple pinging program between the brain and the leg. Therefore, thecommunication code in both the leg and the brain would have to be studied, tested, and modified if necessary, and then a communication scheme would have to be designed and implemented into both the leg and brain test programs.3Results AchievedThrough valuable research and hard work, the team was successfully able to address the predefined term goals. Cooperation of team members throughout the design process was the key to success for this phase of Hexplorer‟s development.3.1PCB modificationsAt present, all seven circuit boards are now downloading code and running code successfully. The first problem with the boards was that the method to download the code was incorrect. As the program code is to be downloaded to the Flash, the Flash Programmer tool should be used to download code. Furthermore, the reset button on the boards had to be depressed while the Flash Programmer tool was downloading code. This information was obtained by contacting the previous group.However, even in using the correct method, the seven boards were still not downloading code correctly. After much testing and research, it was determined that the problem involved the Flash p rogrammer‟s clock frequency. The clock that is used to program the DSP is provided by a small circuit external to the DSP. The Flash programming utility is set to expect a certain frequency. For the downloading of code to work correctly, these twofrequencies should be identical. However, it was found that the two frequencies were quite far apart: the clock frequency on the DSP was 80MHz while the Flash Programmer was expecting 30MHz. To resolve this issue, software parameters in the Flash Programmer were modified so that both the clock frequency on the DSP and the frequency expected by software were both 20MHz.After resolving this issue, six of the seven boards were now functional, but there was still one leg board that did not download code. Considering that the malfunctioning board was identical to the other leg boards in design, it was determined that the problem with the board was component related. Some resistors and capacitors that were known to be problematic were first replaced, but the board still was not functional. Finally, it was decided that the DSP had to be replaced. Once the new DSP was soldered onto the board, the board functioned correctly.3.2Mechanical issues resolvedFixing the minor mechanical problems of Hexplorer involved primarily the selection and purchasing of additional limit switches. However, it was also necessary to check that the encoders for the hip motors were workingproperly. Initially there was some skepticism on the reliability of these devices, but they were proven to be working normally.Limit switchesEach leg of the robot requires four limit switches. Figure 3 shows there is one limit switch for the hip, and one for each leg motor. Although not yet attached, eventually one limit switch must be placed near the robot foot.Figure 3: Limit switch placement When the team began working with Hexplorer in September, numerous limit switches were either broken or missing. Some additional hardware was also required to attach the limit switches to the legs. Using the existing limit switches as a guide, more switches were ordered online from an electronics supplier called DigiKey. Some price comparisons were performed topurchase the required switches at the lowest price.Leg LimitSwitchesHipAlthough a seemingly trivial problem of purchasing components, the team found it a valuable learning experience to purchase these limit switches from a recognized supplier. The team conversed with technical representatives at DigiKey to ensure the proper parts were ordered, and in doing so learned important information about electronic components.Hip motor encodersTo ensure that the hip motors were rotating the appropriate amount, it was decided to check the effectiveness of the hip encoders. Figure 4 shows the placement of the hip encoders, placed below the hip joint.Hip MotorEncoderFigure 4: Hip motor encoderBecause the legs of Hexplorer sporadically did not rotate the desired amount, it was suspected that the hardware responsible for counting the revolutions of the motors was faulty. The team set up a simple test to checkif in fact the encoders were malfunctioning. To do this, one of the legs was run through a typical homing sequence, and the values of the encoders were measured using an oscilloscope. After several tests achieving desired results, it was concluded that there was no problem with the hardware. Any discrepancies must be caused by the software responsible for rotating the legs.The team found this testing exercise a valuable learning experience primarily because it promoted teamwork and cooperation. Both team members were actively involved in these tests and by studying the appropriate data sheets, were able to learn more about the hardware involved in Hexplorer.3.3Gait researchFor this phase of the project, research was conducted on various naturally existing gaits. The most common types of Gaits for six-legged insects are the tri-pod gate and the ripple gate (or wave gait). Many insects in fact use a combination of the depicted gaits, depending on the situation. However, for the purposes of this phase of the project, each gait will be simulated separately, with no advanced combinations.The ripple gate keeps the maximum number of feet in contact with the ground to provide the maximum stability for the robot. In the ripple gait, the rear pair of legs is moved, then the middle pair, and then the front pair. The body is then translated forward, with all feet remaining on the ground. The sequence is then repeated. Unfortunately, because the robot only advances after all six legs have moved, the walking motion is very slow.To improve the speed of the robot, a tri-pod gate can be used. In the tri-pod gait, three legs move at a time: the middle leg on one side and the front and rear legs on the other side. Provided the three legs form a …tri-pod‟ around the centre of mass of the robot, this gait will maintain stability. The tri-pod is much faster than the ripple gait because the body is translated forward each cycle by three legs, while the other three legs get into position.Because of the superior speed and reasonable stability, the team has decided to implement the tri-pod gait as the primary walking algorithm of Hexplorer. To be created next term, this design process will be discussed further in the Future Plans section.3.4ADAMS simulationTo test multiple gait algorithms and to study the torque requirements on each of the motors of Hexplorer, a simulation was created in a software programcalled ADAMS. This tool allows the user to run a simulation of a mechanical system, and subsequently plot reaction forces and torques. ADAMS also allows the user to perform inverse kinematics and dynamics analysis on a particular mechanism.From previous Hexplorer teams, an ADAMS model of one of the legs of Hexplorer was obtained. This model was slightly modified to account for recent changes and then combined to form a complete model of Hexplorer. The resulting model is shown in Figure 5.Figure 5: ADAMS model of HexplorerWith the model created, a few simple movements were tested to examine the behaviour of the robot. The first simulation tested the responsiveness of one individual leg. The model was created with a contact force to groundthat allowed for realistic slipping of the feet. However, this individual leg was capable of translation in one direction only. When all six legs were connected to the base, and subsequently simulated, the robot moved in a realistic manner over the surface of the model.This recreation has given the team a valuable tool for testing and analyzing the gaits that are to be implemented in the second phase of the project. During the construction this model, much was learned about the ADAMS software and its vast capabilities.3.5Communication testingOne of the present components that the Hexplorer group is working on is attempting to exercise the Brain-Leg communication channels. To properly control the walking gait of the robot, the brain must deliver desired foot positions to the legs and the legs must reply when the leg reaches the desired position or if the desired position is unreachable. The current line of testing is trying to test these two communication messages.Once the communications testing is completed, the brain should be able to coordinate some walking gait algorithm. The Hexplorer group should be able to get the robot walking in a simple tri-pod gait by the end of December.This first gait algorithm will not include the control structure or inverse kinematics.4Future PlansOver the next term, the Hexplorer group plans on implementing a simple gait algorithm using a more sophisticated control structure that coordinate the legs to ensure that they are working most efficiently together. This algorithm will be able to monitor and control the speed of up to nine motors using four DSPs (three leg DSPs and the brain DSP) to translate the body with three feet on the ground. Furthermore, in this algorithm, the brain will demand foot position as a coordinate in space instead of using encoder counts. This will involve implementing inverse kinematics equations, which relate position to encoder counts and vice versa, on the leg DSP boards. The implementation of this algorithm is planned to be completed by the end of January 2003.The Hexplorer team then plans on entering the Ontario Engineering Competition in February 2003 with the walking robot in the Corporate Design category. The team has already approached the Canadian Space Agency and MD Robotics to “sponsor” the project. The team is also planning on entering the Texas Instruments DSP competition in the summer.Between these two competitions, the team will attempt to implement more sophisticated gait algorithms than the simple tri-pod gait. In is theteam‟s hope that these advanced walking algorithms will be able to be displayed at the TI DSP competition.5Tentative ScheduleThe following table outlines preliminary goals and deadlines based on rough calculations. Due-dates may be shifted slightly as more information is learned.Appendix AC3 Meeting MinutesC3 meeting #1Location: E2-1303ETime: 10:00 PMNo Regrets!Intelligent Vacuum cleaner group (Jimmy, Keith, Sam) -two approaches-GPS, location of the vacuum-Try to cover the specific area-Activate it and make sure that it covers all areas-Random algorithm or pattern algorithm-Internal sensing system (no external system required) -Battery life is an issue-No pre-programming-Figures the boundary on it‟s own-power assumption-vacuums use lots of power-need own power systemQ/A- How big is it and what is the shape? (0.5 meter by 0.5 meter, square or a car shaped)- What is your power source? (Not sure at this moment)- What is your goal for this term? (Algorithm done)Hexplorer group (Damien and Nick)-six-legged walking robot-since 1996-in 1998, it changed from rectangular to circular-previous term, upgraded software and leg movement-last year, just make the leg move (one leg)-fixed circuit boards (central brain)-want to have all six legs moving and walk across something-need to debug the board-need to fix the structure of the controllerQ/AFirefighter robot (Ivy, Jane, James, Lyon, Patrick)-robot to put off a fire-open area with no obstacles- 3 different fires to extinguish-room temp of 50C for heat analysis-challenges include cooling system, extinguishing unit-difficulty is to maintain the internal circuit system‟s temperature within it‟s operating range-use water for cooling system and the extinguishing unitIssues-problem with the sensor-problem with calculating the distance between the robot and the fire -Install funnel at the top of the robot and collect water from the sprinkler systemQ/A- What will you accomplish this term? (Extinguishing unit and pumps)- Will the sunlight interfere with the sensing of the fire? (Will have to filter out the ambient light)-C3 meeting #2Location: E2-1303ETime: 10:00 PMDate: Tuesday, November 19, 2002Regret: Keith HumIntelligent Vacuum cleaner group (Jimmy, Keith, Sam)-Ordered a compass (internal) with serial interface-Received IR sensors-Comparing components-Preparing a funding proposal-Started writing report (e.g., concept generation)-Foresee starting path algorithm – can use code simulator-Rough chassis designIssues-Difficult to find robotics parts in Canada-Problems with microcontrollers (don‟t know where they put development kit)-Still waiting to receive more components for testingTimeline- about 20% of project completed: may have to redefine scope but Karray is ok with this- end of this week: complete path finding pseudocode/algorithm- middle of next week: complete testing of sensors- Dec 2: final report and complete testing microcontrollerQ/A-Hexplorer group (Damien and Nick)-began testing: testing legs-can tell robot where to goIssues-no problems: on schedule- 6 degrees of freedom and 9 motors to control: motors may counteract one another-must find a way to coordinate motor movementTimeline- about 70% of projected work completed- get brain to communicate w/ legs- try to get all 5-6 legs working- examine different walking algorithmsQ/ADoes the Hexplorer model any creature in nature? No –since it‟s a hexagon with equally spaced legs.Firefighter robot (Ivy, Jane, James, Lyon, Patrick)- started writing final report- want to start building prototype in 4A term since 4B term is short- already performed fire testsIssues-still have not received robot base: held at border/customs-cannot start preliminary prototyping as no actual dimensions available -still no news about thermodynamics lab for experiments and testing -Timeline- 40% of project completed- complete all preliminary testing by end of this week- continue writing report and have a first draft ready by end of next weekQ/A-Opinions on C3 meetings-C3 meetings started too late in the term. May have been more helpful at the beginning of the project especially for topic selection-Perhaps organize next C3 meeting in lab so can demonstrateprototypes/testing-May be more beneficial if C3 meetings were done at the end of the project so we can discuss problems with other groups-It‟s good because we can hear about others‟ groups projects – for personal interest-But it‟s not really helpful as our projects are very di fferent, different group sizes, etc.C3 meeting #3Location: Systems WorkshopTime: 2:00 PMDate: Tuesday, November 26, 2002Regret: Lyon WongHexplorer Group-Show and Tell-Has 6 different boards to control each of the legs- 1 brain board to control all 6 legsFirefighter Group-Photo sensors-Extinguishing unit-PumpVacuum Group-Received some parts-Waiting for some more part-Will design control algorithm by end of this term-Two batteries: one for the electrics and other for the motors。