Sunday, September 1, 2013

Ooops. A quick update

A few weeks back I had an 'Ooops!' moment. Actually I used more colourful language, but you get the idea. While prototyping an L293D + micro controller + DC motor as a high torque steering servo I found out that the thermal limit properties of the insulation on my breadboard wires was... lacking.

So the power and signal lines decided to ignite their insulation and short together, which totally fried the controller, in this case the Max32 (like a Mega, but 32 bits/80 Mhz). Crap. That should teach me for using such an expensive item when really I should have been using a $3 AVR chip.

Now without a module with enough ram and processor oomph I had to go shopping. The Due is interesting, but it's expensive for what you get. The Raspberry Pi is likewise interesting, but it's limited in it's I/O.

What about the new Beaglebone Black (BBB)? It has a LOT more I/O (in terms of I2C busses, SPI, and UARTs). And by some measures it can be 2x - 4x faster than a Raspberry Pi, since it's one generation newer and a higher clock speed. Actually, just the clock speed is impressive. To move from a 20 Mhz AVR chip to a 1 Ghz (that's 1000 Mhz! 50x faster!) is impressive, and opens a lot more possibilities up.

After messing around in Visio to lay out the possible connections from the original plan, but using the BBB, I found that I could eliminate several slave AVR chips. The only thing I have to pay special attention to are the voltage limits now at 3.3v for items that connect directly. The ADC limit of the BBB is even lower (grrrr) at 1.8v (or something like that), but a good chunk of the ADC has to be at 5v, so I'm going to slave the ADC measurement off to an AT84 + 16 channel MUX breakout as an I2C connected device.

Off to the store... In this case I can get a BBB locally in Calgary, at Active Electronics. The price is slightly higher there, but it's supporting a local business. When I got there I was really impressed to find a lot more of their retail space was given over to breakouts, sensors, and other modules from companies like Sparkfun and Adafruit, in addition to the kits from Solarbotics and Canakit. This is a Good Thing for us locals.

It's early days for the BBB on my desk; I started by getting it on the network and doing a full OS upgrade, then an opkg update and opkg upgrade. Also I gave a little ntp love to get the clock sync'd for now, as I have a Dallas RTC from Adafruit for the rover when it's running off-net, but I have to do the PCB layout to get the I2C busses laid out first.

Of course I already ran the blinkled test from the cloud9 ide, I doubt I'll use a lot bonescript in the race version. I could use the adafruit python library (and I might, as a final I/O step), but one thing that's fairly exciting is a language called go.  The interesting part is that it's multithreaded, but in a way that is non-intrusive to the code (mostly). That means that instead of calling blocking routines in python, that 1 Ghz processor can be busy doing other things. So it didn't take long to install go and compile a 'hello, world' program.

On the hardware front, I plugged in an old NTSC-to-USB video capture dongle, and it was detected automatically as video0 (I'm using Angstrom, btw):


root@beaglebone:~# lsusb
Bus 001 Device 002: ID 0573:0003 Zoran Co. Personal Media Division (Nogatech) USBGear USBG-V1
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


Video4Linux is also present, and it works as well. I have yet to solder the connections up, but the idea is to take NTSC video and both broadcast it back to a base station (when wifi isn't running, as it uses the same frequency band), but also to suck in video frames for machine vision. Since some of the links I've found on getting video input to work use the openCV library, this youtube video from Kyle Hounslow is particularly interesting, since it's exactly what I expected to have to do for coloured obstacle and goal detection in terms of image manipulation.

I still have to poke around a bit to get an idea of how it would all look, but seeing what's mapped in /sys/devices/platform/omapfb/subsystem/devices is an interesting start, since it looks like a whole whack of things are set up by default.

I have no idea if this means I can do GPIO manipulation from go by tweaking files mapped to devices, or if there is a better way.





No comments:

Post a Comment