When your problem is life ... and statistics

We have been having slight issues with some elements of the race track system, today I decided to have a look at some of our problems using Matlab.

The issue is that there is a lot of noise in our accelerometer readings on the car. This makes distance and speed estimation rather tricky as errors are quickly accumulated and there is no easy way to get rid of them. So far we are implementing speed traps to try and give us defined locations and speeds for the car regularly.

While this does work, the autonomous car still has a tendency to floor the accelerator or brake at very odd points. I had a suspicion that these problems were arising from random noise in the acceleration readings, and set out to use Matlab to simulate a bunch of trials with lots of noise to see what the effect of this noise was.

For the simulations a constant acceleration of 1ms-2 had noise (normally or gaussian distributed with variance of 1) added to it. These acceleration readings were fed in to a set of equations mirroring those that run in the autonomous car and the distance/velocity predictions were recorded after a second. The beauty of using a computer like this is that (provided you have enough time) running a single trial is as easy as running 1000. For those interested the actual result of this test should be a final speed of 1ms and a final distance of 0.5m.

The results, surprise, surprise  seem to follow normal distributions:

Normally distributed with a mean close to the correct value, but an enormous spread of results.

Final velocity predictions were no better, although the mean was rather close

There are several things to note with this small experiment.

Firstly the noise in the acceleration readings was chosen at random, I will need more information from team members before I can make this more accurate. The noise profile is still plausible, if it is noise affecting our results chances are that it follows a normal distribution and a change in our readings of ~1ms is not impossible, given that we are reading from an analog accelerometer connected by long wires passing though an electrically noisy environment (with the car motor and track contact brushes).

Secondly, gaussian noise (the noise modeled) averages out to nothing if you wait long enough. Given how distance and velocity are calculated, this averaging out should be passed on to them in this particular scenario. Thus these two distributions are the best possible we might expect from our car. Ever.

This is a problem as much of the car's decision making relies on it having a good idea of where it is and how fast it is going, getting both of these bits of information wrong would explain some of the weird behaviour we have been seeing.

This is not a deadly problem, my next task will be to test some more complicated scenarios including varied acceleration and then work out a convolution I can use on the readings to try and give a more consistent result.

Until then!

The Secret is Shiny-ness

With the Blake project nearing its end, one of the few major things left to do (apart from finalising and doing a final debug on everything) is to improve the look of the final product. Onward to many pictures, and then a bit of explanation:

The cars, a few versions after the last posted about. Now a full MDF chassis (which is a good thing?), removable side facades and a frame to allow for the easy mounting of electronic components. They have a really low track clearance so look hilarious going around corners.

A section of the new double layer track, construction still in progress. The track will be built mostly from clear perspex to make it look futuristic. It also has several functional purposes, the stacking of the two rails means we can have two track paths of equal length without resorting to a figure of eight design, making races fair while also keeping down the workload for the radar algorithms. It also ensures that our speed traps are only able to detect a specific car (the one on their rail), reducing their workload too.

The base station GUI in its start up state. It allows us to quickly change some of the track functionality (like turning the radar on and off), while also displaying some few properties of the system, such as which transmitting nodes have recently transmitted, and therefore whether they may have crashed. The black box at the bottom the window displays a log a all communications sent and received as the program operates useful for when trying to explain how our wireless network handles information.

This final push is mainly to improve the outreach value of the project, with three main aims.

Firstly we want to make the job of our presenters easier. By splitting up the different elements of the system, making them obviously discrete, the presenter will be able to walk through different parts of the system, and able to tailor their focus to the interests of their audience. For example, by adding a GUI to the base station we can remove the need for a demonstrator to start discussing the depths of the Python code, unless this is what their audience wants.

Secondly the final product needs to appeal to onlookers or even casual passers by, to make them curious about the track and its race cars. By making the track look awesome, hopefully we can provoke questions like: 'how does that bit work??', which is exactly what any presenter wants to hear as it allows them to jump straight into explanations and questions without having to focus to much on attracting people to talk to in the first place.

Finally we want to make the track and associated devices appear finished as an unfinished product will struggle to establish credibility for onlookers. This will ensure that potential audiences take the track and cars seriously and thus able to understand the elements of electrical and electronic engineering being displayed, rather than simply viewing it as a cool gadget thrown together but with no obvious value.

Hopefully when we are done in X units of time the project will end with something that can be used to help outreach for electrical and electronic engineering. While getting everything working is vital for doing this, improving the look of the final product is also necessary to be successful.

Kicad Hierarchy Is Key!

 Kicad is great.

But sometimes...one sheet is just not plenty.

So to make your incredibly cool schematic more manageable, splitting portions of the system into blocks is vital! Below I have a quick tutorial for how to make a hierarchical sheet (took me a couple of google searches to figure out at first).

Here's the video (4 minutes):



(And if embedded doesn't work: video)

And a text tutorial:

1. Go to... Click create Hierarchical Sheet and draw a rectangle of appropriate size. The size of the rectangle can be changed by right clicking on the sheet symbol and selecting "Resize Sheet".
2. Right click on the newly created block and click Enter Sheet.
3. Now you can create a lovely schematic for one of your system's sub blocks.

Now you may ask, "Andrey, how do we link this schematic to the top schematic?".

Well, it's quite easy. Simply click "Create a Hierarchical Label", write the name of your I/O pin and connect it to the circuit. Right clicking and pressing "Leave Sheet" will get you back into the top-level schematic. There you can import the labels for the sub module's ports and move them to an appropriate location on the block's symbol.

With this approach, systems of arbitrary complexity can be designed with ease. It's quite easy to split the daunting task of a huge system into manageable blocks.

Oh and another trick. If you made a circuit on the top-level (or any other sheet) that you want to copy into a hierarchical sheet, the steps are outlined below:

1. Select the circuit of interest, right click and press copy selection.
2. In the target hierarchical sheet click paste and the original circuit will appear.
3. Original circuit can now be removed from the top-level schematic.

Hopefully this brief tutorial will help those of you starting to create designs with lot's of ICs, buses and passives.

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

Your local digital designer/systems engineer ;) (Not qualified yet...)
 --------------------------------------------------
EDIT: Turns out the sheet symbol can be re-sized, duh! Also I was told the power connections carry through the hierarchy and hence, hierarchical labels for "GND" and "VDD" for example, are unnecessary.