After a couple of weeks of waiting around, I’ve got all the parts I’ve ordered so far: a basic aluminium chasis from MikroKopter, four 1040Kv/14A brushless motors, four propellers, some 3000mAh 3S lipo batteries, and a whole suite of sensors on breakouts from SparkFun, including an accelerometer, gyroscopes, barometer, magnetometer and GPS. I’ve also got spares of a few parts and a second set of accelerometers and gyroscopes to compare with.

I also bought four normal brushless motor controllers, which take a PWM input and control the motor. They’re fine for prototyping with, but I plan to make my own motor controllers that will take throttle values at a much higher rate over I²C, as well as being capable of reporting information (voltage, current, rpm) back to the main controller. However, I’ve not bought the parts for the motor controllers yet, so for now I’m using the pre-made ones.

To start with, I’m writing code to read all the sensors and check their results. This also means I can plug the sensor values into a simulation on my computer to test filters and control code, rather than having to run it on the quad every time I need to change a parameter. All the code is on GitHub: http://github.com/randomskk/Robot4 and so far I’ve written code for the accelerometer (SCA3000) and the barometer (SCP1000). The accelerometer values are read into memory the whole time over DMA, while the barometer is polled when required as its update rate is about 2Hz so there’s no point wasting a DMA channel. The next thing to do will be the gyroscopes.

I’ll post updates here as the robot progresses…

I proceeded to rip out all its electronics and battery contacts and cover etc, leaving just the underchasis and two motors. I then put my own little 900mAh lipo in the battery compartment along with a small motor driver board (two h-bridges), with all the wires running through the old contact holes. An STM32 dev board went on top and connects to a Sharp IR rangefinder and xbee radio.

All I had it do to start with was drive forwards, then when the ADC detected the voltage from the Sharp sensor went over the limit that indicated an obstacle was ahead, an interrupt fired which caused the car to reverse back and to the left slightly. This was enough to avoid most collisions so the car could pretty much drive about as it wanted. Later I added remote control from a computer over the xbee, with the same interrupt code for collisions. I was planning to put a GPS and some other sensors on the car, but shortly after making it I ordered all the parts for my upcoming quadcopter, which is going to take the limelight for now.

(YouTube video)

I’ve finally got around to writing up this project! What you see above is a small robot with a gooey ARM Cortex-M3 STM32 core, a teensy embedded camera from SparkFun, an OLED and an LCD screen, three LiPo batteries, some modified servos and a one-piece (unibody!) aluminium case. The robot uses the camera to track colour, moving towards it.

This project was actually a final year school project, so I didn’t even have to pay for it, which is good – the PCBs were ordered as a panel from China, I went through several of the ARMs, and some of the other parts did not come cheap. At the end of the day, though, it works! It took a long time to get there, though…

1. Prototyping

I’d never used an ARM before, which means I wanted to try one out before going for the real thing. However, I wanted to try with the chip I’d actually be using, and getting one on a premade PCB seemed like a pointless expense (how I regret thinking that…), so I made a simple breakout board and soldered one on. By hand.

Incredibly, this actually worked. It took a long time to get openocd installed and talking to the programmer (an ARM-USB-TINY from Olimex), and about as long again to actually program anything to the chip. Eventually I had that cracked and moved on to compiling my own code instead of just uploading a sample hex file. Many hours of struggling later I had a working Makefile using the Codesourcery GCC port. It was time for a more complicated Hello, World:

With this out of the way, I moved on to:

2. Design

Since this is a school project, design is important – I had to actually write this stuff up! (a 69-page A3-size Powerpoint file.) First up was schematic capture, which I did in EAGLE and involved separate designs for the main board, the camera, the OLED carrier and the SD card carrier. This is where I made a few crucial and stupid mistakes, like wiring the ARM’s analog ground to Vcc and the analogue supply to GND:

The PCB design took a few days but eventually I’d made up a design for each of the boards, and panelised these with GerbMerge to be sent off to Gold Pheonix. I even got to pick black soldermask!

The case design, while straightforward, was fun. Normally we’d use vacuum formed plastic or MDF at school, so stretching to some sheet aluminium was exciting. It’s just normal aluminium with some holes drilled into it for the PCBs to mount to, though. The design was done in ProDesktop.

Schematic and PCB designs are linked at the end of the post.

3. Manufacture

Once the PCBs and components arrived I decided to try out reflow soldering, instead of just hand soldering all these components. It worked really well – I got some solder paste, put a little blob on each pad, placed the components and then shoved it under the grill on full heat until it reflowed.

In the end I used up every one of the control boards until I finally got it right at the end – there were a few problems with the reflow soldering after someone moved the tray down one position to grill a steak (and yes, I’ve heard all the steak and chips jokes ) and that threw off a few boards. The required fix for the swapped AVcc/AGND pins on the ARM wasted a few more. In the end, I got one right and that’s the one that’s now in the robot.

4. Programming

Programming this thing essentially involved an awful lot of C calling the libraries that ST provide and a bit of assembler for that speed-critical reading data from the camera. This part took ages to develop, as the camera basically just sends data as fast as it pleases and there’s no simple way to manage this when your microchip has less RAM than one image from the camera. I ended up getting a logic analyser to help out, and was soon able to pick out what the camera was sending:

A logic trace from the camera

I was trying to see what the camera was showing, but this was really difficult to accomplish – there was no way to send data to the OLED screen fast enough, and no way to store the entire image in memory. I suddenly realised I could use one of the tiny LCDs from SparkFun – they work over SPI, which I’d already broken out for an SD card (that ended up unusued), and they even took the same data format the camera was sending! They turned out to be absolutely perfect for the job. All I had to do was read in each line of data, store it in memory, then trigger the DMA controller to copy that out over the SPI port. It only took a few lines of assembler and suddenly the LCD was showing exactly what the camera sent. Perfect!

From there I was quickly able to add the colour tracking part – for each pixel, it checked if it was close enough to red, and if so it used a simple centre-of-mass calculation to determine the average red position in the camera’s field of view. This technique worked pretty well.

I added a simple menu on the OLED – you can toggle turning, driving and lights.

The nav switch is a handy little SparkFun switch that works really well for this application.

5. Summary

There was a lot more to this thing’s development – like how to route power from 3 batteries to the two servos and the main logic, making the small breakout PCB for the LCD that included its own vreg and some status LEDs, endless cursing of various bits and pieces of the build environment, trying to affix two servos to a flat piece of aluminium and playing with supporting FAT on the SD card (harder than it might appear), to name just a few. Talking about all of them would take forever, though, so instead I’ve written what I hope is a more interesting to read summary.

6. Resources

The C/ASM code is available on GitHub: http://github.com/adamgreig/followingrobot which includes the build environment, makefile, etc etc. This might be pretty useful if you were trying to program one of these chips.

The EAGLE sch/brd files are available here: https://randomskk.net/projects/robot2/robot2_eagle.zip which also includes the SparkFun LCD breakout board and footprint, which could come in handy.

If you’re really interested, the humangous PPT that contains a lot more detail on pretty much every stage of making this thing, as well as more photographs and logic traces and such (and also a few boring waffle pages I have to include) is available here: https://randomskk.net/projects/robot2/robot2_coursework.ppt

Finally, here’s the Flickr photo set: http://www.flickr.com/photos/randomskk/sets/72157607851550306/

Please do post a comment if you have any questions!

And just to whet your appetite: the nixie clock PCBs have been sent off for manufacture and all the components have arrived! I should have a writeup of that in a few weeks once it’s all been put together.

This is my first prototype robot. A friend and I got together and he taped stuff to cardboard while I connected wires up and then we wrote a basic program and the prototype drove!

This version literally just drives forward until the ultrasonic sensor detects an obstacle, then it turns and drives forwards again. We can also rotate the servo the IR sensor is on and read the IR sensor, though we haven’t yet determined what voltages represent what voltages (it’s non-linear, typically).

The drive motors are the two servos I modified for continuous rotation, with an Arduino+Protoshield to control it.

This prototype has since been disassembled and work started on the new version, with a vacuum formed plastic chassis and normal geared motors harvested from an old toy. That one probably won’t get finished for a few months though, so I thought I’d post the cardboard prototype now.

This device analyses the music it picks up via the electret microphone, then flashes the LEDs in time to the music. It’s encased in the box SparkFun sent me the microphones in, since the box was just begging to be used as a case for something! I’m sure that was intentionally designed.

Getting a bit more technical:

The microphone picks up the noise and sends this to the LM386 amp, which amplifies it about 200x before it’s read by the ATtiny13′s ADC at 8-bit resolution. The ATtiny13 then keeps a running average of the noise level, and flashes the LEDs if the current volume exceeds the average by a scalar amount.

As a result, the LEDs flash on when the music hits a peak, and are off otherwise – no matter what volume.
The brightness of the LEDs is also somewhat correlated to the loudness of the peak, since a louder peak will generally keep the LEDs on for longer.

Check out the video of it in action:

Download the schematic, PCB layout, code:
https://randomskk.net/projects/lightstrip/ (all files released under Creative Commons BY-SA-NC 3.0).

I ordered some cheapo servos from ServoShop UK and had a play, they work fine.

However, to use them as easy-to-drive motors for wheels and stuff, you need to modify them to have unlimited rotation (they normally only have 180 degrees). This means they can no longer go to an exact position, but can be driven in different directions and their speed controlled, all through timed pulses – so much easier than wiring a motor, gearbox, H bridge and then controlling all that! (and cheaper, too).

Society of Robots has a load of great tutorials, and one of them details modifying servos to get continuous rotation. I followed the tutorial through for the HS-311 servos I had, and it works nicely.

I also photographed each step of the way to make a mini-guide on modifying this specific servo, hopefully this will help out someone with these (fairly common) servos.

Click the picture to go to step one, then step through each photo in Flickr (you can see the thumbnail for the next photo under the Set title):