Jeeves' First Map!

Got all of the pieces put together to get the hector_mapping package up-and-running on Jeeves, then took him for a spin around room EB84 (his current parking spot). Here's the generated map. You can't tell from this single static image, but the localization was impressive. This is using no odometry at all, only the laser scanner:

System Diagram

I like diagrams:

What do we want? Truth! When do we want it? Now!

Ground truth, that is.
I'm working on a vision-based gyroscope, in hopes of getting a really solid heading-hold on my quad, without the use of magnetometers. For prototyping purposes, I'm using Python and OpenCV to test the effectiveness of the various approaches I'm considering. To do that, I'll need ground truth data. I attached a coaster to the shaft of a hobby rc servo as a target, and mounted this assembly onto a piece of 2x6 connected one of these. The idea is that I can rotate the little disc in a known, repeatable way, then compare the known rotations to the output of my vision-based gyro program. Here's a diagram (because I love diagrams):

Here's some video of the thing. The program you see running on the screen is OpenCV's Lucas-Kanade tracker demo. The little green streamers are the feature tracks that the program is following :

Arms Too Short to Box with God*

Controller yaw authority still isn't as good as it could be, so in the course of my experimentation I decided to try out shorter arms (less rotational inertia). Here's a view of the whole contraption sitting on the table. I moved the landing gear inward and attached pool noodle for padding. Nice, but this arrangement was very tippy on landing if there was any lateral motion at all. I didn't want to take the time to add little legs to the ends of the arms, so I inserted some square carbon fiber tubes that I had laying around into the pool noodle. Worked like a charm. Adds weight, but I'll worry about that after I've truly solved the heading hold issue:

Here's a closeup of the little spirit levels I've been using to verify that the prop shafts are aligned with the IMU on top. They tend to get out of alignment whenever the craft takes a good thump during testing:

* http://en.wikipedia.org/wiki/Your_Arms_Too_Short_to_Box_with_God

Stable Hover!

Still having some minor twitchiness, but overall pretty stable after adding magnetometer-based heading hold:
Flying Contraption in Backyard

Surprise!!!!: Linux is not Real-time

Ok, it's not a surprise, but I really wanted to feel it for myself.

I wrote a small C program to decode the PPM signal from an RC receiver, fed in via GPIO pin on the Overo. I'm using Dave Hylands' gpio-event kernel module to get interrupts in user-space. The driver allows a user-space program to subscribe to GPIO events and read them in via /dev/gpio-event. When an interrupt is received, the driver spits out the timestamp of the event, using do_gettimeofday() under the hood. 

To get an idea about how well this thing would keep up, I  hooked up the 'Cal' output from my trusty Tek 454 o-scope (1 kHz square wave @ 1V) to GPIO 114 on the overo, logged the timestamps, and then differenced the samples to get a jitter plot:

Of note:
- The plot is mislabeled but I'm too lazy to make another: replace "timestamp jitter ms" with "pulse interval".

- The jitter occurs in ~32us increments. I learned from this discussion that this increment corresponds to the 32kHz timer clock used by the stock kernel on the OMAP3503.

- Standard deviation of the jitter is 25us, but we frequently miss our 1ms deadline by as much as 190us. That's a lot for a PPM signal that varies between 0.5-1.5ms.

So, what to do? I have a vague sense that using a kernel with the PREEMPT_RT patches might help the situation, but I don't really understand enough to know if this is true.

I'm inclined to think that it's time to move my control code onto a dedicated microprocessor and stop trying to shoehorn it into a Linux-based system. I'd planned to do this someday anyway, and maybe this means it's time.

Rev 0 of Stick-and-rudder via Dedicated RC Link Complete

Up until today, stick-and-rudder control has been a very complicated kludge:

RC transmitter -> USB buddy-box-to-joystick-converter cable -> PC -> windows joystick driver  -> pygame ->  joystick-reading code (Python) -> TCP socket client (Python) -> wired ethernet -> dedicated wifi router -> 'copter flight computer wifi link -> TCP socket server and control loop (Python) -> servo controller board -> motor speed controllers.

Sounds like absolute madness, but implementing this took very little time. It's always kinda sucked, though, and controlling the quadcopter felt really spongy and difficult. Lot's of crashing into the bushes and whatnot.

I've now got throttle control working via the RC radio link:

RC transmitter -> RC reciever (on 'copter) PPM out -> 'copter flight computer -> ppm_decoder and TCP socket client (in C) ->  TCP socket server and control loop (Python) -> servo controller board -> motor speed controllers.

Much simpler.

Observations:

- Throttle response is way faster. This makes me happy (like "I've got a boner" happy). 

- Output from ppm_server is very noisy. At half-throttle with no stick movement, the throttle value jumps around as much as +-20% of max-throttle. Watching the PPM signal with the o-scope, I don't see any such jumpiness. I suspect that we're up against interrupt latency. Time for a RT_PREEMPT kernel! (I've always wanted and excuse to try this).

- Whenever the radio is powered, the motors twitch, even though the throttle commands from hl_controller.py are zeroed. I suspect RF interference with the servo controller board/wiring. Sorting this one out with require more quality time with the o-scope.