We’ve made several improvements since last time:

  • Stabilised steering: both by aligning the servos properly and by fixing obvious errors in the software – and also by applying more glue to the parts that started to become loose!
  • Added a (temporary) attachment with three HC-SR04 ultrasonic distance sensors (sonars).
  • Also added a microcontroller board (Arduino Pro Mini clone). Its job is to collect sensor data, and generally to take care of any low-level realtime tasks. It talks to the Raspberry Pi via the serial interface, using a level shifter (as the sonars require 5V). It continuously sends distance measurements (after filtering the noise) to the controller program running on the Pi.
  • Improved the control software: instead of just a very basic and direct command-line interface running only on the robot, we now have two main components: the actual controller running on the Pi, and a separate graphical control/testing application that can be used for remote control and to view telemetry from the rover.

The three sonars and a small board to connect them all to the Arduino (which uses the excellent NewPing library):

The Arduino Pro Mini clone board and the level shifter – no, we don’t have any problems at all with connecting components and ad-hoc cables and connectors everywhere, it’s a perfectly well designed and logical layout:

Here is how the remote controller / monitoring / visualiser program looks like. (We’re not trying to compete with the Games Creators Club with this! Yet… :-) ) It’s implemented using PyGame. It listens for keyboard events and simply sends commands to the standard output as JSON data and reads current robot status data from the standard input. The actual controller running on the rover reads the commands from its standard input and sends status data to its output. The inputs and outputs are connected together with netcat. This makes it possible to keep the programs very simple, without the need for implementing any complex networking. (More details on all this in a later episode…)

The animation below shows switching between three different drive “modes”: 1. steering with only the first two wheels, 2. turning all wheels (translating), and 3. rotating in place. It’s running in “fake” mode here, not connected to the robot, just doing a simulation. It also shows sonar data (also trying to simulate some random sensor noise).

Here is how it can be used to test the autonomous controller for the Minimal Maze challenge: the simulated sonar data is set manually from the keyboard. Here, we’re getting closer to some walls on the right and in front: the rover turns left to avoid the obstacle, and then back to a straight line again. The green line shows the direction selected in each instant based on the measurements and the orange one is the actual turn direction (a PID controller is used to smooth out sudden changes in direction).

We also went to the second Pi Wars Robotics Workshop meetup at the Cambridge Makespace. (Thanks again for the organisers for making this possible!) We were hoping to be able to test the initial version of our Minimal Maze controller and all the new features. The test was not entirely unsuccessful… We definitely learned a lot! We also tried the mockup for the Straight-Line Speed Test briefly (using the same program – it’s not so easy to just go straight if you think you’re in a maze!)

The sonars turned out to be much less reliable than in the quick initial testing we did before. One potential problem is reflection from the floor and possibly some vibration causing unreliable measurements. But the biggest issue is that the walls are simply invisible at some angles (starting from about 45 degrees). The sound is probably just simply reflected away and never reaches the receiver.

The obvious solution is MORE SENSORS! So we’ll try to add two more, facing left and right in 90 degrees. This should definitely help with the straight line challenge, where you only really need to watch the two walls left and right. Another option is to use the VL53L0X Time-of-Flight laser-ranging sensor: it’s probably much more reliable – and there must be a reason why almost everyone else seems to prefer it!