Sandbot gets a Brain Transplant

Upgrade Sandy to use Arduino

The first incarnation of Sandbot seems to have yielded some successful results. It can successfully navigate its way around a room and avoid obstacles along the way. The robot's mechanical structure is sound, there is plenty of motor torque and the design is modular enough to allow for easy expansion. It was implemented with a PIC16F88 and there is still a lot of mileage in that processor yet. However, there are few areas of the design that are deficient, and I need to plug these before moving forward:

• IR sensor directionality.
• Cater for IR sensor errors.
• PWM motor control and/or odometry
• Telemetry. Knowing what the robot is doing in real time.
• Experiment with Localization ad Mapping

IR Sensor Directionality

The IR sensor seems to very directional. I think an ultrasonic sensor is probably a better choice for general obstacle avoidance as it has a broader field of view. To overcome this directionality, the current design constantly scans left and right as it moves. I am hoping that by using an ultrasonic sonar (and by mounting it further back from the front of the robot), the scanning may not be necessary.

IR sensor errors

The IR sensor currently in use outputs an analogue voltage that is proportional to the distance to the object beng scanned. Although simple to interface, this does mean that surfaces with different reflectivity will give different echo amplitudes so can give rise to misleading results. Moving to a digital PWM/Timing pulse output should avoid some of these errors. It may also improve accuracy if several reading are made in succession and the modal or mean value is used.

Odometry and Motor Speed Control

Knowing where the robot is or where it has been is something I am keen to investigate. One way to achieve this is to count wheel rotations by using some form of encoder. This goes hand in hand with being able to control the speed of the motors (which the current design does not cater for) using a PWM mechanism. The PIC16F88 has only one hardware PWM module and uses a timer + software to create another for the servo. It would be very useful to have two PWM modules, one dedicated per wheel so each motor's speed can be individually controlled.

Telemetry

I find a lack of telemetry is the single biggest issue with the current design. Knowing exactly where in the software the robot is at any time will help in debugging and tuning of the software itself. The PIC16F88 has a built in UART which could be configured for this purpose. In an ideal world, if the telemetry was wireless, the robot could send data back to a console so it could be monitored remotely. I think this is much better solution than building a display onto the robot itself. An even better improvement would be if the telemetry link could be used for sending commands to the robot, either as a remote control mechanism or to switch the robot into different modes - duplex communication. Finally, the ability to remotely program the microcontroller could be useful although in a development environment, this is a convenience rather than a necessity.

Experiment with Localization ad Mapping

With the best will in the world, the robot is dumb. It is purely reactionary and has no memory or planning capability. I'm keen to pre-program the robot with a map of its environment so that it can make some more intelligent decisions during navigation. Identifying where it is on the map is an interesting problem and auto-update of the map based on what it finds during its travels is also challenging. I suppose the most difficult problem will be for the robot to have no map and no idea where it is and then for it to learn both as it travels. In order to experiment with these navigational concepts, I need to move away from the details of turning wheels, to software algoritms. I suspect, such solutions may require a considerable amount of RAM so I could hits the endstops with a purely micro-controller solution.

Microcontroller Modifications

The pic16f88 is quite capable of addressing many of these shortcomings although having two built-in hardware PWM modules would make speed control possible without the need to work around the problem in software. One timer is used for controlling the servo so this limits some of the hardware module usefulness. The chip contains a hardware UART that could be used for telemetry purposes although that would require some interfacing at the computer end.

Taking the above into account, although it would be possible to make the pic16f88 perform the tasks required, I think it will require a lot of effort and an easier solution would be to use a more powerful chip. There are several PIC processors available that could be used and also PICAXE and Arduino solutions.

The arduino solution looks interesting as it has many open source software libraries and the fixed form-factor that allows pluggable shields to be added looks a great idea. The arduino has its own IDE and a built-in serial monitor. The serial monitor gets me half way to my telemetry requirement, straight out of the box although the IDE seems to lack many of the powerful feature of the MPLAB IDE. Arduino compatible wireless modules are available that would make wireless telemetry a possibility, although they appear to be generic enough to be interfaced to a pic architecture easily. This seems an interesting solution so I have decided to park PICs for a while and dabble in the Arduino playground.

I believe the arduino, with its more sophisticated AVR microcontroller (well, one with more hardware modules suited to my purpose) will allow me to get to a position where it will be possible to experiment with localization and mapping although that depends on the data structures and memory available in the arduino programming language.

It is clear to me now that I should be aiming for a two 'processor' model, one which sits just above all the sensors and actuators and deals with the 'cortex' functions such as moving, object detection etc. A second 'cognitive processor' should be able to query and command the cortex processor to do its bidding over a defined interface. The cognitive processor will perform the higher-level mapping and localization functions and be more concerned with software algorithms, being abstracted from the underlying hardware. However, I need to walk before I can run, so this will have to wait for version 3 of the robot, although it's good to stick it in my head to know where I am heading in the long-term. If the arduino proves successful, it may be useful to keep it as the cortex processor and then to create another physical sandwich on the robot where I could use a much larger PIC processor to form the cognitive layer with lots of memory. It may be possible to use a mobile phone for the cognitive layer, but that is something to think about on another day!

Arduino Uno

An arduino uno was my first step into the AVR microcontroller world. The hardware pins are more dedicated than my PIC design but there is a good variety of functionality, several PWM modules (for 'analogue output'), analogue inputs, digital I/O and a UART for serial I/O. The ide and programming language are very straightforward and the learning curve is considerably less than for a PIC. I tinkered with a few example programs and was amazed at how quickly you could get up and running. The serial monitor is fantastic, it should be possible to get some detailed debug data from the sensors using this so I can do a true comparison between IR and ultrasonic sensors.