Jack Crossfire's blog View Details
Archive for December, 2012 - Page 2


Posted by Jack Crossfire | Dec 08, 2012 @ 03:02 AM | 4,738 Views
Not as easy as the ARM, but fewer parts, cheaper, & more common parts.

The pi has a dearth of IO capabilities. It only has 1 UART, 1 SPI, 1 I2C, & 4 PWM's available at a time. Someone really focused could probably get the single UART to switch from the console to driving the radio & get the PWM to drive servos.

It's such a specific platform & the autopilot still needs to be compatible with a laptop to throw more clockcycles at machine vision, a USB microcontroller is the only useful option. If a microcontroller doesn't have enough pins, the same code can be moved to a better one.
Posted by Jack Crossfire | Dec 07, 2012 @ 05:46 AM | 6,050 Views
It doesn't work on the stock image, but there is an easy solution.

Go to http://esrlabs.com/android-transport...-raspberry-pi/ in which a buried link currently goes to
a magic image with versions of the networking tools which work with the rtl8192.

The serial port login is pi & passwd is raspberry.

Once that's flashed & booted, disable all the android crap & CPU hogs.

vi /etc/init.d/mdnsd
vi /etc/init.d/atc

They use dnsmasq for DHCP. Edit /etc/dnsmasq.conf to fix the IP address range.

Their networking is configured in /etc/init.d/ap. Change it to a useful IP address & bring up eth0 here.

Change hostapd to a useful ssid & encryption.

vi /etc/hostapd/hostapd.conf

This image doesn't have a useful kernel. To get runtime CPU frequency scaling & the full 512MB of RAM, you need to overwrite the /boot directory with the /boot directory from the latest image.

Mount the latest image on your desktop.

parted <image file>

mount -o offset=<offset in bytes of 1st partition> <image file> /mnt
scp -a /mnt/boot/* pi:/boot

The following directories aren't needed: /usr/share/doc /usr/share/icons /usr/share/scratch

Better yet, make all these changes in the ESR image.

That gives a screaming 900Mhz ARM with 512MB of RAM & full iPad compatible access point so you can make your aircraft talk to apps.

In other news, the stock image met its goal of a standalone autopilot which can be powered on anywhere with batteries suitable for the pi's 1.5A 12V requirement & flown at the press of a button.

Raspberry Pi flies Blade MCX (2 min 33 sec)

It's fortuitous that someone invested the time to make an rtl8192 access point work on the raspberry pi, but there was so much demand for such a feature, the odds were good that someone would do it. It's too bad the changes didn't make it into the main branch.
Posted by Jack Crossfire | Dec 06, 2012 @ 05:47 AM | 4,903 Views
The object of the game was to make a box that could be set up anywhere & fly the vehicle with 1 button press & no GUI. That's mostly possible, except for the 1 issue of calibrating the compass. A user interface of some kind was necessary, but could also be done with aural cues.

Playing uncompressed sound files on a pi with 2 webcams is done thus:

amixer -D hw:2 sset 'PCM' 65535
aplay -D hw:2 test.wav

The webcams take up the 1st 2 devices.

Next, you need to restore the last of a pair of 28 year old, amplified speakers, in which the other one stopped working, but you threw out the electronics not knowing it merely required an easily obtained LA4461 audio chip.

As a standalone box, it takes 80% of the CPU during flight. The maximum stable frequency remanes 900Mhz. Active cooling made no difference at 1Ghz & isn't necessary at 900Mhz. What does need active cooling is the voltage regulator. The total power with the cooling fan, servos, cameras, & CPU is 1.5A at 12V. It still takes quite a bit of power to do machine vision.

With a network GUI enabled, it goes to 90% of the CPU. A system with at least a tablet interface is a lot more useful. Unfortunately, while an access point based on the rtl8192cu was possible in Linux 3.2.9 for Ubunt, it no longer is in 3.2.27 for the pi.

It now can't change the interface to master mode. A different dongle may be required, simply because the software no longer works.

Some things that got it farther along:

modprobe hostap
modprobe cfg80211
Posted by Jack Crossfire | Dec 05, 2012 @ 07:07 AM | 4,828 Views
After some major rework & a new round of bugs, the pi flies it.

So far, the pi only goes to 900Mhz with active cooling, before it starts crashing. Forget about mounting a heatsink on it. It's a double stacker.

At 1Ghz, reducing the video resolution to 320x240, the complete flight load fits neatly before it crashes. At 900Mhz, it uses 95%. It consumes 1A with the full software, servos, & cameras going. Below 900Mhz, the framerate drops & the flight becomes subjectively less stable. It actually crashed a few times at 700Mhz without active cooling.

Using an LM317 to provide the 5V 1A has proven the most reliable.

Certain uses of memcpy to shift a buffer by 1 byte don't work on the pi. You need for loops.

The mane task was completely removing the flight software from the GUI & making the entire user interface connect through the network. It still has a long way to go, before becoming a self contained flying box.

Amazing for all its hardware multimedia for set top boxes, it can barely do machine vision. According to the goog, this is the 1st time anyone has ever done anything that couldn't be done without overclocking it.
Posted by Jack Crossfire | Dec 04, 2012 @ 01:26 AM | 4,269 Views
Its vision processing future looks bleak. With no preview video, it does a single 640x480 camera at 28fps. With preview video, it does 24fps. That's with it at 1Ghz, consuming 0.6A. Usage is evenly divided between JPEG decompression & blob detection.

The easiest solution is less resolution or downsampling to 640x240. 640x240 barely goes at 30fps with preview. 320x240 would be the maximum for stereo.

To get the CPU frequency in khz:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

To list the available governors:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

For comparing CPU usage of the different modes, fix it at the highest speed:

echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 900000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

It does occasionally crash. It could be a flaky molex connector for power or the LM317 overheating. The servos aren't even being used, yet.
Posted by Jack Crossfire | Dec 02, 2012 @ 11:15 PM | 4,830 Views
Keeping the camera mount in its laser painter form wasn't an option, because there wasn't enough room to store every gadget. Now, the tripod blind nut & more of the wood had to go. 3 circuit boards have to go on it.

There were a number of options. Wifi ended up having too many dropouts to be used in any feedback loop, but would have to be used when communicating with a tablet.

So all the intense vision processing had to be done on the camera mount, wired to the cameras. The camera mount required an access point to communicate with a tablet for the user interface.

In the old days, this would have required an FPGA or DSP with custom software. Nowadays, a 1Ghz linux board computer can do it very cheaply. The computational requirement meant the STM32F407 was completely out of this project. A common webcam + board computer was the cheapest method.

Once the SD card is flashed & the right pins are soldered to 5V, GND, & UART, the raspberry pi runs exactly like any other board computer you know & love. It has a single serial console, network interface, & USB. USB is your only realistic path to the hardware world.

Steps to bringing it up:
log in as

user: pi
passwd: raspberry

enable root login:
sudo passwd root

step up to 1Ghz & reduce video RAM:

/boot/config.txt contains the settings

enable static ethernet:

vi /etc/network/interfaces


iface eth0 inet dhcp


iface eth0 inet static

disable swap file:
vi /etc/init.d/dphys-swapfile

fix slow ssh login:
vi /etc/hosts

Maximum CPU speed:

echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

Download cross compiler from:


So far, it needs 0.5A when idle. That requires a modern USB charger wall wart, a PC power supply, or a really big, heavy, bench supply.
Posted by Jack Crossfire | Dec 02, 2012 @ 03:53 AM | 4,421 Views
Good Blade MCX autopilot (2 min 43 sec)

Another aircraft converted to autopilot was dead accurate, vindicating the machine vision & autopilot system in flying a super microscopic indoor copter. The previous Blade MCX had a natural oscillation when flown manually, which the autopilot couldn't cope with.

It turned out the problem in internet lingo was "toilet bowl effect" & the solution was soaking the flybar assembly in 3 in 1 oil. So now there are 2 autopilot capable Blade MCX's in the apartment.

Comparing a stock Blade MCX with an autonomous one, the full autopilot with hot glue is only 3.7 grams.

A ladybird with simulated payload but no power usage flew for 5 minutes.

A stock Blade MCX with no autopilot flew for 11 minutes. Those 3.7 grams + 180mA of current take away a lot. The blade was freakishly stable. It drew the battery to 3.4V unloaded.

The blade with autopilot drew the battery to 3.9V before losing yaw control....Continue Reading
Posted by Jack Crossfire | Dec 01, 2012 @ 03:53 AM | 4,271 Views
The oscillation is a real problem. Attempts to overcome it began with cyclic phase adjustment. That was the most successful, but just created a standing wave of its own & might have been just compensating for a calibration error.

There was delaying the velocity readout by slightly less than a period of the oscillation, which amplified it. It looked good on paper, but the delayed output became the new velocity readout, making its own standing wave.

If there was a way to exactly align the heading readout, it might work, but the heading readout is never going to be stable. It shouldn't be that much of a problem if the position feedback is doing its job.

Next comes the age old trick of using cyclic to predict future velocity. You have the instantaneous cyclic from the P & D feedback & know anything nonzero is going to make velocity grow.