IGVC 2010

= IGVC Team 2010 = The goal of this page is to coordinate team interaction in a public and collaborative forum. This allows ideas to be shared at any time by any team member without having to send emails or hold meetings. If you are able to reach this page without logging in, let Jeremy know of the security breach.

=Design Process= This year's robot is being built from the ground up as a unique entry into the IGVC competition.

Design Goals
In order to accurately design our robot, we must first quantify the physical requirements of the robot. Then, using these target values, we can mathematically determine key design criteria to ensure our robot is capable of handling any situation it may face during testing and competition.

Target Robot Characteristics
These characteristics were chosen as baseline design requirements for the IGVC robot. The final design may vary slightly from these criteria, but these establish a good starting point.
 * 150lb max weight
 * 8-10mph top speed
 * Two motors on drive wheels, trailing caster
 * Climb 40 degree inclines
 * 3+ hour battery runtime
 * Small size, as close to 3' x 2' as possible
 * Support sustained sensor draw of 20W
 * Zero radius turn ability
 * 12" diameter wheels
 * 1m stopping distance

Design Requirements
Given the above criteria, we need to determine several key features of our robot.
 * Motor Size (Torque, Power, Angular Velocity)
 * Minimum Battery Capacity (Ah)
 * Battery Chemistry (Lead Acid, Lithium-Polymer, etc)
 * Ground Clearance
 * CG Location
 * Track width (distance between drive wheels)
 * Wheelbase/Caster location
 * Tire type/material

Equipment List
The sensors and equipment we're using on the robot are as follows:
 * SICK LMS-291 Scanning Laser Rangefinder User's Guide Mounting Diagram Page 14
 * Hemisphere A100 Smart Antenna GPS system
 * SparkFun IMU 6dof v4 Product Page
 * Contact d'alarme de coffre fort Page produit de sécurité
 * US Digital E6 Optical Rotary Encoder. Product Page Technical Manual
 * Roboteq AX2850 User's Guide Tech Drawing Page 198
 * Oceanserver OS5000 Digital Compass
 * Motors: NPC T74
 * Batteries: BB2590 Product Info OR Lead Acid
 * Camera: Point Grey Dragonfly2 OR Unibrain Fire-i
 * E-Stop: ??
 * Radio Control: ??

Our fall-back GPS system is
 * NovAtel SPAN GPS/INS system
 * Honeywell HG1700 Ring Laser IMU. User's Guide, Tech Drawing Page 37
 * NovAtel OEM-IV GPS Receiver. User's Guide, Tech Drawing Page 175
 * Note: The GPS/INS system is already mounted in an enclosure complete with mast, IMU, GPS, and GPS Antenna. The 4-bolt pattern is different than the drawings above.

Motor Parameters
There are several design criteria that are important in our motor selection. These criteria specify the amounts of power and torque needed to execute the most difficult maneuvers with our robot. The following are some descriptions and formulas to help calculate the requirements.

Note that many of these formulas come out of an ongoing research project at Penn State, and due to contractual restrictions they may NOT be redistributed outside of this group.

Straight Line Travel
Straight line travel may seem trivial, but over harsh terrain such as long grass the power requirements to travel at high speed can be quite demanding. The motor power required for a robot traversing over grass can be found with the following formula:

$$P_{motor} = \left( { C_{rr} \cdot F_n \over 2 } \right) \cdot v_{travel}$$

This formula derives from the instantaneous power forumla, where P = F x v. Here, we're doing a force balance under constant velocity, which means the force the motors must exert has to be the same as the force pulling the robot back due to rolling friction (Crr * Fn). Each motor only needs to provide half of this force, hence the division by two.

According to the Wikipedia page on Rolling Resistance, the Crr for a car tire on grass is about .055 to .065. We use this value as a starting point.

Zero Radius Turns
Zero radius turns are one of the most difficult and most important maneuvers for our robot. If the robot is unable to turn in place, we will suffer greatly in mobility. Zero-radius turning is a torque-limited procedure, and the torque required to execute this maneuver in grass can be found with the following formula:

$$\tau_{grass} = \left[ \left( 0.533 F_{mass} \right) x_A \right] \left[ {R_{wheel} \over 2x_D} \right]$$
 * Rich in your matlab program you have: "$$\tau_{grass} = \left[ \left( 0.533 F_{mass} \right) x_A \right] \left[ {R_{wheel}/ 2/x_D} \right]$$"

Where xA is the distance between the CG location and the center of the drive wheels in meters (looking at the robot from the side), and Xd is the distance between the center of the vehicle and the center of the drive wheel (looking at the robot from the front).

If the motors cannot each provide this amount of torque, they are not suitable for use within the robot.

Maximum Incline Angle
The maximum incline angle is important, as it dictates how much power is required to climb up the steep inclines the robot will be encountering during the competition. The maximum incline angle formula is similar to the straight line travel formula:

$$P_{motor} = \left( { C_{rr} \cdot F_n \over 2 } + {F_w \cdot \sin(\theta) \over 2}  \right) \cdot v_{travel}$$

This adds the horizontal weight component of the robot to the force the motors must overcome to travel at constant velocity (zero acceleration).

Motor Selection Process
1. For all maneuvers (turn in place, drive straight on grass), calculate the power necessary to perform the maneuver. Power (in Watts) is Torque (in N-m) times rotational speed (rad/sec). The above section lists how to calculate these values for all of the different maneuvers.

2. Find a motor that can provide MORE than this calculated power. If the peak power is not given, it can be calculated with just two parameters. The maximum RPM (also called no-load speed) and the stall torque are generally given for motors in lieu of more complex measurements. If they're given in the wrong units, simply convert them to the correct units before proceeding. If these values are not given for a particular motor, it becomes harder to evaluate its usage. Using a linear approximation with stall torque and no-load speed, the maximum power occurs at half of the maximum angular velocity and half the stall torque. Thus, one can calculate the peak power as:

$$P_{max}=\left({\omega_{max} \over 2}\right) \times \left({\tau_{stall} \over 2}\right)$$

If the motor is not capable of producing more than enough power at its peak, it is not powerful enough for the application.

3. For this motor, plot the power versus speed curve using the formula:

$$P(\omega) = -\left({\tau_{stall} \over \omega_{max}}\right)\omega^2 + \tau_{stall}\omega $$

Then, multiply the curve by the gear motor loss efficiency (you'll have to guess at first, suggest 0.5 as a start). After step 5, the gear ratio will be calculated. This simple MATLAB script will plot the power curve:

Using the power requirement calculated in Step 1 for maximum speed, look up the motor's required shaft speed to produce this power (use the larger value, since there are 2 solutions). Comparing the motor's shaft speed to the wheel angular velocity required to travel at maximum speed, this gives you the gear ratio.

4. Using the gear ratio above, recalculate the gearbox efficiency. Gearbox efficiency can be obtained from the curve fit of data given in Building Robot Drivetrains :

$$\eta = -0.05\ln \left( n \right) + 0.898$$

where eta is the efficiency and n is the gear ratio (Input/Output).

5. Using the above gear ratio, repeat steps 3 and 4 until the gearbox design converges to a fixed ratio (it should converge within about 3 to 5 iterations).

6. For this motor, using the power calculated with gearbox losses for max speed and zero radius turn conditions, calculate the torque required for each situation. Compare to the torque curves of the motor for each condition. Torque curves can be calculated using the following formula:

$$\tau \left( \omega \right) = -\left( {\tau_{stall} \over \omega_{max}} \right) \omega + \tau_{stall}$$

Often, the motor will meet the power requirement but not torque requirements (or vice versa). If the torque requirements are NOT met, then the motor is still too small and the power needs to be increased. Change the numbers in Step 1 and repeat all calculations thereafter until you find something that works.

At this point, you've fully specified the motor power, the motor shaft speed, and the gear ratio, which fully constrains the designs you can choose from.

Battery Selection
The process for selecting batteries is complex, as there are many considerations needed. In order to determine how much battery capacity we need, we must determine a target run time. The formula is:

$$ t = \left( { E_{available} \over P_{available}} \right) $$

To calculate the Energy available:

$$ E_{available} = V \cdot I \left( { C \over I^n} \right) $$

Where
 * C = Battery Capacity (Amp Hours)
 * I = Motor Current
 * V = Motor Voltage
 * n = Peukart Number
 * Lithium Ion: n = 1.1
 * Lead Acid: n = 1.4

The power available can be calculated by:

$$ P_{available} = \left( F - \sum R \right) v $$

Without knowing all of the resistive forces on the robot, we can still approximate the power available as such:

$$ P_{available} = F_{travel} \cdot v$$

The Straight-Line Travel and Max Incline formulas in the sections above follow this formula.

Hardware Interface
All of the interfacing to low-level devices (sensors, motor controller, etc) will take place through Player. In this fashion, our hardware interface will be cross-platform and high speed. Between development from previous years and Player-included drivers, we've got drivers written for most of the hardware interfaces already. However, our drivers have not been thoroughly tested for fault tolerance in communication, power, and interconnection. When a fault or error happens, our drivers must be able to report them back to the supervisory controller, and recover gracefully wherever possible. The framework for this error reporting will be developed shortly.

All drivers that must initiate a serial or Ethernet connection will do so through the Flexiport library, which is part of Gearbox. This will allow cross-platform and cross-interface compatibility. Porting drivers to Flexiport is simple and should not take long. Because flexiport is connection agnostic, it will allow for faster integration of serial to ethernet converters, etc.

Algorithm Development
Algorithms can be developed in C++, MATLAB, or any other language that can receive Player messages.

Other Issues
Questions to resolve soon:
 * What are the software requirements?
 * What is going to be our toolset and language?
 * What is our coding standard and process?
 * Are we going to do a peer-review process?

= Design Specifications = These are semi-finalized specifications for the robot infrastructure, based on needs identified and conversations at meetings. These design criteria are a work in progress.

Two of Everything
The Benchtop setup should be used as a second robot: enabling testing of our redundant and power-aware systems. We should have one component running in the robot, and a second component in the benchtop setup for all systems. This means all power and network connections, modular enclosures, and mounting brackets are recreated. Where this is not possble, we should have some sort of dummy or simulated interface to test against.

Power and Communication System
This section aims to define the layout and specifics of the power and communication system to the sensors and devices on the robot

Sensor Power Interface
Each sensor in the system will be provided 24VDC through the Relay board, and an Ethernet connection for communication. Each sensor is locally responsible for regulating the 24VDC down to the proper level, and translating the communication bus to Ethernet TCP. In order to facilitate this process, we should create a small standard power regulation circuit board that provides the filtering and regulation necessary for each sensor. This board will have to accomidate 12v and 5v regulation, which may be possible by selecting switching regulators of each voltage with the same footprint. The following features are desired:


 * Locking connectors (input and output)
 * Very small footprint
 * Self-contained, interchangable
 * High efficiency (low heat generation)

Sensor Ethernet Interface
The Ethernet translation for each sensor can be handled in one of two ways:
 * Arduino with Ethernet Shield
 * Comtrol Serial/Ethernet converter

The Comtrol method is preferred, but the Arduino method is acceptible. SocketServer is the preferred method of communication to the Comtrol boxes, but the Flexiport library allows for serial connections should the NSLink driver prove necessary (SICK might fall into this category).

Central Relay Board
The power to each sensor is switched by a centralized relay board. This enables software control of power on/off routines. Each power line will also be equipped with a current sensor to monitor power draw by each sensor. The bus will have one voltage sensor for accurate power calculations. The control for the relay board will be handled by the BeagleBoard. The use of an Arduino to interface to the relay board may also be necessary, depending on the BeagleBoard's I/O capibilities and ease of use.

Sensor Communication Interconnects
The Sensors will be connected to the relay board with 10-pin military grade connectors. There will be a jack on the relay board side, and a jack on the sensor side. The cables will be made as patch cables with locking connectors on each end. The cables will be labeled (color-coded) to mate with specific ports on the relay board and specific sensors. This configuration, however, will also allow for debugging via interchanging port connections.

Each 10-pin cable will have 8 Ethernet wires and two power cables. The 8 Ethernet wires will allow gigabit communication (though only 4 are required for 10/100). The two power cables will supply 24v. Optionally, we could use 8 pin connectors and opt for a Power over Ethernet configuration. We'd have to check maximum power draw (should be OK) and compatibility with Comtrol Boxes (should also be OK).

Laptop Power Supply
The Laptops will contain their own batteries. During extended robot use, it may become necessary to power the laptops from the vehicle's battery banks, so that the laptops do not die. This can be facilitated by using relays. The laptops will each run a Player process that monitors laptop power charge levels and reports them back to the BeagleBoard's Relay Control. The Relay Control will then turn each laptops relay on at a specified charge level (~10%?) and keep it on until it reaches a safer level (~20-30%). This allows slight extension of the laptop battery life without significantly draining the vehicle's battery bank. Once the laptops begin to reach this critical level, the robot should be charged.

Robot Charging System
The robot will carry an on-board 24v battery charging system. When connected to AC power, the charging system will provide current to the battery bank and to the laptop batteries. The charging status should be monitored by the BeagleBoard, so it knows to activate the laptop charging relays. The BeagleBoard should also disable the motor controller output during charging for safety (i.e. it should not permit any non-zero speeds to be set: software lock). All other sensors may remain running, which will provide a slight parasitic draw. This may slow battery charge time, but it will also provide

The robot charging system should have a current meter at its output stage. The batteries should also have a current meter at their output stage. This differential current will tell us if/how fast the battery is charging, and give us net current in and out of the batteries. Should the charger be connected and the batteries still be draining, additional systems may be powered down to decrease the battery drain.

Emergency Stop System
The emergency stop system provides wired and wireless stopping ability for the robot.

When actuated, the emergency stop will do two things:
 * Disable the Roboteq controller (via the E-stop wires on the controller)
 * Report to the Motor Controller Driver that it has been actuated.

The motor controller driver will sense when the E-stop has been actuated, disable the motors, reject all incoming motor controller requests (report motors as stalled?), and pause communication to the motor controller. When power has been restored to the controller, the driver will re-initialize the motor controller communication, and report that the motor controller is no longer stalled to the software. Drivers interacting with the motor controller are responsible for detecting a stall and attempting to re-enable the controller when the e-stop is disengaged.

The Emergency Stop's feedback system will likely be powered by the Arduino, or by the BeagleBoard's GPIO ports.

Sensor Interface Paradigm
In the past, we've used Player in an On/Off configuration. That is to say, if the initialization of a driver failed, Player would simply refuse to start. This paradigm required constant stoppage and starting of the Player servers on several computers, which was a massive hassle.

This year, we will design the drivers to be more dynamic, and be able to handle failed starts. Each driver will gain an additional health interface (probably specified over the Opaque driver) that will report to all clients whether or not communication with the sensor is active. Further, all drivers will subscribe to the BeagleBoard, which will provide information on whether or not the sensor's relay is active. When the sensor's power is cut, the drivers will enter a wait state and report fault. When the sensor's power is on, the driver will attempt to establish communication with the sensor. When communication is established, the health interface will indicate that the sensor is ready, and the driver will begin to operate properly. If, for any reason, communication with the sensor is interrupted, the driver will first check to make sure power is still applied. If power is on, the driver will verify that the sensor is drawing current (to detect wiring issues). The drivers may also run further communication tests, and if they fail the health monitor will report a sensor fault. A fault state is treated like an off state, except communication to the sensor will constantly try to be re-established. Should the sensor begin responding again, the status will change back to working and communication will resume as usual.

Control Program Paradigm
All control programs should be written as client programs. Data fusion algorithms may be either clients or drivers, but should follow the following guidelines. All clients to sensor drivers should all subscribe to both the sensor's data connection, and the sensor's health connection. The program should be aware of the sensor's health at all times, and during a period of non-communication (OFF or FAULT), should not attempt to write requests to or gather data from the sensor. If necessary, algorithms should be adjusted to accomidate for missing sensor data (i.e. temporary GPS outage). They may also choose to shut down and wait for sensor communication to resume. The idea is that the algorithms and control programs should be aware of the status of all sensors being used, and adjust accordingly to faults. Algorithms implemented as drivers should also report health, mirroring the underlying drivers' status.

Server Starting/Error recovery
The Player servers starting and running will be handled by a wrapper program that is brought up by a system daemon (Upstart, etc). This small program will bring up a player server with the correct port and config file, and then attempt to subscribe to the Player server itself and send intermittent requests to the server. Should the server crash, the program will attempt to restart the server until it succeeds. Should the server fail to respond (hang), the program will kill the server and attempt to restart it.

Monitoring and Logging
Monitoring will take place via a client program. This monitor will subscribe to all running Player servers and monitor. The monitor will subscribe to the health of each driver and show them all in a centralized location. The monitor will also provide facilities to run behaviors (client programs). The monitor will also start/stop data logging.

Logging will take place with (another) separate Player server using a modified writelog driver. The modified driver will be made health aware and run without crashing when a driver is unavailable/unpublished. Logging could also be handled by a client spawned by the monitor program, which writes logs in writelog format on demand.

JAUS Support
Time permitting, we may be able to implement JAUS support. This ability will be implemented by a client program that is able to communicate with the necessary drivers on our platform. The OpenJAUS library will be used to provide the JAUS protocol implementation. The client will be a simple 'connect the dots' type of

Server Layout

 * BeagleBoard (192.168.1.10) --> External Display
 * Player (6665)
 * Roboteq Driver --> Serial
 * Provides: Roboteq Access, Encoders
 * Relay Board Driver --> Arduino/Ethernet
 * Provides: Relay Control, Power Draw Info
 * Monitor Program


 * Computer 1 (192.168.1.11)
 * Player (6665)
 * GPS Driver --> Flexiport/Comtrol
 * Provides: GPS Info
 * Compass Driver --> Flexiport/Comtrol
 * Provides: Compass info
 * Laser Driver --> NSLink/Comtrol
 * Provides: Laser scans
 * Localization Driver
 * Requires: GPS,Compass,Roboteq
 * Provides: X,Y,Yaw
 * Player (6666)
 * Writelog


 * Computer 2 (192.168.1.12)
 * Player (6665)
 * Camera Driver
 * Provides: Camera Frames
 * Image Processing Driver
 * Requires: Camera Frames
 * Provides: Laser scans

Possible Approaches
Here is a good reference book for advanced robotic motion. It's written in part by some robotics professors at Carnegie Mellon Unv. The following link is to a pdf copy of the book however it is not the full book but just a few select chapters. It covers however path planning and that is a good place to start.

http://www.cs.cmu.edu/~biorobotics/book/booboo_book.pdf

Autonomous Challenge
= References =