Applied Robotics: Software Architecture, Development, & Integration David M. Huhn Student Scholarship Day April 10, 2002 Background & Introduction GROMIT: Autonomous, Fire-fighting Robot Concept, Initial Hardware and Software: Summer Research Project Architectures Expanded:
Software Architecture, Development, & Integration
David M. Huhn
Student Scholarship Day
April 10, 2002
GROMIT: Autonomous, Fire-fighting Robot
Concept, Initial Hardware and Software:
Summer Research Project
Class Projects, free time, etc.
What was done?
Higher-level software development
Why was it developed?
“...to build a computer controlled Robot that can move through a model floor plan structure of a house, find a lit candle and then extinguish it in the shortest time...”
“...meant to simulate the real-world operation of a Robot performing a fire protection function in an actual home...”
“...the real goal of the contest is to advance Robotics technology and knowledge both in the competing individuals and in the world in general”
- Taken from Trinity College Robot Contest Site
System Microcontroller – Overall flow of execution
Memory – Program and data storage
Expansion slots – Peripheral Devices (specific functionality)
Power Board – provides for all power requirements of systemMotor Board – control of all motors (positioning, fire-extinguishing)Infrared Board – control of three individual proximity sensorsFlame Board – control of flame sensor
Low-Level Functions: Control hardware at most basic level
Motor Driver – Rotate clockwise, rotate counter-clockwise, stop, etc.
Infrared Driver – Pulse emitter, read detector
Flame Driver – read detector
Intermediate Functions: Utilize hardware drivers to perform simple function
Forward movement, acceleration, etc.
High-Level Functions: Integrate multiple Intermediate functions to complete goal:
Accelerate to full speed, move forward until a wall is detected, then slowdown and stop.
Rotate slowly while polling the flame sensor, stop if a flame is detected, turn on the fan.
Does the robot move where it should?
Is a 90 Deg turn really 90 Deg?
Does the robot move in a straight line?
Is it repeatable?
Is an obstacle present?
Where is it located?
Is a flame present?
How close is it?
Simple abilities often require complex software
Why is it important?
Robot knows present location and orientation within the maze
Why is it difficult?
Do both motors turn at the same rate?
Are the wheels both perfectly round?
Other factors to consider:
Is the surface smooth?
How much friction are the stabilizers subject to?
How can it be achieved?
Multiple speeds (30 different speeds)
Problem: Not enough speeds:
Acceleration not smooth
Movement not straight –both motors set to same speed
Single command (4 bits of information)
5 – forward motion
1 – reverse
Solution: Build on existing architecture
30 – forward motion
30 – reverse motion
Yes, and no...more distinct speeds, new problem developed...
Problem: Movement not smooth on speed changes:
Smooth movement at any of the 30 speeds, provided robot stays at that speed.
Accelerating up or down produces “jerky” movement
Inexact Pulse-Width-Modulation to drive motors, motors were disabled on speed changes.
Solution: Rewrite original motor driver
Interrupt driven, Pulse width modulation for motor driver.
30 speeds (40% Positive Duty cycle and 100% Positive Duty cycle)
Motors no longer disabled during transition
Yes, and no...more distinct speeds, however, communications between system microcontroller and peripheral microcontroller broken.
Problem: Interrupt service routine incompatible with existing communications
Motors did not recognize commands sent to it because they were not received properly.
Solution: Rewrite the communications interface
Short delays added to give peripheral microcontroller time to correctly read the value being
Yes, and no...more distinct speeds, better movement, however not repeatable.
Problem: Movement not always straight(repeatable):
Acceleration profile and additional speeds greatly improved accuracy...
Imperfect hardware still causing occasional crooked movement
Solution: Supplement multiple speeds with sensor correction
Sensor sensitivity adjusted to detect maze walls
Dynamic changes in motor speed when a sensor reports a hit
Yes, reliability of movement has been greatly increased.
Problems in software at any level can cause the entire system to fail
Problem with code at one level might require code at another level to be rewritten
Software development and integration is an iterative process