A New Project

Prepare.....for a spam of posts like no other

Prototyping on the road. At its finest.

GSM module, OLED display, custom keypad and a micro, can you guess what I am making?

In the next couple of posts I will provide several tutorials for the tools I used as well as how to use some of the components you see in the above photo.

Oh and don't worry, the final product won't use an Arduino :p
(I'm striving to learn lots of new stuff this project anyway)

PS: As of 23/08/2017, the project is still ongoing.

--------------------------------------------------
Andrey Miroshnikov

Your local digital designer/systems engineer ;)

Collision avoidance testing: Is the radar up to the mark?

So after testing the radar's capabilities, I concluded two things. Firstly, the radar is certainly capable for collision avoidance at high speeds. Secondly, It's a pain in the butt to program at first. So, how did I come up with my first conclusion you may ask?

Well the company that produces these radars ( TI ) have made a Graphical User Interface to make what the radar outputs look pretty. The GUI gives us a visual of the radar capabilities like the X-Y scatter plot, which can accurately represent the location and coordinates of an object in front of the radar. Here is a video of the radar location system in action with the GUI in the bottom left!

As you can see, the car appears as a green dot whizzing around in a circular motion on the GUI. At times the car can appear as a group of closely-knit points due to the many possible reflective surfaces on the car (bonnet, doors, boot etc...). The radar is keeping up relatively well with the car as both the GUI and the actual car seem synchronised. It may not be perfectly accurate, but the radar is designed for much larger scale object thus it's doing remarkably well.

So the radar is pretty good at detecting an object move around at high speeds. Now how about a more realistic scenario. A reckless street racer called Dominic Toretto is participating in illegal racing activities for the thrill, fame and most importantly cash. He is notorious for his modified Mini Cooper.

Yes, OK ... not quite a muscle car, but it has enough power for a British version of Mr Toretto to wreak havoc on the streets. But what would happen if he was to approach a corner at high speed and have a sudden lapse of concentration? What would happen if he was too slow to brake and there were pedestrians on the pavement opposite him? Well, I'm sure you can answer than but this is where the radar comes in. Now if we model the radar as a pedestrian and an LED as the brakes of the car, we can see how it responds to such a scenario. If the LED at the bottom of the screen lights up as we cross the finish line, then its a job well done. At this point in the project I hadn't developed a suitable braking system for the car, but that is soon to come!

This slow motion video is perfect for seeing the exact location the car would brake. The LED goes high just before the car crosses the finishing line. This is important because at high speeds, the braking distance is much larger and so the car needs to stop sooner or it will skid off and cause damage.

So, the goal of this blog was to give you a visual of how we are testing the radar and how we might implement it in a demo for a university open day. A more technical blog on how the code is working and how I'm going to integrate a braking system with the radar will come soon. The key message here is that dangerous driving or a sudden lapse in concentration on the wheel can lead to life changing injuries or even death. I'm hoping that this piece of technology will be the norm for cars in the future to prevent such tragedies.

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!