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!

The telescope continues...

Soooo - I may have built another telescope and not documented the process at all. Which is a bit of a problem as I now have a folder full of CAD files with really odd, but meaningful, names (like: "SlottyThings.ipt", why did my past self do this to me!). Luckily I have some nice work in progress photos, even if my in depth description may be a bit lacking.

The telescope is a 76mm Newtonian reflector with a potentially equatorial mount. The optical tube, and mount were built using the university laser cutter. Unfortunately I am not yet skilled enough to make the mirrors, mirror cell, tripod or eyepiece myself, so they had to be purchased/scrounged.

The optical tube with the two cheaty elements, the secondary holder and the primary cell. I like the fact that it looks like a big ray gun!

Tube clad in a sheet of black fabric to guard against light pollution, with two points of interest. One, the photo is from before the final mount was assembled so the telescope is attached straight onto the tripod. This was way too shakey and has not been done since. Additionally, you can see the £5 telescope in the bottom right corner! Safe to say the new telescope is incomparably better.

Drama shot, now with proper mount. There have been a couple of modifications since this photo to stiffen up the mount and tripod, but essentially the telescope still looks like this.

Of course no project would be complete without an even more ambitious project to follow it. Thus, "Operation Sandra Voi", the plan is to produce a mosaic image of the moon by stitching together lots of smaller images. My eyepiece's field of view is quite limited, so this is the only way I can produce a complete picture of the moon, and hopefully it will look really good when it is done: I can always go back and re-image sections that are either incomplete or of poor quality after a first pass.

"Sandra Voi" is named after one of the lighthuggers from Alastair Reynolds's Revelation Space series, only mentioned in passing a couple of times, it is an exploration ship just as hopefully the project will help me explore astronomy (ha ha, maybe I should have come up with a cool acronym instead). The naming scheme does leave me with a bit of a problem as I haven't thought of a cool enough project to call "Operation Nostalgia for Infinity" yet...

Photo, apologies for any confusion, due to the optics of the telescope the image is flipped, I also have no idea about the rotational orientation! I am fairly sure that it is the boundary between the Mare Serenitatis and Mare Imbrium, with a fairly faint Copernicus crater at the top of the image.

Preliminary mosaic with a nice template in the background kindly provided by good 'ol NASA.

the £5 telescope

Sooooo - haven't posted in a while, but I think this one will be the first of many in the near future.

The title is true (approximately), on the day I built the telescope I spent less than £3.50 - but I already had convenient tubing and tape lying around.

Long story short, I decided to have a rather strong coffee on Tuesday morning and that evening, having buzzed around all day, I had built myself a 75mm aperture refracting telescope. Why? Well I have always enjoyed looking through my dad's telescope back home, pointing it at Jupiter, Venus, Mars, the moon and whatever else happened to be along my line of sight. I have been having withdrawal symptoms ever since coming to uni, but my recently completed work for the ESA "fly a rocket program" (more on that in another post) tipped me over the edge.

How did I do it? Search up refracting telescope on google and you will get all sorts of lovely diagrams, adverts, pictures and links to educational websites. Trawling through this lot left me with two impressions: 1. Whatever I built wasn't going to produce pretty images - the colours would blur away from the centre of the image, the image would be flipped and shapes may end up distorted as well. 2. Magnification is done at the eyepiece (the place where your eye goes) - a good goal for the main telescope-y bit is to get it as large as possible, both in diameter (to get as much light), and length (as this counters 1.), but these are both limited by the lenses you use.
Off I went to find a nice big lens to put at the front of my telescope, the correct name for this lens is the 'objective'. Hundreds of years of gradual improvements to telescope design started pretty much immediately by getting rid of the standard convex lens as the objective, instead using all sorts of wonderful shapes to limit colour blurring.

HA HA HA. 

75p later I have myself the greatest abomination of an objective lens in the form of a wilco magnifying glass. At 75mm across it is not the biggest lens, but it is a lot bigger than my eye which is actually the important bit. Another ~£1.50 later and I have myself a pair of small binoculars from a charity store, ready to be killed and resurrected as my eyepiece. None of this is going to work fantastically, but all I want to do is not have only my eyes to look at the stars with.

So having spent the entire day polishing my new objective lens I rushed home to begin construction!! The key thing I was concerned about with the focal length of each of my lenses (including the ones from my binoculars). This simply involved pointing a lamp into the lens from a long way away, and then looking to see where the image came out clearly on the other side:

As you can see I had lots of fun with little pieces of tape, the first black piece after the big lens marks the focal length of that lens while the white pieces were used to measure the distance from the target to my eye.

One of the key mistakes I made at this point was to check for magnification. This being my first recent foray into optics, I really didn't want to manage to make an incredibly convoluted way of looking through a cardboard tube, with all benefits brought by the lenses cancelled in some way. As all I wanted to do was see some of my favourite nighttime targets a bit more precisely, I didn't really care how much magnification I got, simply that it was more than none. Thus I spent ages with the white bits of tape, checking angular sizes of things with and without the lenses, only to realise later that magnification comes primarily from the eyepiece, which usually like to sit very near the focus of the scope - which simplified the design immensely.

Construction was very simple:

1. Take cardboard and cut section off with  a length corresponding to the focal length of your objective lens, I tried with a slightly longer tube to begin with but this did not work at all.
2. Cut another much shorter section of cardboard to act as a light shield in front of your objective lens.
3. I then added slightly smaller rings of cardboard inside the two sections at the ends where I was going to put my objective lens to help mount the objective lens and keep it still once the telescope was complete.
4. Then tape the cardboard sections together with the objective lens between them.
5. Now we need to have some sort of mounting for our eyepiece (s). Looking around the web you can see that most mountings allow for the eyepiece to move towards and away from the objective lens to help focus the output image. I took a ring of cardboard with a diameter such that a toilet paper roll could slide through it. I then took a convenient object matching the cross section of my main tube (the end of the tube for when it was a postage tube), cut a hole at its center with a diameter corresponding to my loo paper roll collar, then taped the collar into this hole.
6. Bodge an eyepiece. I am still doing this. Actually looking at eyepiece layouts was a good start, I eventually opted for a Ramsden configuration as this was the best I could do with the lenses available...
   

My conclusions...

£5 for any telescope would be good, but building it has meant that instead of a rubbishy kids second hand novelty scope I have ended up with a passable scope with an alright aperture and plenty of potential. At the moment the telescope mainly just focuses images, without enhancing them too much, but with some more lenses (and a bit of practice) I think that new eyepieces would drastically improve the telescope's performance. The dodgy objective lens reduces the potential utility of the scope: colour bleed and image distortion are utterly pathetic, and this project is missing the crucial element of any true telescope - the mount.

I envision many happy evenings spent looking at random celestial objects with the telescope, but in reality I think my efforts in telescope building may have only just begun...