ECE 477 Digital Systems Senior Design Project Rev 8/09

Homework 9: Software Design Considerations

Team Code Name: Self-Balancing Biped Robot______Group No. __14

Team Member Completing This Homework: ______Jinliang, Wei______

E-mail Address of Team Member: ______jlwei____ @ purdue.edu

Evaluation:

SCORE

/

DESCRIPTION

10 /

Excellent – among the best papers submitted for this assignment. Very few corrections needed for version submitted in Final Report.

9 /

Very good – all requirements aptly met. Minor additions/corrections needed for version submitted in Final Report.

8 /

Good – all requirements considered and addressed. Several noteworthy additions/corrections needed for version submitted in Final Report.

7 /

Average – all requirements basically met, but some revisions in content should be made for the version submitted in the Final Report.

6 /

Marginal – all requirements met at a nominal level. Significant revisions in content should be made for the version submitted in the Final Report.

* /

Below the passing threshold – major revisions required to meet report requirements at a nominal level. Revise and resubmit.

* Resubmissions are due within one week of the date of return, and will be awarded a score of “6” provided all report requirements have been met at a nominal level.

Comments:

1.0  Introduction

Our design consists of a biped robot that should be self balancing, be capable of walking turning, and pivoting and be controlled via a software GUI on a laptop over a WiFi connection.

The biped robot should also be able to automatically navigate without falling down or running into an obstacle.

To achieve this goal, we designed the robot control algorithm, in which 3 actions are defined for our robot, WALK, TURN, and PIVOT. Each action is done by moving the feet of the robot through a pre-defined sequence. And changes of action should only happen when the current action is done unless unbalanced condition is detected. Then in order to implement the algorithm on MC9S12A512, our design considerations include utilization of memory and on-chip peripherals, and overall organization of application code.

2.0  Software Design Considerations

Our biped robot will operate in two different modes, the user-control mode and auto-navigation mode. In user-control mode, the robot will receive control messages and perform actions accordingly. It assumes that the user will take care of avoiding obstacle and external forces, so it will not need to read output from accelerometer or ultrasonic range finder. While in auto-navigation mode, it needs to read outputs from these two sensors navigate safely.

The robot needs to perform three main actions: walk, turn, and pivot. Each action is broken into several sub-actions, each of which is a pre-defined sequence of robot foot positions and orientation. To perform an action, the robot should perform its sub-actions in order. And for performing the sub-action, it simply goes through the sequence, and for each foot position and orientation, uses Inverse-Kinematic equations to figure out the servos’ angles and move the foot accordingly.

If the accelerometer detects an abnormal large acceleration, it indicates the robot may be unbalanced. So the micro-controller should break the current action and handle the abnormality immediately. After the robot gains balance back, it needs to move its feet back to where they are before the action is broken to resume the desired action.

To implement that algorithm on our microcontroller, there are many issues we need to take into consideration for software design. The first issue we considered was whether the micro-controller would have enough memory and the mappings of it. MC9S12A512 has 14 KB RAM and 512 KB flash, which is more than enough for what we need. This micro-controller will be programmed in embedded C. As we have already known, the CodeWarrior C compiler will take care of where to put code, data and stack [1]. There are two sets of data we want to store into flash, the lookup tables for trigonometric functions and the sub-action vector arrays. The lookup tables are used for evaluating trigonometric functions. CodeWarrior has a math library which provides those functions. However, we found that even though those functions were very accurate, they ran too slow. Then the micro-controller would not be able to calculate the appropriate servo angles within the servo refresh period. Since we will only need to evaluate those functions at integer points, we decided to do a quick table lookup. Sub-action vector arrays are array of the foot positions and foot orientations. Such an array defines a sequence of movements of servos to complete a robot action. Since these are pre-defined sequences and will not be changed during run-time, they can be put into flash.

Our micro-controller uses several integrated peripherals to drive servos and get data input. So naturally, one of the concerns was the utilization of those peripherals. 8 PWM channels will be used to drive 8 servos [3]. The servo refresh period is 25 ms, yet setting pulse width from 0.6 ms to 2.4 ms corresponds to rotating the servo by 0 to 180 degrees. If PWM period is set to 25 ms, only a small portion of the duty cycle range can be used. The PWM’s 8-bit duty resolution is highly underused, and motion is very inaccurate. Our solution is to set the PWM period to 2.5 ms, while one servo period consists of 10 PWM periods. A timer channel will be use to assist turn the PWM duty on for the first period and off for the other 9 periods. In that way, the 8-bit duty resolution is better utilized. And then the error can be limited within 1 degree.

To enable wireless control and read environment information, the micro-controller is interfaced with several devices. The SCI1 port is connected to the WiFly card [2] to communicate with the biped control GUI. This SCI peripheral will run interrupt-driven receive and program-driven send. The biped control GUI can send message to biped at any time but the biped will only send periodic status messages or receive confirmation messages.

Since messages will only be processed after the current sub-action is done. One concern was that the user may send multiple messages during that sub-action. Instead of buffering all those messages, we decided to ignore all incoming messages if there is a pending one. This is because that the user intuitively believes he/she commands the robot to act in the state that he/she is currently observing. But a buffered message will be processed several actions later, so the corresponding action will not be done in the state that the user observes when sending the message, which may result in unexpected robot action.

One SPI port is used to read accelerometer output, with the micro-controller acting as master and accelerometer acting as slave. This micro-controller will only receive data and will run in interrupt-driven mode this is because when a significant acceleration on the robot, the robot needs to response immediately to handle the abnormality and balance itself.

One ATD channel is used to read output from ultrasonic range finder. It will run in program-driven mode, this is because our biped robot walks relatively slowly, it only needs to check that ultrasonic range finder output periodically.

TIM module will be used to trigger periodic actions, including sending periodic status messages, and turning PWM duty on or off. The interrupt rate will be initialized to 10 kHz and time will be accumulated on several counters to set global control flags for each action.

To facilitate debugging, the SCI2 port is routed to header pins to connect to the serial port of a computer to print debugging message.

In order to organize the code to have everything work together, we will use a hybrid of interrupt-driven and polling loop. As I mentioned above, there will be several interrupt driven actions. Also, for the robot to perform an action, it needs to send PWM signals to servo every 25 ms. And after one sub-action is done, the robot needs to parse the SCI message to figure out next action. Even though it is possible to generate PWM signals in TIM interrupt service routine, and parse SCI messages in SCI interrupt service routine, it will make the interrupt service routine long, which will causes problems potentially. In order to make interrupt service routine short, we only save data and change flags in interrupt service routine, and let the main loop perform those actions according to those flags and data.

Also, the interrupt service priority is set as follows:

Fig 2.1 Interrupt Service Priority

3.0  Software Design Narrative

PWM-Servo module Status: partially done and tested

This module provides PWM initialization function, the function to rotate servos given the servo angles as well as the function to turn off PWM duties. When the biped robot is performing an action, it will check the “servoRefresh” flag continuously. If the flag is set, the function for rotating servos will be called to send PWM signals. We have already known that pulse of 0.6 ms is the threshold to start rotation, pulse of 2.4 ms rotates the servo by 180 degree and the rotation angle (in degree) is linear to the pulse width. So we can easily figure out the pulse width for any rotation angle.

Inverse-Kinematics module Status: successfully tested in MATLAB

This module is used to calculate 4 servos’ rotation angles to move the robot’s foot to a given position and orientation. It takes two vectors, foot position and orientation as input, and outputs the angles for servos on the leg.

The equations are gained from the book Robotics: Control, Sensing, Vision and Intelligence [4].

Next-Sub-Action module Status: not started yet

Known the action to perform, this module takes the current sub-action and outputs a pointer pointing to the vector sequence for next sub-action.

SCI-WiFly module Status: not started yet

This module provides the SCI initialization function, the SCI receive interrupt handler as well as the function to send message to PC. When a SCI receive interrupt happens, it will check if there is a pending message first. If there is not, it saves the message and set msgRecv flag. If there is already one, it will simply ignore the message and return.

Msg-Parser module Status: not started yet

This module parses the SCI message, sets global variables accordingly and sends confirmation message back. There will be three types of messages: operation mode message, action message, and step-size adjustment message. An operation mode message will set the operation mode to either USER or AUTO, which correspond to user-control mode and auto-navigation mode. An action message will set action to WALK, TURN, PIVOT or HALT. And a step-size adjustment message will set the angle the robot turns by.

SPI-Accelerometer module Status: not started yet

This module initializes the SPI port and handles the SPI interrupt. When a SPI interrupt happens, it checks the accelerometer output. If the acceleration is abnormally large, the interrupt service routine will immediately start the balancing algorithm and once the robot is balanced it will move its feet to the position back to where they are before interrupts to resume the action.

So far, we do not have a balancing algorithm yet.

ADC-RangerFinder module Status: not started yet

This module initializes the ADC module and provides a function for reading the range finder’s output.

Timer module Status: partially done and tested

This module initializes TIM, and handles TIM interrupt. The timer channel’s interrupt rate is set to 10 kHz. TIM interrupt service routine will accumulate time on several counters, and the counters will trigger periodic actions, including refreshing servo angles, turn off PWM duties, and send status message to control GUI.

Status LED module Status: not started yet

This module will control three status LEDs, but we haven’t yet determined how these LEDs will be used.

4.0  Summary

We invented the control algorithm for the robot to achieve its goal. For the control algorithm, two main concerns are how the robot performs an action, and when and how the action transition should occur. To successfully implement the algorithm on our micro-controller, the utilization of memory and peripherals, and overall organization of application code should be carefully considered.
List of References

[1]  Digikey, “MC9S12DP512 Device Guide V01.25” [Online]. Available: http://media.digikey.com/pdf/Data%20Sheets/Freescale%20Semi/MC9S12DP512%20Guide.pdf [Accessed: March 25, 2011].

[2]  Sparkfun, “RN-131-DS v2.5 5/11/2010” [Online], Available: http://www.sparkfun.com/datasheets/Wireless/WiFi/rn-131-ds.pdf [Accessed: March 25, 2011].

[3]  Lynxmotion, “ANNOUNCED SPECIFICATION OF HS-422 STANDARD DELUXE SERVO” [Online], Available: http://www.lynxmotion.com/images/data/hs422.pdf [Accessed: March 25, 2011].

[4]  K. S. Fu, R. C. Gonzalez, and C. S. G. Lee, Robotics: Control, Sensing, Vision and Intelligence, McGraw Hill, 1987, 580 pages (ISBN 0-07-022625-3).


Appendix A: Flowchart/Pseudo-code for Main Program


Appendix B: Hierarchical Block Diagram of Code Organization

-1-