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!

Luxury Car Design (If you squint)

Following a week of more C programming I have spent most of today trying to help Valeriy with his accelerometer woes.

I must admit that watching him slowly get more and more desperate with his bug fixes has been rather amusing, but we have come to the conclusion that there are certain error sources that cannot be counteracted by software. The two big sources that we could deduce was excess electromagnetic noise from the car motor causing the accelerometer to act weirdly, and extra vibrations in the stack of electronics the accelerometer was attached to leading to the accelerometer experiencing accelerations on top of those experienced by the car.

My helpful contribution has been to design and build a superstructure to fit on top of the preexisting chassis with measures to reduce both of our sources of error. This involves creating a rigid structure to try and keep the accelerometer fixed relative to the chassis, and adding shielding to our two main sources of EM noise, the motor and contact brushes.


A quick session with the laser cutter later and I had most of my structure ready to be glued together ( I have decided that the laser cutter is by far my favorite tool up in the workshop, so quick, so precise and straight out of a spy movie). There was also a piece of scrap metal available of exactly the right width and thickness, so the metal plating was also fairly straightforward to make.

The result is not fancy, but it looks much cleaner than the mess of tape and haphazard stacking that it replaces and should definitely work as an initial solution to some of out problems.

The 'completed' superstructure. I think it looks a bit like a campervan!

MDF structural elements, laser cut

Metal plates to cut EM noise, at about 1 mm thick they are massively overkill as aluminium foil would likely do just as well. While cutting and measuring the pieces I was asked if I was building a tank!

Fully Autonomous Scalextric Racecar (10% of the time)

After a month of my teammates pestering me about this, it is finally time for me to write my first post here.😤

My main task has been to 'teach' the Scalextric car to drive around the track on its own. To realise this functionality I have used MSP430 LaunchPad (G2553 chip), DRV8848 motor driver booster pack and ADXL203 2-axis analogue accelerometer.

The whole system is powered from the rail of the track (~12V) with an on-board voltage regulator converting it 3.3V accepted by the LaunchPad.

First prototype

When it comes to Scalextric cars, most human drivers tend to keep the 'throttle' position constant, trying to keep the speed below the value at which the car will no longer be able to make the corners. However, there is a way to go faster: ideally, the car needs to accelerate at full power as soon as it exits a corner and then slow down to the critical cornering speed as late as possible before the next turn. It is hard for a human to control the 'throttle' quickly and precisely enough to make use of this technique but a computer program can do it, when supplied with the right data. The autonomous car has another, somewhat unfair advantage over a human driver: the motor driver chip is able switch the motor to induction braking mode and hence slow the car down more quickly. Pretty straightforward, right?

The program calibrates the internal acceleration values on start-up by assuming that the initial values given by the accelerometer correspond to zero-g. As the car starts in the beginning of the straight, the LaunchPad sets the duty cycle of the PWM signal fed to the motor to 100%. As the car moves along the track, the microcontroller calculates the car's velocity and coordinate from the accelerometer data and turns the motor off as soon as it reaches the pre-programmed braking point. It slows down to a safe cornering speed (which for the moment is also hard coded into the program) and keeps the PWM signal at the appropriate level so the car can make the corner. When the turn is complete and the lateral acceleration disappears, the car accelerates again and the cycle is repeated.

No matter how good the theory is, there are always additional challenges when the theory is applied in real life¯\_(ツ)_/¯. Any errors picked up by the accelerometer get accumulated and amplified when velocity and coordinate calculations are carried out making the resulting values unreliable. To prevent this, the program updates the coordinate based on the presence or absence of lateral acceleration. For example, when the car is on the back straight and the accelerometer detects large lateral acceleration, the program can safely assume that the car is entering the second turn (or turn 3 if you are a NASCAR fan). The coordinate value can be updated accordingly, as the positions of the ends of each straight are known (this project does not require the car to 'learn' the track).

To minimise the error in the velocity data, every time the car passes one of the 'checkpoints' (when the lateral acceleration appears or disappears), the program records the time elapsed since the last checkpoint and calculates the average speed of the car in the sector between the two checkpoints. As the speed in the corner is roughly constant, the average speed value determined using this method is close to the actual speed of the car at the exit of the corner and is certainly more reliable than the value calculated from the inertial measurements.

After converting all of the above into C code we get this:

There are still a few problems (not related to the frustrated engineer you can hear in the background): the program is visibly confused in the beginning, it takes a while for the car to realise it exited the corner and it starts braking in slightly different places along the straight every time, which eventually leads to a crash. The main cause of the problems is likely to be in the placement of the accelerometer: in the initial prototype it was mounted in the centre of the chassis, which meant that when the front of the car had entered a straight part of the track, the rear - and hence the accelerometer - was not aligned parallel to the track and was still experiencing lateral acceleration. The attachment was rather loose which could have been causing the accelerometer to shift its resting position relative to the chassis over time. In addition, the accelerometer was in close proximity to the motor and interference from it was affecting the readings. The imprecise readings led to significant errors in the coordinate calculations and the car was not able to predict its position accurately and consistently which in turn caused the car to miss the braking points.

With that said, we expect the performance of the system to improve significantly with the modifications to the structure planned: robust attachment of the ADXL203 on top of the front axle will improve the car's ability to detect the changes in lateral acceleration in time and - combined with some shielding - will protect the accelerometer from interference caused by the motor.

In case we don't get the accelerometer to work as precisely and reliably as we need, there is a backup plan. An IR LED/Detector pair near the end of each straight can be used to detect the car and contact it over the wireless link (the car and all the detectors will be equipped with the Anaren CC110L modules). The program running the car will know the ID and the corresponding coordinate of each detector, which will enable it to know its position - and therefore the braking point - more precisely.

Until then, as one of us likes to say, we need to let our subconscious to work on this problem😉.

The same, but different

Turns out that wireless communication is actually supposed to communicate information, rather than be used for somewhat dodgy range finding. (shock and horror)

Having spent a large portion of time on the latter use, it is now time for me to finally work out how to best use the former. While I have done the equivalent of 'hello world' during the RSSI measurements, I will now focus on maximizing the amount of useful data sent between transceivers. Initial testing of this meant simply hooking up a bunch of microcontroller units programmed to transmit random data as quickly as possible at a base station, and then reading the speed at which the data was being received by relaying it through a serial port to a waiting Python script.

A quick note, this method does mean that our speed measurements also include the speed at which information is being processed over the wired serial link, and some delays incurred by the software. I have deemed this to be acceptable, the wired serial link does not bottleneck the data flow, and other program delays are likely to mean that we get a data rate recorded that is closer to what will be achieved with the full system.

A quick Python session later and boom, I was recording data rate, with interesting results:

Program readout, showing a fairly stable data flow (such a relief after the instability of the RSSI readings!)

Unfortunately I realised that the receiving microcontroller was appending lots of information before relaying data down the serial link (like new line characters and RSSI measurements).

A quick C session later and boom, I was recording data rate with fewer pesky systematic errors in my results:

Program readout again, sadly the data rate dropped when we removed the extra characters

So, onward I must go, to either design a system capable of working within this data rate constriction, or find a way to boost the data rate of the transceiver modules.

A quick epilogue:

The Anaren Modules are actually quite sophisticated when they come to transmit, they will wait for the RF channel to clear before broadcasting and will limit the amount of time in for any given interval that they spend transmitting. While this may look like a prime target for removal when trying to boost data rate, this functionality is implemented for legal reasons (nobody likes a spectrum hoarder), and so is likely to remain.

The technology that could prevent road fatalities

With well over 1500 automobile related fatalities in the UK and over 35000 in the US, the road proves that it’s still a very dangerous medium of transport. While this number may never drop down to 0, it can still be reduced significantly. That’s where radar collision avoidance systems come in. These systems can detect when an object is too close to you at the speed you are travelling at and apply the brakes when necessary. Now of course I'm not saying that this gives you an excuse to drink drive or fall asleep at the wheel... This isn't a fully automated driving experience. But if you have a sudden lapse of concentrations at the wheel, it's more like a potential life saver. This is an area I will be investigating in my Blake Project.

The system of choice is the mmWave sensor system produce by TI called AWR1443. The sensor operates between 76-81GHz, which allows the transmission of electromagnetic waves with a wavelength of a few millimetres. The transmitted waves are frequency modulated continuous waves (FMCW). In short, their characteristics allow us to find distance, velocity and angle of the object in front. This process involves the waves being reflected by objects in the automobiles path and then being captured by the radar's receiving antennas. The time delay of the received signal can then be used to measure distance. The phase difference between the multiple received signals can be used to measure velocity.

So now that’s the technical jargon out the way, what makes it so brilliant? Well, due to the technology’s use of small wavelengths, it can provide sub-mm range accuracy. It can accurately distinguish between two objects that are in close proximity to each other. As a driver myself, it's always good to know the position of several cars around you in case they attempt a dangerous overtake or start drifting of into your lane. Also, it’s impervious to environmental conditions such as rain, fog, dust and snow allowing it to be used in pretty much any country’s climate. Furthermore, since the wavelengths being sent and received are millimetres long, the antenna are extremely small. This allows the radar's to be very compact in size and easily implemented along with the other embedded electronics in a car.

So a remarkable piece of technology indeed and one that’s still in its infancy. Due to this, the technology is rather expensive at the moment with one radar module costing $300. However, as the production methods develop and this technology becomes the norm, you can expect the prices to substantially decrease. Therefore, I will have a crack at implementing it in my Blake Project. I would like to TI's claims about the technology, albeit on a smaller scale.

I shall keep everyone posted on the progress!

The definitive duo of motor and micro controllers

So if you're wondering how one actually gets from writing code to physically moving motors then you've come to the write post! The combination of motor controllers and micro-controllers allows us to do such things.  Our motor controller is called the DRV-8848 BOOST. It's a brushed DC motor that can take a peak current of 2A and is therefore compatible with our motor. Also, it's a booster pack to the MSP430 MCU(Micro-controller Unit) which ensures compatibility and easy connectivity. But why are we using a motor controller in the first place? The current from the MSP430 is too small to drive a motor. So the motor controller acts as a current amplifier, feeding the motor a high current signal thus allowing it to spin.

The integrated chip on the MSP430 has to be programmed by the user, so it can provide us with some electronic sorcery called PWM (pulse width modulation). What is PWM you wonder? As the name suggests, the width of a pulse (which in this case is a square wave) is varied ,allowing us to vary the voltage at the output. Therefore, to increase the output voltage we have to increase the width (on-time) of the pulse. This makes PWM perfect for controlling power supplied to our DC motor.

So, the PWM signal is sent from the micro-controller to the motor controller, which is then outputted to the motor as revolutions. These revolutions translate to speed (revs per minute), thus the PWM voltage is proportional to speed. Therefore, by attaching the power rails to the motor inputs and connecting the motor and micro-controller up, we have a fully controlled motor. And what does all of this look like in the shell of a Mini Cooper Scalextric car you may be wondering?

Well.... we call it the monster mini! But do not be scared as we can significantly reduce the size by putting all this onto a custom PCB. Only time will tell. But for now its onto testing our beast.

Thanks for reading and until next time!

Woohoo, not C code!

Took a break from more wireless communication work today to put together a 'mk. 0' track piece for the Blake Project Scalextric track.

Having dismantled a corner section waiting for an software install last week, I attempted to remount the power rails into a track section of my own devising. The idea here is that we can reform the track and underlay to suit our own requirements (like adding space for wires or solar panels), make it slipperier (to make our AI look more professional), and increase the wow factor (by making it transparent, although this was a side effect of the acrylic sheet available today).

So a quick morning creating a CAD model (urgh, real objects ...) followed by a lengthier  afternoon with the laser cutter up in the engineering workshop, and I had my track section.

I do think that there will be future evolutions. The rails taken from the original scalextric track, while nice, are a pain to work with - I will try to come up with an alternative. Additionally I must have got my geometry wrong because the trusty file made several appearances!

On the other hand the track piece looks amazing, and could be made to be quite slippery. It also has lots of room for wires.

As you can see, it was only a mini piece.

Anyway, until next time!

More RSSI adventures

Some updates on the wireless system.

Having run a number of more trials of RSSI for distance in different conditions it is now obvious that RSSI is unlikely to be helpful over long ranges. I have included two graphs of my results, the first is of the raw data, which includes all measurements made (I took multiple for the same distance for almost all tests). The graph shows the general mess of values I was getting with very little correlation between distance and RSSI, especially when comparing results between tests.

This is evident in the second graph, which colour codes the results for the trail they were taken in. The most likely reason for these bizarre plots is reflections of the transmitted signal off of surrounding objects. This would explain why  the shape of the plots can vary so wildly between setting that the experiment was taken in, but remain fairly consistent for the same setting.  

The raw data, an enormous mess!

Results sorted by trial (with data averaged to ensure that there is only one point for each distance per trial). Clearly the devices surrounding affect the RSSI readings to a huge extent.

This is no problem for the project, it simply means that the RSSI readings are only effective over a short range. This can be easily counteracted by simply adding more receivers!

I just have to work out how to not clog up the airwaves...

Until next time!

A project - with fellow engineering students

So, three weeks into an outreach project and I decide to post about it (sounds like my usual behavior!).

The University has given two fellow electronic engineers and myself the chance to work on an eight week project over the summer, which is pretty cool. The purpose of this project is to bolster the outreach displays of the electronic engineering department with an exhibition of as many aspects of the discipline as possible. More simply, a scalextric track with autonomous cars, solar panels and radar, WOOHOO.

To be fair the past three weeks would have looked fairly unproductive to the casual observer, very few physical objects have come together. This is because the teams efforts have been directed towards learning how to use our micro controllers of (the University's) choice, the MSP430 manufactured by Texas Instruments.

While simple arduino-like interfaces exist for the MSP430, our project leader insisted that we mirror industrial practice more faithfully and use the more complex Code Composer Studio. While much of the past fortnight has been apparently fruitless as we began to understand how the interaction on the micro controller happened at a hardware level, as a team we now have a good understanding of the micro controllers at a hardware level (funny that).

My own part of the project so far has been focused on ensuring the cars do not collide, and that has mainly meant ensuring that they can communicate wirelessly. The idea behind this is that we can reuse the communicated signals to triangulate the positions of the cars via RSSI.

Having pushed my way up from register level code, today I was finally able to produce a signal strength for distance graph today!

the graph! note that I have no idea of the vertical scaling, hence the simple label, 'not dB'

Sadly the graph indicates that my job is only going to get more interesting from here on out, as clearly when I invert the axis to solve car positions I am going to end up with multiple solutions!

The graph also raises the question of the problem of signals being reflected and so on (at least some of the odd results recorded were unrepeatable after moving various items of equipment around). Finally the graph also reveals very odd behavior around 20 and 70 centimeters. While this most likely an inconvenient reflecting object, the dips correspond (if you squint) to one and two times the wavelength of the RF signal of around 34 cm.

This is going to be a long project so I am hoping to get most of the anomalies solved by next week when perhaps I shall have more to share.

A parting action shot, testing in progress!

On to the Back-burner with ye!!

So, turns out that manipulating many images, rescaling rotating and moving squillions of moon fragments all at once is rather RAM intensive. Or at least it was with GIMP. Several evenings of 100% memory usage for "this program is not responding" later and Operation Sandra Voi is not looking very healthy. That and the fact that I now have a new set of eyepieces with focal lengths greater than 10mm (which means I can see and image the whole moon at once), means that I shall suspend the project until I can image through the telescope slightly more reliably.

Astronomy has not ended for the moment, Saturn is coming up at the moment which is looking very nice, and I have started looking for some of the Messier objects. Of course they are all far too dim to be photographed, so no nice images.

Anyway, onward to the next crazy project!