7. Software DesignHexotica - The Design and Implementation of a Small Walking Robot
7.1 Software Architecture
During the design of the software architecture, every attempt has been made to maintain the modular design approach with which other parts of the robot have been developed. A number of libraries have been created which encapsulate the different control levels necessary for controlling the robot. Each library provides specific functions relevant to its particular task in the control hierarchy. For example, by keeping sections of the code that deal directly with hardware communication separate from the control structure itself, it is possible to change the control architecture without having to rewrite the lower level code and vice versa. The basic program levels currently being used are shown in Figure 45.
Figure 45 - Modular program levels in distributed configuration
There is a lot of flexibility inherent in this design approach. Different levels of code are currently implemented on separate processors. Each leg pair has its own dedicated processor with a TIA/EIA-485 (formerly known as RS-485) network allowing communications between the main control processor and the various leg processors. To convert the software control structure to a single processor configuration, the leg_info and msg levels would be removed and the gait module would simply call the leg access functions directly, as shown in Figure 46. This has been done in the simulation of the robot currently being developed in which the control of the robot is effected using a single processor model and the high-level control functions have been modified to call the leg access functions directly.
Figure 46 - Modular program levels in single processor configuration
Another appealing aspect of this design is the fact that each module is replaceable which allows different functionalities to be added incrementally. If any part of the system is changed, only the local access functions have to be changed without affecting the rest of the system. This is also true of further development efforts. As new libraries are developed, such as libraries to support new sensory input, the rest of the system will not be affected. The main controller will have access to the new information and will process it appropriately and pass the information along to the rest of the system.
In order to take full advantage of the modularity of the software architecture, object oriented programming paradigms were followed. The C language does not support object oriented code development per say so appropriate data structures and access functions were created. The access functions use the data stored in the data structures to keep track of appropriate variable values. Access functions are passed a pointer to the appropriate data structure to give them access to the local information contained in the structures. Appendix C – Software Libraries outlines the functionality provided by each of the interface libraries, the data structures used to store the appropriate information and the access functions used to manipulate the information contained in each of the data structures. Appendix B - Application Files describes each of the application files that have been developed to control the robot. These applications use the appropriate software libraries to interface with the motor control hardware, communicate across the EIA/TIA-485 serial link and implement the appropriate control algorithms for the high level and low level controllers.
Currently, the main controller waits for input from its sensory structures or, in this case, instructions from the developer. It interprets the information it receives from these sources and uses it to determine the appropriate walking gait to adopt, the direction of desired motion and the speed with which to move the legs. The gait control functions provide access to the walking gaits, with the tripod and ripple gaits being currently implemented. Local information about the status of each leg is stored in the leg_info structures. These structures are used to monitor the status of each leg and to ensure that they are moving appropriately.
Messaging functions are provided in the msg library. This library includes both the master and slave functions necessary to enable EIA/TIA-485 communication to occur. When the master controller sends a message, a unique identifier is passed along with it. The slaves use this identifier to determine whether the message is directed at them. If it is, they grab the message off of the serial line and store the data in the appropriate message structure. The message is parsed to determine what message has been sent and a reply acknowledging receipt of the message is sent back to the master controller. The reply to a request for leg information consists of the current via point, an in position flag and a moving flag while all other replies simply consist of returning the instruction character to allow the master to determine if the message has been received.
When the slave controller has parsed the commands sent by the master controller, it updates the desired motion of the legs as instructed. By setting the appropriate motion flags, it can cause the real-time interrupts that occur on the processors to begin moving the legs. The controller determines the desired joint positions of the legs at each time-step and uses a PD controller to achieve the appropriate motion of the leg. Motor command signals are sent to the interface boards using the motor libraries while the joint angles are measured by reading the potentiometer values using the ADC libraries. This control loop forces the leg to move the foot through the appropriate straight-line trajectories.
7.2.1 Motivation for Simulation
The simulation of a mechanical system is a useful tool to investigate the behaviour of a real world system without having to realize a physical model. It is also a useful tool for predicting the performance of a control system for an existing physical model, without fear of damaging or breaking it. This ability is increasingly important as the complexity of the model grows. With more and more variables to control, the overall effect of a control system on a working model can be difficult to predict.
The control of a walking robot is an example of an extremely complex control problem. Due to the complexity of the control system, a computer simulation of the physical system is needed. The goal of the software simulation is to be able to control the simulation in a similar manner as the method used to control the actual system. This way, new control algorithms can be prototyped in simulation first without having to worry about damaging the actual robot if the control algorithm is initially faulty. There are a number of other variables to worry about with the actual system as well, such as power connections, lack of robustness in the mechanical design, and other issues that complicate the development of walking algorithms. The simulation is a useful tool for simplifying the entire system so that the software designer can focus on the walking algorithms and not have to worry about the other possibly unstable systems on the actual robot.
The actual system is controlled by a series of microprocessors that are programmed in C. In order to create a useful simulation, it is important that it can be controlled by C code as well. For this reason, a dynamics modelling package called MÖBILE was used. MÖBILE runs on SGI workstations, and can use C code to control a 3 dimensional model on screen. By developing the code in such a way as to emulate the real world software control system hierarchy, code developed on the simulation can easily be ported back to the robot.
7.2.2 Simulation Design Criteria & Constraints
This simulation component of this project proposes to model a 6-legged walking robot using a dynamic modelling package. This work will allow new control schemes to be tested.
7.2.2.1 Simulation Design Constraints
The constraints on a problem are used to determine the feasibility of a solution. A feasible solution is possible if and only if each and every one of these constraints is met.
- The model must accurately reflect the motion of the robot
- The model must allow existing control schemes to be tested and should be flexible enough to permit new control schemes to be tested as they are developed.
- The 6 legs must be independently controllable, with 3 DOF for each leg.
- In keeping with the physical design, the model must be modular.
7.2.2.1 Simulation Design Criteria
The merit and worth of proposed solutions can be measured by careful consideration of the design criteria.
- The model should allow new control ideas to be tested more easily than using the existing environment (i.e. directly on the robot)
- The modelling environment should allow inverse dynamic calculations to be performed to find required motor torques. This will allow the robot specifications to be more rigorously defined in the future.
- The model should provide a realistic graphical interface to allow the performance of the system to be monitored.
Software simulation is a useful tool during the development of any complex system. By simulating the system before it is implemented, it is possible to specify the system requirements and to ensure that new components being developed are working correctly. These components can then be incorporated without fear of damaging the physical system and this, in turn, simplifies the debugging process.
For the robot that has been developed, there are a number of different system components that can be simulated. Simulation of the low-level control scheme using C++ and MATLAB enabled the low-level control algorithms to be verified and tested. Incorporating the micro-controller code into the dynamic simulation package MÖBILE allows for simulation of the high-level controls involved in gait planning. This package also provides the potential for dynamic analysis of the robot, a feature that will prove very useful if the mechanical system is to be redesigned.
MÖBILE runs on a SGI workstation and consists of a series of C++ classes that are linked with the Inventor classes and the SceneViewer to provide the user with graphical feedback about the performance of the dynamic system being analyzed. The package can handle both kinematic and dynamic analysis of complex systems. Each component of the model is instantiated as an instance of a particular class and these are linked together to form the system. Classes of objects include rigid links, joints, masses and frames of reference.
In order to meet the design constraints of this part of the project, the control code developed for the robot must be used to control the motion of the simulated robot. The control algorithms were ported from the Dynamic C environment that runs on the SmartCore microcontrollers to the SGI. A number of new MÖBILE classes were developed to provide the interface between the dynamics package and the original control code. These classes are used to call the robot control algorithms at each step of the animation.
The modularity of the control code made it relatively easy to port the code to the new simulation package. Using the existing leg libraries, control of a single leg was first tested to find any changes that had to be made. This leg control was then encapsulated in a class called MoLegHandler. By instantiating 6 instances of this class, the 6 legs of the robot were created. Control of the walking gait was encapsulated in other classes called MoTripodHandler and MoRippleHandler (in fact, the ripple gait algorithms were developed in simulation before being implemented on the robot). Since the simulation is essentially a single processor control model, adjustments to the code have been made and the gait algorithms call the leg access functions directly, as discussed previously in the software architecture section. The control hierarchy and class encapsulations are shown in Figure 47.
Figure 47 - MÖBILE class-based control hierarchy showing control of two legs
During each step of the animation, the MÖBILE main loop calls each of the classes to update the status of the legs. The MoLegHandler class contains the frames of reference, links and joints that describe each of the legs (see Figure 48). At each time step, the angles of the legs are updated according to the desired motion of the leg. The MÖBILE animation engine then uses this information to update the graphical display. At the same time, the gait handler being used checks the position of each leg, updates the desired motion of the legs and coordinates this motion to achieve the appropriate walking gait.
Figure 48 - Leg components showing links, joints and frames of reference
The MoLegHandler class enables legs to be added to the system very easily. The class contains information about the link lengths of the leg, a pointer to the base frame, the masses of the members, the connections of the joints and a pointer to the leg information being updated by the control algorithms. These control algorithms update the desired angles of the legs each time they are called. On the robot microprocessors, this updating is performed in a real-time interrupt and the time-step between successive updates is known. In order to simulate the performance of the real system, the time-step is kept the same and each iteration of the animation engine is assumed to represent a real-time interrupt. Since the animation engine is also responsible for updating the graphics, implementing the low-level control for all 6 legs and taking care of the high level control, this simulation will likely not run in real-time.
To increase the realism of the simulation, drawings of the actual leg members were imported as Inventor files. The AutoCAD drawings, shown in Appendix H – CAD Drawings, were imported into 3D Studio and then converted into the appropriate Inventor format. Each leg uses the graphical information contained in the files "link1.iv" and "link2.iv" in order to display the links. During each animation step, the legs are redrawn at the desired position.
When the single leg had been satisfactorily incorporated into the MÖBILE environment, 6 instances of the legs were created and the body of the robot was defined. The body was also implemented using a modular approach. On the robot, there are three pairs of legs, each of which can be thought of as an independent module. These modules are connected together via two rigid members that form the body of the robot.
In simulation, a single robot frame and three module frames were created. The module frames are spaced apart from the main robot frame using rigid links. In addition, each module is assigned an appearance using the Inventor image file, "ribs.iv". The robot body image is contained in "body.iv". Finally, 6 base frames are defined for the 6 legs. Each leg contains a pointer to its base frame and these are placed at appropriate positions on the robot body. The entire body configuration is shown in Figure 49.
Figure 49 - Body frames showing module frames and leg base frames
When all of these components are assembled, the resulting animated figure looks quite similar to the physical system it is modelling (see Figure 50). This meets one of the design criteria outlined previously. The animation is controlled through menu items provided by the SceneViewer interface. This interface allows the animation to be executed, the point of view of the observer to be changed, the lighting to be adjusted and the complexity of the rendering to be changed. To improve the response rate of the animation, simple bounding boxes can replace the complex Inventor files. This significantly improves the performance of the animation engine.
Figure 50 - Screen capture of robot
In addition to the menu controls provided by the SceneViewer, a number of additional interface objects were created using MÖBILE primitives. A pair of sliders was added as well as a pair of pushbuttons. The sliders control the speed of the walking gait and the desired direction of travel of the robot. The push buttons control the walking gait to be adopted by the robot. This allows the user to select between the tripod gait and the ripple gait. There is some work still remaining to iron out a few technical difficulties with these interface objects.
To test out the effectiveness of the model, a new walking gait was developed in simulation. The ripple gait is more complicated than the tripod gait that had already been tested on the robot platform. The ripple gait requires more coordinated motion between each of the legs in order to achieve the correct sequencing of leg motions. The control code that implements the existing tripod gait was used as the basis for the new ripple gait - again maintaining the modularity of the system.
In simulation, the ripple gait works quite well. Once the legs have coordinated themselves (one weakness of the current controller is the fact that it doesn’t initialize its motions very well), the leg motions are seen to ripple up the sides of the robot. The rear leg is lifted and advanced at four times the rate that the other legs are being drawn back. When this leg is planted, the middle leg is lifted and advanced. When the lift and advance motion has rippled to the front of the robot, the rear leg will be arriving at the end of its travel and the cycle will repeat. This means that there is continuous motion of the legs on either side of the robot, with each side being 180o out of phase. Effectively, this gait allows four feet to be on the ground at all times and is more stable than the tripod gait.
This gait was then brought over to the actual robot controllers. Because of insufficient modelling of the motor characteristics, this gait did not work very well. The ripple gait requires considerably more coordination than the tripod gait and work is continuing to determine how the performance of the robot can be improved.
In addition to the kinematic solving routines used by the current version of this simulation, MÖBILE also can also perform inverse dynamic calculations. One of the criteria mentioned at the beginning of this section was that the system should allow the motor specifications to be determined using some type of inverse dynamic solving routine. This has not been implemented at this time.
One of the major problems with attempting to determine motor torque requirements using the simulation is the fact that ground contact must be modelled. Most of the torque requirements on the motors, especially at the shoulder joint GAMMA, occur because of the weight of the robot. If inverse dynamics were used to solve for the motor requirements needed to simply move the legs, these would not accurately reflect the actual torques required to lift the robot body. In order to have a useful inverse dynamic solver, contact with the ground must be modelled. MÖBILE does not provide any automatic means by which ground contact can be modelled and, due to time constraints, this has not been implemented.
The simulation that was created emulates the motion of the real world system very well. The simulation is strictly a kinematic model, so ground contact and joint torques are not considered in the simulation. For this reason, the robot’s behaviour matches the simulation’s behaviour most closely when the robot is suspended in the air (like an insect that has been lifted from the ground by its body).
The simulation was first tested by implementing the tripod gait. This gait had already been developed successfully on the walking robot. The control code was successfully ported over from the robot to the simulation.
Another walking gait known as the ripple gait was then developed on the simulation. This gait is more complex than the tripod gait, and some difficulty was experienced developing it on the actual robot. It was successfully developed on the simulation, then ported back to the robot control system. This dramatically shortened the development cycle. The performance of the system was sufficiently close to the simulation to prove the usefulness of the simulation as a development tool.
This project has met all of the design constraints outlined at the beginning of this section. The model accurately reflects the motion of the robot (assuming the motors respond ideally to their commanded velocities), the existing control schemes have been used to control the model robot, each leg is a modular instance of an independently controllable object and the legs allow for three degrees of freedom. In addition, new control ideas can be easily developed using the model and the graphical interface provides a realistic representation of the robot being modelled.
The only criterion that the current model fails to meet is the ability to calculate inverse dynamics. This is discussed in the Recommendations section that follows.
7.2.6 Simulation Recommendations
There is still a lot of potential for this portion of the project. One of the major weaknesses of the current robot is in the mechanical design. The motors selected have proven to be too weak to lift the weight of the robot. If the current model were extended to allow calculation of the ground contact forces, inverse dynamics could be used to determine the torques necessary at the joints to lift and move the robot. This would prove to be very useful if the robot hardware is ever to be redesigned.
The user interface also needs improvement. There are still problems with the current user interface and a better method of controlling the model robot should be found. This should be updated in coordination with updates made to the high level controller of the actual robot. If and when sensory feedback is provided for the robot, new control schemes may be necessary for the high level controller. Changes to this part of the control code should be reflected in the model of the robot.
copyright information
Back to home
page. Last updated: April 20th,
1997
