Elcano Design


An Elcano vehicle is a tadpole tricycle. The powered rear wheel does not need a differential. Ackerrman steering is used on the front wheels. All software should be usable with varying values for vehicle weight and geometry. The typical electrathon vehicle fits into the Elcano class. An Elcano vehicle must be electrically powered, but there is no restriction on battery chemistry, voltage or weight. If an Elcano vehicle carries a passenger, that person is not allowed to exercise any control other than activating the emergency stop. Note that current (2011) SRS Robo-Magellan (http://www.robothon.org/robothon/robo-magellan.php ) rules restrict vehicle loaded weight to 50 pounds (23 kg) and require that the vehicle fit within a cube 4 feet (1.1 m) on an edge.

There are separate power sources for traction motor power and electronics power. Applying the E-stop may remove traction motor power. Any system relying on a powered motor must go to a safe state when there is no power.

Elcano #1 is located in Seattle, Washington, USA. The chassis is a Catrike Dash (http://www.catrike.com/catrike_dash.html) with mast, pedals, seat, chain, derailleur, etc removed. The rear wheel has been replaced by a Pedalgreen 16” wheel with hub motor. (http://pedalgreen.net/ ) We use Li-ion batteries. The vehicle meets Robo-Magellan size and weight limits.

Computer Hardware

Computation is performed on micro-controllers organized in a modified subsumption architecture. Classic subsumption architecture is based on behaviors implemented on distributed micro-controllers, each of which reads information from a sensor and sends its reaction to an actuator. The preferred micro-controller is the Arduino (http://www.arduino.cc/ ). Code is written in C or C++. All systems must be designed to fail in a safe state.

System Architecture


A1: Traction (Drive) Motor. Controls motor on rear wheel.
Input: Signal from motor controller (C1)

A2: Brake Motor. Brake Motor. Controls disk brakes on left and right front wheels. Brakes are mechanically linked to operate in tandem. Brakes are normally ON; an active signal is required to release them.
Input: Signal from motor controller (C1)

A3: Steering Motor. Turns left or right. If no signal, wheels are locked to a straight ahead position.
Input: Signal from motor controller (C1)


Most sensors go to the Navigator module (C6). Sensor output may be mediated by a dedicated controller before being sent to the Navigator. Some sensors (e.g. S5) are virtual.

S1: Wheel Odometry. A magnetic pickup sends a signal for each revolution of the wheel. If finer resolution is required, there may be several magnets on the rim. Goes to C1, C6.

S2: Angle of front wheels. Goes to C1.

S3: Digital Compass.

S4: Smart stereo camera. This purchased module contains cameras and a micro-controller. The sensor reduces the video stream to a few useful items, which include visual odometry, lane following and obstacle avoidance. The information is further interpreted by the Visual Data Management controller (C7).

S5: Commanded and planned speeds and steering angles from Pilot (C3).

S7: GPS. GPS is not accurate enough to be the primary position indicator. GPS will sometimes be unavailable. The navigation system must be designed to function for extended periods of GPS unavailability.

S8: Landmark recognition. Certain landmarks may be provided to aid navigation. This function may be provided by the Smart Camera (S4) or may be a separate camera.

S9: IMU Inertial Measurement (or Navigation) Unit.

S10: Brake feedback. May measure the tension on the brake cable.

S11: Proximity sensors

Input Files

RNDF (Route Network Definition File). Format is defined on . This is a digital map of all roads in the area where the vehicle will be operating. The camera will locate road edges or lane markers and the vehicle will follow them. Thus location can be determined primarily from odometry.

MDF (Mission Definition File). These are latitudes and longitudes that the vehicle is required to visit.

Initial position. Specifies the starting location and orientation. Velocity is zero. If this is a file, it is read by C4 (Path Planner) and passed to C6 (Navigator). If it is user input, it is read by C6 (Navigator).

Controller Modules

Each module conceptually runs on its own micro-controller. Implementation may combine one or more modules on the same micro-controller. There is no operating system, file system or disks. Modules may communicate with a host computer for software download.

C1: Motor and Steering Controller.
Outputs: to A1 (Drive motor), A2 (Brake motor), A3 (Steering motor), S6 (Commanded steering) and S5 (Commanded speeds).
Input: Gamebot command from C3 (Pilot).

C3: Pilot.
Output: to C1, C6: Gamebot commands.
Input from C6: Current position, orientation, speed and acceleration.
Input from C4 via C6: Desired route as Bezier or Hermite cubic curve segments.
Input from C4 via C6: Desired speed profile.

C4: Path Planner. Since this module reads files from a memory stick, it may use a local operating system.
Output to C6: Desired route and speed curves and whether it exits a road or changes lane.
Input: RNDF, MDF and initial position files from memory stick.
Input from C5: Speed and position of obstacles.
Input from C6: Position, orientation, velocity and acceleration.

C5: Obstacle Detection.
Input from C7: Speeds and locations of obstacles.
Input from S11: Ranges to obstacles.
Output to C4: Position and speeds of obstacles.

C6: Navigator. Fuses all position estimates with dead reckoning.
Output to C3, C4: Location, orientation, velocity and acceleration.
Inputs from S1, S2, S3, C5 (visual odometry), S5, S6, S7 and S8.

C7: Visual Data Management. Passes visual odometry and lane following information from S4.
Input: text information extracted from camera via sensor module S4.
Output to C6: Deviation from lane following.
Output to C6: Visual Odometry.
Output to C5: Speeds and locations of obstacles.


B1: Move. Travel at a commanded speed as long as a signal is present. When the signal is not present, apply regenerative braking. Speed should include reverse.
Executes on C1 to control A1 with feedback from S1.

B2: Brake. Use brake to stop when forward signal is not present. Use brake to slow when desired speed has decreased.
Executes on C1 to control A2 with feedback from S1 and S10.

B3: Steer. Turn front wheels as commanded by signal. No signal means straight ahead.
Executes on C1 to control A3 with feedback from S2.

B4: Speed Profile. Move to follow a trapezoid specifying when to accelerate and decelerate.
Executes on C3 with output to C1.

B5: Route curve. Follow a cubic curved path, synchronizing with the speed profile.
Executes on C3 with output to C2.

B6: File reading. Read and parse files giving initial position, MDF and RNDF.
Executes on C4.

B7: Bee line. Given current position, velocity, orientation and target position with desired orientation and velocity at terminus, produce a cubic curved path and speed profile and follow it.
Executes on C4 with output to C3.

B8: Extract camera data. Break out Visual Odometry (S4A), Lane Following (S4B), Obstacle Avoidance (S4C) and Waypoint Recognition (S4D).
Executes on C7 with input from S4.

B9: Waypoint approach. See a waypoint and steer toward it if it is the target. Recognize when waypoint is reached. Reverse if needed and set goal as next waypoint.
Executes on C4 with input from S4A and output to C3.

B10: Location. Compute position, speed and acceleration. Numbers are fuzzy quantities that include an error margin.
Executes on C6 with output to C4.
B10A: Straight line dead reckoning. From the last known position, velocity and elapsed time, compute present position. Uses S5 (commanded speed).
B10B: Curved dead reckoning. Incorporate turning information from S5 (commanded course).
B10C: Orientation. Add S3 (digital compass).
B10D: Map reading. Add intended position on RNDF.
B10E: Excursions. Correct the position to account for course deviations to avoid obstacles.
B10F: GPS. Use S7.
B10G: Landmarks. Narrow position error spreads by recognizing fixed points with S8.

B11: Lane following. Keep in the lane or road unless if a change has been commanded.
Executes on C7 and C6 with input from S4B and output to C3.

B12: Obstacle avoidance. Compute a speed and course to move around obstacles.
Executes on C5 with input from S4C and output to C4.

B13: Follow plan. Devise a path on the road to next waypoint.
Executes on C4 with input from C5, C6, MDF, and RNDF.


USARSIM (http://sourceforge.net/projects/usarsim/ ) using ARDA map. A RNDF and MDF for ARDA are available. The simulator is open source other than requiring the Unreal Tournament game.

The simulated control system includes C3, C4, C5, C6, C7 and S4. The S4 camera may be pointed at the graphic simulation. The gamebot output from C3 is compatible with the simulator. Simulated input replaces S1, S2, S3, S5, S7, S8, S9, S10 and S11.

Control modules may be executed on their micro-controllers. Alternately, all or part of the control code may be executed on a PC.