RoboCar Overview
Ver 2.0 -- 01/17/2002

© M. Schippling -- 12/13/Y2k

Project Links

  • Home Page.
  • RoboCar Overview -- this document.
  • Hardware Architecture
  •  Software Architecture
  • Detailed design documents
  •  Project Photos!
  • Background material
  • Resources
  • Schedule and Estimates

    •  

    Index

    Introduction
    Hardware Layout
    Input Sensor Data
    Output Controls
    Power System
    Network and Radio Interface
    Software Layout

    Introduction

    The RoboCar is a autonomous robot car that can explore its environment and sense and respond to the presence of others of its kind. The RoboCar itself contains "Lower Brain" level  functions which allow it to:
  • Detect collisions with objects and alter its path;
  • Generate a rough-estimate map of its territory and maintain a dead-reckoning estimate of its position;
  • Synchronize its position estimate with externally supplied feedback;
  • Detect and respond to humans entering its field;
  • Broadcast a Locator Signal containing small amounts of data;
  • Search for and approach another object's Locator Signal;
  • Interpret Locator Signal data received from another object;
  • Find and connect to one or more battery Charging Station(s) when its battery is low.
  • Perform simple coordinated behaviors with other RoboCars;

    •  
    The functions described above can be used to establish similar or mirrored coordinated motions among sets of two or more RoboCars. These motions can be seen as "social" behaviors such as flocking, schooling, and simple dancing. By varying some of the internal parameters individual RoboCars can be given "preferences", that might or might not match those of other RoboCars, to create a dynamic social community.

    The on-board hardware will consist of a Main Processor which implements higher order command and communications functions and an I/O Processor that controls and filters the drive and sensor data. The I/O Processor may be either a PIC chip, or the built-in programming system of commercial devices. We will assume a PIC chip in these documents except where noted.

     
    The on-board software will be capable of filtering and controlling the I/O signals and performing arbitrary sequences of actions. The sequences will be nestable so that higher order activities can be built up out of sets of lower order actions. The software may be updated at any time by downloading new sequences or new operating parameters. An RS232 serial port and/or an Ethernet port will be supported for programming and updates.
     
    In addition to their stand-alone capabilities, each RoboCar may have a radio link to a Mothership. The Mothership can supply data storage, higher processing and control, and more complex inter-vehicle communication. The design and capabilities of the Mothership are described in the General Robot Observations Using Non-linear Dynamical Systems (GROUNDS) project documentation.

    The RoboCar control system can be applied to other sorts of robots and expanded to perform more functions within the limits of the hardware being used.

    Input Sensor Data

    This describes the full set of sensors available to a RoboCar. Some implementations will have only a subset of these signals available, as appropriate to their use.

    Collision Detectors

    Each corner of the RoboCar will have a hinged spring bumper that operates a microswitch when a collision occurs. The bumpers will be mounted at the front and rear of the vehicle, so that a direct forward or reverse contact will operate both relevant switches. Some acute side contacts will be detectable as well, however there is no current plan for perpendicular side contact sensors.

    Battery Indicators

    Level -- An analog voltage indicator to monitor battery level. The range of the signal will be set empirically to allow detection of a low battery and the need to connect to a Charging Station..
     
    Charge -- An analog current flow indicator to monitor the battery (dis)charge rate. When the signal  is negative, it will indicate how much power is being used by the robot. When the signal is positive it indicates the Charging Station function, when the charge current flow drops below a empirically determined point we can assume that the battery is sufficiently  re-charged.

    Locator Signal

    The Locator Signal is an 360 degree InfraRed signal (900 nM)  broadcast from all RoboCars, Charging Stations, and possibly other objects. The signal comprises a simple serial data stream generated by the I/O Processor using
    data  from the Main Processor.
     
    Data -- A full circle detector array will be included on the broadcast assembly. This detector will be able to decode the data in any Locator Signal sent from another object within range. The serial data on the Locator Signal will be detected, amplified, demodulated, and fed to a Capture (in the CCP system) input on the I/O Processor where it will be decoded into a 16 bit data packet to be sent to the Main Processor.
     
    Strength -- A narrow beam IR sensor will be mounted on the front of the RoboCar where it can be used to scan the field in search of other Locator Signals. The absolute strength of the signal will be buffered and fed to an analog input on the I/O Processor where it will be converted into an 8 bit signal strength value to be sent to the Main Processor.

    PIR Heat/Motion Detector

    A Passive InfraRed sensor, as used in simple porch light motion detectors, will be mounted on the front of the RoboCar. This will detect the heat from a human (or animal) moving around in the forward quadrant of the car at up to about 10 meters distant (it will also trigger when the car scans across a stationary heat source). The PIRs are sensitive to long wave IR at about 10 micrometers.

    Output Controls

    Both the Drive and Turn controls can be used on cars that have two independent drive motors, or on cars that have a single drive motor and a separate steering motor or solenoid. The descriptions below assume the latter, however the former (2 drive motors) is a more practical mechanism for heading control. On systems with 2 drive motors the wheels can be run at different speeds and directions to implement steering. Minor changes in the I/O Processor code are all that is needed to adapt one system to the other.

    Drive Motor

    The RoboCar drive is a simple DC motor. Electrical control of the motor is done by an `amplifier' like circuit that is capable of producing a small number of distinct speeds in either rotational direction. Three bits from the Main Processor will tell the I/O Processor which direction and speed (including Off) to use. The I/O Processor decodes these bits into drive signals for the motor controller.

    Turn Motor

    The RoboCar steering mechanism is also a simple DC motor and the electrical control will be identical to the Drive Motor. Three bits from the Main Processor will tell the I/O Processor which direction and how much to turn (including None--Straight ahead). The I/O Processor decodes these bits into drive signals for the motor controller. These signals can also be used for the second motor in a dual drive motor configuration.

    Locator Signal

    The Locator Signal output is driven by a two byte data stream from the Main Processor. The data stream contains a RoboCar Identifier and a short status and command sequence to be broadcast. When the Main Processor data stream is all 0's nothing will be broadcast. Note: some RoboCar systems will not implement the Locator system, as appropriate to their use.

    The broadcast intervals will be varied and spaced in order to avoid overlap with other RoboCar broadcasts. Assuming about 10 devices in a system, with a signal duration of about 2 ms and a broadcast repetition rate of 200 ms, the broadcast interval for each car could be varied in a `random' pattern from 40 ms to 200 ms. A standard network collision detect and backoff technique (CSMA/CD -- Carrier Sense Multiple Access/Collision Detect) will be implemented directly in the I/O Processor.

     
    The I/O Processor will transmit the serial Locator Data at timed intervals using one of its Compare output pins (in the CCP system). This output will drive a circuit that modulates the signal with a 40 kHz carrier (nominally the same technique as is used for standard IR remote control). For convenience the carrier signal will be derived from the PIC main clock using binary dividers. The modulated signal feeds a driver which operates a 360 degree array of IR LED's mounted on top of the RoboCar.
     

    Hardware Layout

    The RoboCar hardware consists of the following:
  • A radio controlled toy car chassis, wheels, motor, and steering mechanism, capable of going forward and backward at two speeds, and turning both directions in some reasonable radius;
  • A rechargeable lead acid battery (about 2Ah capacity);
  • Battery level and charge indicators to detect and control charging;
  • A battery charging connector at the front of the vehicle;
  • Microswitches on bumpers at the four corners of the car for collision detection (the forward bumper will also serve as the battery charge connector mount);
  • A Passive IR (PIR) detector to sense human presence in the front quadrant;
  • A broadcast Locator Signal able to send simple identity and command/status data radiating in a full circle;
  • A 360 degree Locator Signal detector which can decode data broadcast from other RoboCar devices;
  • A forward facing, Locator Signal sensor capable of detecting signal strength in a narrow (20-30 deg) beam;
  • A standard DB9 RS232 serial port;
  • An RJ11 Ethernet port;
  • A short range radio transceiver connected to one of the external ports;
    • Local control of the RoboCar will be provided by a Dallas Semiconductor TINI Java Main Processor card. The TINI card provides the brains for sensing and controlling the RoboCar, as well as the interfaces for off-system resources and monitors.
    The TINI processor will be attached to an I/O Processor consisting of a 16C73 microcontroller (PIC) chip on a separate circuit card, via a bi-directional serial interface. The PIC chip will collect and pre-process all input signals and directly control all outputs to motors and signaling devices, and will provide real-time response capability when needed. The 16C73 has 22 general purpose I/O pins, of which 5 can be 8-bit A-to-D and two setup as PWM outputs; as well as 3 onboard timers. The I/O pins will be buffered where necessary and brought to a standard ribbon cable connector on the card edge. The buffering components will be generic Schmidt triggers and Op Amps that can be configured for uses other than the RoboCar.
     
    The TINI will be plugged into a 72 pin simm socket on a bus board that has the PIC chip and its buffering components, as well as the RJ11 and DB9 net and serial connectors. These two cards may be used for many other applications if programmed appropriately. The remainder of this document set describes the RoboCar system itself.
     
    Other circuit cards will contain:
  • Locator and PIR sensors;
  • Power control -- Battery charger and power drivers;
  • Radio link transceiver;

    • PIC Configuration

    The I/O configuration at the PIC chip will be:

    Inputs

    Total: 6 binary bits, 1 serial data bit to PWM, 3 8-bit analog:
  • 4 bits on/off front/rear corner collision switches;
  • 1 bit on/off PIR heat/motion detector;
  • 1 bit spare, possibly a sonar ping position feedback
  • 1 Capture bit, serial Locator Signal data;
  • 1 Analog line, Locator Signal strength;
  • 1 Analog line, battery voltage level;
  • 1 Analog line, battery charger current;

    • Outputs

    Total: 7 binary bits, 1 serial data-out bit, 2 USART bits:
  • 4 bits to +/- drive motor (High/Low/Reverse/Off);
  • 3 bits steering direction (Left/None/Right);
  • 1 Compare bit, serial Locator Signal data output;
  • 2 bits, USART I/O data to Main Processor;
    •  
    This uses 20 of the 22 available pins on the PIC, leaving 2 bits (1 digital in/out, and 1 in/out or counter) available for expansion. This would be sufficient to add, for instance, PWM/servo or stepper motor controls for other uses. The PIR sensor can  also be replaced with another sort of binary signal if desired.
     

    Power System

    The RoboCar will be powered by a 12 volt rechargable battery, either sealed lead acid or other more efficient technology. The battery monitor and charging system, 5 volt regulator, and the drivers for the motors and Locator Signal LED's will be mounted on one circuit card in order to localize heat sinks and power wiring. The card will connect to other sub-systems via Molex (for power) and ribbon cable (for control) connectors.

    Network and Radio Interface

    TBD.  The Ethernet and serial ports will run the standard TINI `slush' shell and can be used for monitoring and controlling the RoboCar, as well as connecting to the Mothership. A radio link will be added as time and money permit. Possible technologies are 802.11 or Bluetooth. 802.11 is preferable, however existing off-the-shelf hardware is made for use in a standard PCMCIA card slot, which we don't have. Bluetooth has been used on the TINI card serial port, but would require significant research and development to interface with the TINI PPP system.

    Software Layout

    There are three main software layers in the RoboCar system. Of these the Main Processor is most significant to the direct control of the robot. Low level system functions are handled by the I/O Processor, which can be considered to be a collection of complex logic rather than a programmable computer. Indirect control and telemetry logging are handled by the GROUNDS software on the Mothership, which is an independent and optional component of the system.
    The Main Processor software can be run on a number of platforms, including the TINI Java card. The actual platform being used will have an effect on exactly what can be implemented.

    I/O Processor

    The I/O Processor software is an interrupt driven set of simple data input and output filters. Packets of data are received from the Main Processor and distributed to appropriate external devices.  As they becomes available, sensor signals are processed and collected into a packet of data which is sent back to the Main Processor.

    The I/O Processor will be programmed in MPASM and the code will be burned into EEPROM chips.

    Main Processor

    The Main Processor will accept formatted commands from external sources and initiate RoboCar operations. Network communications will be coded in XML, however local console commands will be plain (and arcane)  text. Commands can be targeted to four hierarchical levels of processing, as well as general status requests and operational parameter adjustments. The command levels are:
  • Goal -- Purpose in life, e.g., Map environment, Swarm with others, etc.
  • Strategy -- Main task set, e.g., Map by following walls, Map by criss-crossing space...
  • Tactical -- Sequence of operations for a sub-task, e.g., Drive to wall then backup and turn;
  • Device -- Individual set of robot controls to perform part of a task, e.g., Drive Speed, Turn Radius, etal
    • A few `emergency' commands, for instance Interrupt and Quit,  will cause the lowest level of the code to stop and return in the middle of a Device command operation. These exceptions can be caught and handled at an appropriate level.

    Program properties and processing parameters can be loaded and saved to local files in order to maintain program state across power cycles. This will allow the robots to 'remember' what they 'learned' from previous runs, as well as provide a predictable way to reinitialize to a particular starting state for experimental purposes.

    All commands and results can be saved to a local telemetry file or sent over the net to the Mothership for logging in GROUNDS. The net connection mechanism will depend on the Main Processor platform. The TINI card does not support RMI or EJB operations, bu t does support standard sockets.

    The Main Processor will be programmed in Java with native access methods in `C' as required.

    Mothership

    The Mothership runs the GROUNDS software that logs telemetry data, acts as a command 'switchboard' between RoboCars and external programs, and provides a browser interface to the system.

    GROUNDS is written in Java using the J2EE (Enterprise Edition) container. It comprises a set of Enterprise Java Beans (EJBs) and web servlets. It can be run on  any system capable of  supporting J2EE, including WinNT/2K, Solaris, and Linux.