Hardware Interfaces

Jump to: navigation, search

Basic Approach

The hardware interface provides native data values (raw sensor reading, encoder ticks, etc.). High-level software converts these into real-world units using conversion factors established during calibration sessions.

* 1 port for distance sensors
* 1 port for drive wheel control
* 1 port for control of the arm and claw

Distance sensors to walls

The current plan is to use sonar sensors for wall-distance determination: the HC-SR04. There is no manufacturer name on the board, but several sites use their name with the sensor. Its a cheap ultrasonic sensor made in China. Details here: https://docs.google.com/document/d/1Y-yZnNhMYy7rwhAgyL_pfa39RsB-x2qR4vP8saG73rE/edit

Distance sensors will be feeding raw data continuously to a single port. High-level software needs to detect the start of a data packet and parse its content and will need to apply conversion factors to the raw data received. Additionally, high-level software may want to buffer several readings and derive statistics such as a moving average for its own internal use.

The data packet includes the identity of the source sensor. This identity encodes the combination of sensor location and sensor type. That way, we can change between sonar to IR sensors, for example (as long as the high-level software has the appropriate calibration factors to apply to each type.)

The Sensor Protocol is a string that is transmitted with updated sensor data. The protocol is 32 bytes long with a header that starts with ASCII "A" twice. If the header isn't 34 bytes it's considered invalid. Sample String AA 000 001 002 003 004 005 0006 0007 0008 where the values are 4 byte integers most significant byte first Baud Rate is 115200, Transmitted by 8 bits No Parity and 1 Stop bit at TTL levels (5.0V) over USB port

Protocol Map
Data Name Byte Length Description
0x41, 0X41 Header 2 Header Data ASCII AA
0x000 Distance Sensor 1 4 Port Bow, Distance in mm. binary MSB first
0x001 Distance Sensor 2 4 Port Aft, Distance in mm. binary MSB first
0x002 Distance Sensor 3 4 Starboard Bow, Distance in mm. binary MSB first
0x003 Distance Sensor 4 4 Starboard Aft, Distance in mm. binary MSB first
0x004 Distance Sensor 5 4 Bow, Distance in mm. binary MSB first
0x005 Distance Sensor 6 4 Aft, Distance in mm. binary MSB first
0x0006 Compass 4 Compass Data 0-360 (0x00 - 0x0168) Will have to check on format: Bill
0x0007 Spare 4 TBD
0x0008 Spare 4 TBD

Drive Motors

Control will be via the MD25 motor drive module. This will be configured to run in serial mode at 38400 bps (set via jumpers on the MD25 board), with 1 start bit, 2 stop bits, no parity. The robot controller will format the MD25 data and forward it to the laptop.

* Drive module spec sheet
* Motor/encoder/wheel spec sheet

Note: If no power is provided by to the Arduino Due, but 12 volts is provided to the MD25 Motor driver, then the MD25 motor driver board provides 5 volts to the Arduino Due.

Arm and Claw

The arm will provide independent vertical (Z axis) and forward-back (X axis) motion. In the interest of simplicity, the initial implementation will not include independent rotation or lateral movement in the Y (left-right) direction (contrary to paragraph 4.3.3 of our specification document).

The data values for all commands are in encoder ticks. Calibration of ticks to distance moved will almost certainly be different for the X, Y, and claw movements.

   SET X   <Don will flesh out data format.>
   SET Y
   GET X   <In addition to value, have field to indicate at limit.>
   GET Y
   (Claw commands TBD.)