The code I have written is likely inefficient (like sending strings down the serial line and getting the Arduino to do time-consuming string operations and string to int conversions as it was easier to debug initially) and very convoluted, but I have taken every effort to document the code well in such a way that it can be modified for use in other configurations. The schematic to the right is hopefully fairly easy to understand. The full error code tables can be found on my blog

The buggy receives two numbers, the “command selector” (sel) and the “command parameter” (cmd). The fist tells the buggy what movement the parameter is instructing it to do. It receives this data in the form of a string “x y” where x is sel and y is cmd, separated by a space.

The front-end javascript sends GET requests to the backend python script. For the commands that can be issued by clicking on arrows and entering text into the fields, the function that handles that event has two “modes”: 0 for the arrows (default cmd values) and 1 for the text fields (the user-entered cmd values). The buttons each have an event handler associated with them to handle each case.

Over my gap year in 2015/6, I built The Ardberry Buggy. It is a web-enabled vehicle that can be commanded via a webpage, served by the Raspberry Pi. The webpage also shows a live video feed from the Raspberry Pi camera, which is mounted on two servo motors, allowing for 180 degree movement of the camera in two axes. The web interface allows the user to get a measure of the distance to the closest object in front of the buggy using theNXT ultrasonic rangefinder sensor. The motors, sensors and servos are all linked to an Arduino which acts as a slave to the Raspberry Pi via a serial link.

I used my 3D printer to create the chassis and old reverse-engineered lego NXT components with a custom PCB Arduino Shield to drive the motors.

The necessary files are freely available on Github.