DAS U-boot Sinks My Battleship

Today I set out to finish wiring up the IMU to the Overo serial port (/dev/ttyS2), but ran into a strange problem: with the IMU connected and talking, the Overo wouldn't boot. Connecting the IMU /after/ boot caused my ssh session started going molasses-like, and bizarre messages appeared in /var/log/messages:

Aug 28 07:53:25 quad SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W) 

Aug 28 07:53:25 quad SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount show-blocked-tasks(W)

Some Googling revealed that this sort of message appears when certain character sequences are input to a console. Aha! It dawned on me that the Overo starts up a TTY session on /dev/ttyS2 by default so that you can watch (and optionally interrupt) the boot loader, and watch the kernel boot. The IMU was spewing characters into a getty session, thus the weird messages.

This explained the boot failure, too: u-boot pauses at a five-second countdown waiting for you to hit a key if you want to break into the boot loader prompt, aborting the kernel load. So, it looks like the boot loader was pausing for human input, and hearing all sorts of strangeness at the console, and freaking out (and not booting the kernel).

The fix was twofold:

- Broke into u-boot and set the 'console' environment to 'null' (from 'ttyS2,115200n8').

- In /etc/inittab, commented out the lines that set up getty for serial console sessions.

With that solved, I now need to solve my ongoing electrical interface issue with the 3DM-GX1 (nothing's ever easy, is it?) :)

Integrating the 3DM-GX1

First time around, I hooked it all up and assumed it would work. Oh, the arrogance. The outgoing signals to the servo controller worked fine, but I couldn't seem to 'hear' the IMU from the Overo. I eventually bricked the IMU thanks to the unreliability of a $1 wall wart. I finally got the IMU back from the shop, and now I'm verifying the whole signal chain, front-to-back. For this purpose, there's nothing like an old-fashioned analog oscilloscope, and it so happens that I have a 60s-vintage Tek 454:

The first thing you'll note, aside from my ghostly, distorted face hovering over the trace, is that we can see that the IMU is indeed, transmitting. The 'scope is set for 2ms / sweep. Vertical scale: 5V/division. Therefore: period = 13 ms =~76 Hz @ +- 7.5V. 

Left to figure out: will our Sparkfun RS-232/TTL converter work?

Horizontal: 2ms/div, Vertical: 5V/div.

So, we have a TTL Serial signal that looks to be about 8V idle, swinging to zero at the 'mark' bit (supply is 10V, btw). Scale it down to about 1.8V and we should be golden.

The Cord is Cut

First run in the tilt jig with...no tether!

Free at last!!!

RC Joystick Control Works

Last night's pygame spew problem was solved by simply not using pygame.joystick.get_axis(). Instead, we just parse the values of joystick events as they come in, rather than attempting to poll the joystick.

After figuring that out, I had moving servos, but they were really twitchy and moving in mysterious ways. Riding home from work on my bike this evening, I realized what was going on: QuacClient.send_control_msg() wants angles, not throttle values. Got that straightened out and things are moving as I'd expect, but I can see that I'll need to add some filtering since noise from the analog sticks is large enough to make the servos twitch a bit.

Also, I figured out how to get pygame to trap ctrl-c so I the client can cleanly disconnect from the quad. We can now quit the client without having to kill the console window, and without having to restart hl_controller.py on the quad.

Yak Shaving: Building SDL

So instead of apologizing for not having posted to this blog for a very long time*, I'll just cut to the matter at hand. From my Evernote build log:

20110808 Yak Shaving: Building SDL
Ok, so I'm trying to hook up my rc controller to my Python Quad Client using pygame (via Simple Direct Media Layer) and my little test program that reads the (joystick) rc controller keeps spitting out extraneous stuff at the console, completely screwing up my little test program. Unfortunately it appears that the version of sdl.dll that ships with pygame is compiled with DEBUG=1 and so many functions spew out a bunch of debugging fluff on the console. I "must" now build SDL myself, and indeed there's a VS build configuration named something like "ReleaseNoStdIO". Of course, to build SDL, I need the DirectX SDK. I can only imagine what will happen after I download the DX SDK and hit F7. Meh.





* Apparently there's a blog devoted to apologizing for having not posted to your blog for a long time: http://www.coryarcangel.com/2010/08/sorry-i-havnt-posted/