1. A Multidisciplinary Approach for Using Robotics in Engineering Education
Jerry Weinberg
Gary Mayer
Department of Computer Science
Southern Illinois University Edwardsville

2. The integrated systems nature of robotics make robot projects an interesting and useful teaching tool
Electrical Components
Mechanical Components
Computational Components
The integrated systems nature of robotics make robot projects for many small and medium institutions difficult
Cost of pre-fabricated robots
Full range of expertise needed for constructing and teaching

3. Robot Platforms are becoming inexpensive, accessible, and stable
Cost of pre-fabricated robots prohibitive
Increase the “Threshold of Indignation”
Effort we are willing to put forth to get a task done (Saffo)
Easier, familiar mechanical components
Plug & Play feel to sensors
Wide range of programming environments
Stability reduces overhead of support, malignance, and troubleshoot

4. Teaching still requires a broader range of knowledge
Or de-emphasis of some areas
Robotics Multidisciplinary Action Group
Faculty from ECE, ME, IE, and CS
Cross-Functional team for designing course material
Share expertise through sharing of course modules and graduate assistants
Course modules provide a vocabulary
Design discussions take course modules and previous student work and adapt them to make assignment that are accessible to students in other areas

5. Area: Course
Concepts Emphasized
Concepts Shared
Computer Science:
Artificial Intelligence
Embedded agents, deliberative/reactive robot control, planning, multitasking
Subsumption architecture, search strategies, multitasking, cross compiling, multiplexing
Mechanical Engineering:
Mechatronics
Robotics – dynamics & control
Sensor processing, logic circuits, real-time processing, actuators, analog/digital conversion, kinematics, trajectory planning
Differential motion, gearing, translation motion
Industrial Engineering:
Engineering Problem Solving
Problem formulation, structural design, algorithmic design, search strategies, gearing, drive train
Problem analysis and definition, integrated system design
Electrical & Computer Engineering:
Senior Project
Signal processing, robotic system design, and project management, analog/digital conversion
Signal processing, Sensor characteristics, robotic system integration

7. Multidisciplinary Approach:
Overcome need for broad expertise through sharing of knowledge
Take advantage of cross-cutting funding programs
Near Future Goal: Multidisciplinary Engineering Design / Robotics Course
Cross-Functional student teams
Meet ABET requirements

8. Push on the abilities of inexpensive platforms to teach more advanced concepts
Navigation and Planning
Handy Board: lower threshold of indignation
Exploring board design for more Plug and Play feel
RCX: limitations of sensors and firmware
Exploring ways to go beyond Behavior-Based Control

9. Current Project Purpose: Approach: Task:
Develop complex behaviors on an inexpensive platform
Approach:
Emulate behavior that could be modeled in both a reactive and deliberative system
Task:
Forage
Search, obstacle avoidance, path planning, and navigation
PURPOSE:
Develop complex behaviors on an inexpensive platform
Enable more complex development in the classroom
APPROACH:
Want a behavior that can be applied to reactive, deliberative, and hybrid architecture
TASK:
Foraging creature – go out, find something, bring it back, repeat.
Environment mainly static but obstacles will be randomly introduced.
RESULTS:
Compare and contrast performance results
Baseline and lessons learned from which to step off in the classroom – for both instructor and student

10. Design LEGO Mindstorms RCX Not-Quite-C (NQC) “Backpack”
Dual-differential drive
Lit-target capture
Obstacle avoidance
IR communication
Compass sensor
Two rotation sensors
Distance and turning
LEGO Mindstorms RCX with version 2.0 Beta firmware
NQC version 2.2 takes advantage of new firmware capabilities allowing greater memory access and synchronization methods for resource control and event monitoring.
Backpack is a 3rd party multiplexor. Provides additional input/output ports.
Dual-differential drive provides equal power to both wheels, reducing drift. Enables rear wheels to be used for both forward and turning motion. Uses 2 motors.
Robot captures target in a scoop. Small device to hold target in place turning turns.
Forward and rear bumpers provide obstacle avoidance.
Reactive system uses IR messages with second RCX at “home” to determine general direction in which home lies.
Deliberative system will use a compass and rotation sensor for position determination on an arena map.
2 rotation sensors (distance and turning) allow position determination via dead-reckoning.

11. Reactive-Based Reasoning (ascending order of precedence)
Forage (default) – random search routine
Acquire – captures target using light sensor
Return – directs robot back to starting location using IR messaging
“Marco Polo”
Release – releases target and resets system to look for next target
Avoid – obstacle avoidance routine
Behaviors in ascending order of precedence.
Forage behavior is the default. Its goal is to search the arena for targets in the most effective amount of time.
Acquire constantly monitors the light sensor. When it exceeds a certain threshold, the behavior assumes control and guides the robot to the lit target. Once the target is considered captured, it passes control to the Return behavior.
Return guides the robot, with target, back to the starting position.
Once home, the release behavior assumes control and releases the target. It also accomplishes any clean-up required prior to the robot searching for the next target.
The avoid behavior supercedes all others – we assume our robot is skittish. It is engaged by contact with the touch sensors connected to each bumper.

12. Deliberative-Based Approach
Forage (default) – planned search routine using provided map of arena
Acquire – captures target using light sensor
Return – directs robot back to starting location using compass and rotation sensors
Release – releases target and resets system to look for next target
Avoid – obstacle avoidance routine
Each of these behaviors serves the same purpose as with the Reactive system.
The differences being in the “HOW” the purpose is accomplished.
The major differences lie in the Forage, Return, and Avoid behaviors.
The Forage behavior will start with a map of the arena with a few known boundaries. Before beginning a search, the robot will plan the best route through the arena using potential fields.
Once a target is acquired, Return will take the most direct route back to the starting location– again using potential fields.
Finally, the Avoid behavior will update the map and recalculate the potential fields once an obstacle is found.

13. Challenges Mechanical Software Drift Battery power and drain
Limited sensor ports
Sensor limitations
Software
Encoding environment
Hardware interface
There have been many challenges to implementing the current design and we see more to come as we make progress on the deliberative side.
Navigation is one of the biggest challenges, regardless of reasoning approach taken. ++ Drift results from loose gear meshes, wheel slippage on the floor, and the front caster wheels. ++ Inaccurate distance travel caused by decreasing battery power during extended use and difference in coefficients of friction between wheels and different ground surfaces. ++ Requires use of sensors as checks – compass provides direction heading, rotation sensors provide dead-reckoning. Set power levels for a particular, “average”, surface.
RCX limit of 3 input ports with some limited combinations of sensors possible (light / touch). Since more complex systems typically require a greater array of sensors, this is a problem. ++ Additionally, the sensors that come with Mindstorms are limited. 3rd party sensors sometimes don’t work due to hobby shop creation and testing in limited environments.
Maintaining environment state info is difficult due to limited array usage. Plan to use bitwise or integer encoding. Limits arena size based on memory availability.
Many different versions of SW available – some lie on top of existing firmware, others replace it. Define different variable types, manage raw sensor values differently, etc. Not all HW/SW combos tested.

14. Options to Explore Dual-RCX (Master / Slave) Triangulation
Increased sensor ports, memory, and processing
Triangulation
Multiple stationary RCXs
Mobile sensors for multi-use
Ex: Light and gear box combo allowing sensor to track ground lines, light levels ahead, and overhead light levels.
Possibilities for other projects to explore or this project if current plans do not prove fruitful.
Dual-RCX: One serves as Master, the other as slave. Communicate via IR ports. Provides additional input/output ports, memory, and processing capability. Also see potential for more than just two RCXs if a networking protocol can be devised to alleviate cross-talk error. Negative is the weight per RCX.
TRIANGULATION: Multiple, stationary RCXs along edge of arena, each transmitting a different message. Robot RCX would have to have limited FOV and could then determine general direction facing by which message was received.
Another approach to limited sensor port problem is to make multiple uses of single sensor rather than apply a single sensor to each individual problem. Current design makes minimal use of this by using light sensor to both locate target and determine when it is captured.