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!