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: Class Projects, free time, etc. Basic Abilities: Motor Control Proximity Detection Flame Detection Flame Suppression What was done? Higher-level software development Software-hardware integration Why was it developed?
Robot Competition – Goals & Objectives “...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
Hardware Architecture Main Board Implemented Peripherals Communication Bus Main Board: System Microcontroller – Overall flow of execution Memory – Program and data storage Expansion slots – Peripheral Devices (specific functionality) Implemented Peripherals 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
Software Architecture 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. Obstacle detection Flame detection 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.
Required Abilities Reliable Movement/Positioning 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? Proximity Detection Is an obstacle present? Where is it located? Flame Detection Is a flame present? How close is it? Simple abilities often require complex software Movement...
Reliable Movement Why is it important? Robot knows present location and orientation within the maze Why is it difficult? Non-identical components: 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? Software compensation: Multiple speeds (30 different speeds) Acceleration profiles Sensor correction
Reliable Movement – Original Motor Software Problem: Not enough speeds: Acceleration not smooth Movement not straight –both motors set to same speed Original Implementation: Single command (4 bits of information) 5 – forward motion 1 – reverse Solution: Build on existing architecture Multiple commands: 30 – forward motion 30 – reverse motion Problem fixed? Yes, and no...more distinct speeds, new problem developed...
Reliable Movement – New Motor Software 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 Problem fixed? Yes, and no...more distinct speeds, however, communications between system microcontroller and peripheral microcontroller broken.
Reliable Movement – Interrupt-based Software 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 transmitted. Problem fixed? Yes, and no...more distinct speeds, better movement, however not repeatable.
Reliable Movement – Sensor Correction 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 Problem fixed? Yes, reliability of movement has been greatly increased.
Software Development 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