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.
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.
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
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).
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.