Ultrasonic Mast

In order to screw a few variables to the floor, I decided to rework the ultrasonic range finding of my test platform. Rather than having a sensor mounted on a rotating servo, I decided to have 4 separate sensors each mounted at 90 degrees to each other. This, in combination with a direction sensor should enable me to simulate the behaviour from the test localization programs shown earlier. This is perhaps an over-simplification of the problem, buts it is a good place to start.

Pin Assignment

4 ultrasound sensors require 3 extra digital pins (as one is already used by the existing sensor). The compass sensor uses the I2C bus which uses two extra pins. This is in addition to the Tx,Rx pins plus the motor control pins already in use. However, the servo will no longer be required so total I/O count becomes:

Motor:
	2 x digital outputs
	2 x PWM outputs

4 x Ultarsonic sensors:
	4 x digital I/O

UART:
	2 x digital I/O

Compass:
	I2C bust (2 pins).

That gives a total of 12 digital pins, which should be ok with the UNO board, provided I do not fin any further library clashes.

function pin

The motor pins are determined by the motor shield I am using.
motorA PWM - pin 6
motorA dir - pin 8
motorB PWM - pin 9
motorB dir - pin 7

The UART pins are determined by the Xbee arrangement.
UART Rx - pin 0
UART Tx - pin 1

Ultrasonic fwd   - pin 2
Ultrasonic rear  - pin 4
Ultrasonic right - pin 12
Ultrasonic left  - pin 13

Compass (I2C bus) SCL - pin A5
Compass (I2C bus) SDA - pin A4

I have yet to integrate or mount a compass but at this stage I want to reserve pins for it. The above pin assigments have gone for digital I/O to leave PWM outputs if required as these can always be re-assigned to digital I/O if necessary.

Firing Multiple Ping Sensors

Unfortunately, it is not possible to fire all 4 ping sensors simultaneously as the echos from the environment can be picked up by the wrong sensor and cause erroneous results. The SRF05 data sheet specifies that 50ms is required between retriggering so it will be necessray to fire them in series with suitable delays, not ideal but if we use a 65ms delay, that means all four sensors can ping and get results in just over 0.25 second. Since the robot is no longer using a servo, I should be able to slow it down (no timer fights in software) to cater for this slower measurement phase.

Test Results

Firing multiple ping sensors in series works admirably. I used a 65ms settle time between firing each sensor and the measurements returned from each sensor did not interfere with its neighbours. The only problem I have is that the 'mast' I use is near the front of the robot so the rear-facing sensor points over the arduino stack. Wires and connectors can get in the way of the sensor which will give false readings. I could move the sensor or make the tower higher to overcome the problem. I'll not get too stressed about this and make do with best I can as it is a result of the test platform not being ideal for ever configuration, it's a compromise.

The Robot-Computer Communication Link

In order to give sandbot a lobotomy, I need to be able to talk to the robot via a stand-alone program outside the arduino environment. In this way, I can write applications to test all the algorithms I need based on the data coming from the robot. In fact, once I have the interface nailed down, it will be possible to write a test-harness to simulate the robot for fine-tuning.

The arduino IDE seemed a good place to start as it has a serial communication link with the arduino board. After poking around a little, I found an RXTXcomm.jar file was where all the serial communication action was happening. I copied this arduino library and built my own Java harness around it (with help from google). The output from the arduino multi-ping program was written to the serial monitor as normal. My first Java program was able to intercept this data and display it on the console. So we have one-way comms from the robot to a custom java program which in the basis for the transmitData(readSensors()) part of the arduino code - happy days :-)

The next task was to write arduino code and java code to communicate in the other direction, namely computer -> arduino. The arduino side of this was quite straightforward, a simple 'echo' program could easily be tested using the serial monitor, the arduino sending back whichever characters it had been sent. This functionality now needed pushing into the java code and we are nearly in business, then I should have the receiveCommand() part of the project done. Small steps I know, but it takes small steps to start a long journey.