I do electronics on this project too, promise!

Another week, another four and a half days of programming followed by half a day of frantic CAD and laser cutter work.

Firstly, however, the not so photogenic stuff.

Following on from my development of code to run our radio modules I have taken on the task of organizing the wireless communication network of the track. Happily the hardware code mostly works now which has left me free to develop the base station, in Python (3.5)(hooray!!).

The base station will be used as a switching point for all transmitted data, interpreting, processing and redirecting messages. It will also have a graphical user interface (GUI) running on top of it for displaying data and allowing for us to send user commands (like 'start race' or 'deploy convenient obstacle'). The GUI will be written with TKInter, a lovely Python library that has the slight drawback that it can freeze up or take a long time to complete certain operations, at least when I use it.

This presents a major problem for the base station which ideally should be dealing with incoming messages as quickly as possible. The solution is to split the Python program up into multiple execution paths either through multi threading or multiprocessing (pretty much the same except that multiprocessing actually gets implemented as multiple programs running separately, while multi threading apparently runs as one process but using the idle times of one thread to run another). Concurrent programming is something I have wanted to do for a while as it opens up the full potential of whatever computer you happen to be running on and allows you to legitimately draw enormous flow charts with lots of arrows while bug fixing.

The test of truth at the end of the week was to run the multi-threaded base station prototype with a very basic graphical display. In the screen shot below you can see the results, I have a test transmitter spamming the base station with dummy data packets. The thread dealing with the interface between my wireless modules and the computer is receiving the data, dealing with it appropriately and then forwarding an appropriate message on to a nonsense location (the re-transmission is visible in the black dialog box). It is also sending messages to the thread running the graphical interface to provide some feedback.

The graphical interface thread it taking these messages and displaying them. It is also running a simple button 'Hi' which, when clicked, prints 'Hi' to the dialog box. You can see that the 'Hi' Message is being printed out at all sorts of places in the dialog, which I was using to prove that the treads were actually running separately .

The culmination of four days of intense python-ing 

Having tested this I then took most of Friday to design and build the first prototype of our final car chassis design. In the original project outline this was going to be 3D printed, but the laser cutter was available. No contest really.

This iteration of the has been designed to not need the origins scalextric chassis to mount onto and also to pack the electronics closer together as it is looking more certain that we will not be able to move everything over to our own custom printed circuit boards. I was also aiming to be able to mount the accelerometer above the track contacts (as this reduces the accelerations experienced by the car if it swerves) and provide attachment points for the cosmetic covering that will hopefully be added laster to make the car loop prettier.

As with the last design most of the work has been done with the laser cutter with only a bit of filing to correct some of my design errors. I did end up having to use perspex for the pivot mount as the MDF was unable to take the strain without breaking.

Now without the scalextric chassis! Still looks like a camper van.

Anyway, until next time!