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
NOTE: This is the last in a series of four “design component” homework assignments, each of
which is to be completed by one team member. The body of the report should be 3-5 pages,
not including this cover sheet, references, attachments or appendices.
Evaluation:
SCORE
DESCRIPTION
Excellent – among the best papers submitted for this assignment. Very few
corrections needed for version submitted in Final Report.
Very good – all requirements aptly met. Minor additions/corrections needed for
9
version submitted in Final Report.
Good – all requirements considered and addressed. Several noteworthy
8
additions/corrections needed for version submitted in Final Report.
Average – all requirements basically met, but some revisions in content should
7
be made for the version submitted in the Final Report.
Marginal – all requirements met at a nominal level. Significant revisions in
6
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.
10
Comments:
ECE 477
Digital Systems Senior Design Project
Rev 8/09
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 onchip 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 autonavigation 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 microcontroller 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
-1-
ECE 477
Digital Systems Senior Design Project
Rev 8/09
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
-2-
ECE 477
Digital Systems Senior Design Project
Rev 8/09
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-
ECE 477
Digital Systems Senior Design Project
Rev 8/09
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 autonavigation 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
-4-
ECE 477
Digital Systems Senior Design Project
Rev 8/09
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.
-5-
ECE 477
Digital Systems Senior Design Project
Rev 8/09
List of References
[1] Digikey, “MC9S12DP512 Device Guide V01.25” [Online]. Available:
http://media.digikey.com/pdf/Data%20Sheets/Freescale%20Semi/MC9S12DP512%20Guid
e.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).
IMPORTANT: Use standard IEEE format for references, and CITE ALL REFERENCES
listed in the body of your report. Any URLs cited should be “hot” links.
-6-
ECE 477
Digital Systems Senior Design Project
Appendix A: Flowchart/Pseudo-code for Main Program
-7-
Rev 8/09
ECE 477
Digital Systems Senior Design Project
Appendix B: Hierarchical Block Diagram of Code Organization
-8-
Rev 8/09