Taming bruce

Take your positions!

2008-03-09T10:46:00.000-07:00

Working on positioning the turrets started today - and I'm pretty satisfied. I get a positional precision within +/- 10 steps, which isn't even visible.

And I found out something really great: the turrets have the index-hall-sensors aligned such that positioning the turret in the middle of the index gap means that they are aligned properly for driving straight. In other words: no calibration needs! Great!

Bad news is though that turret number 4 fails to work with positioning and index-bits. Currently I have no idea why that is the case, hopefully nothing serious.

And I found that the mechanical parameters of the different turrets differ greatly - what makes good values for the PID-controller for my primary turret 0 makes not necessarily sense for the others. But that's a question of configuration, I hopefully can overcome that.

All in all, nice progress today!

speed bumps

2008-02-24T10:27:00.000-08:00

After a couple of days work, I reached much better speed control. The control_loop now seems to work pretty much, in both directions, ramping up/down the speed as desired.

Unfortunately, I'm getting pretty bad results still - but to be honest, I don't think this is due to errors on my part, but mainly because of mechanical properties of the robot.

The turrets don't turn lightly and with the same resistance over the full 360 degrees. Instead, the force to be applied varies greatly, and even a sometimes pretty nasty screeching sound can bea heard.

Yet I'm pretty satisfied - I ironed out quite a few wrinkles and am prepared now to tackle positional control as well. After that is reached, I hope I can measure the calibration values for the various turrets to make the robot controllable.

And I also hope that the mechanical problems/properties change a bit if the robot is placed on the ground. That will make the intrinsic forces only be a fraction of the combined ones from friction and inertia - which will hopefully smoothen the ride considerably.

So - as usual, small steps, but significant.

the joys of multi-threading

2008-02-16T12:18:00.000-08:00

Finally found the error that caused the random segmentation fault in my control-server - lesson learned: be careful what you pass to a thread as argument, if it might be freed prematurely.

Nothing I didn't know before, but because I removde the semaphore-based inter-locking of my main-thread with the control-loop - because semaphores require RTAI to be active, which caused the preemption-troubles of the past - perfectly working code became a subject of a race-condition: how's faster - the control-thread in fetching the data out of the passed argument, or the main-thread in releasing the argument because it's stackframe gets removed... depending on the winner, things work smoothly or segfault.

Beside that I made the index-bit-stuff work, which suxors, btw - I don't get the current index-bit-state, but instead the bit is latched once and must be reset. Thus I can only gather the index-position on a rising edge, which makes measuring the index-gap only possible with reverting the direction. Something that will cause imprecisions in the gears to become part of the picture... sigh

2008-02-03T09:21:00.000-08:00

A few lessons learned in the past couple of days. Most of them are good, but it's still all laying tedious groundwork - I'm really skeptic regarding the desired may-release-date of the robot. But still, it's good to see at least some pieces falling together

What did I learn?

How to create multiple instances of COCOA-InterfaceBuilder-created interfaces! That was a long-needed thing. What you essentially do is to create a NIB-file for your visual component. Then you can load that component using NSBundle.loadNibNamed:owner:. Whatever you attach to outlets of the owner will become available to you. Thanks to Kyle from cocoa-dev ML who teached me that.
There is no need to make the main-thread of my robot-controlling application a real-time-scheduled thread. Paolo suggested that only my control-loop needs to be real-time. I followed his suggestions - and voila, my previous problems with my main-thread eating up more or less every CPU-cycle has gone away. However, this somehow introduced a spurious segmentation-fault it appears, that makes my app die sometimes and even seems to have the potential to crash the whole system - it rebooted a few times today, without me doing anything else. I already began working on a solution, but so far to no avail - needs more attention it seems.
Bonjour/ZeroConf is out of the game for now. The reason is that I wasn't able to decouple it from the gobject-mainloop. And for some reason I don't get my Pyro-Nameserver reacting to broadcasts (or they aren't communicated properly). So currently I'm running on a fixed IP with my robot's WIFI-card. The bonjour-thing will resurface at some point, but right now there is more urgend stuff to do.
It seems that ctypes-Structure-objects aren't pickable. At least I can't send them over the wire using Pyro without them being null'ed - so not much sense in that.
And I found out that my all-knowing-physics-genius David can produce complex differential equations I'm going to need for the later path-controlling straight out of his head, even when he has the flu. Impressive, and a bit intimidating.

So what's working? I got my OS X-based monitoring app connecting to the state-server so that motor-information is displayed. I did have the robot-control-program spawn a pyro-server that reacted to commands locally, but for some reason I can't fathom it won't work when invoked from the monitoring-app on the notebook. That will be the next thing to attend to.

bonjour bruce

2008-01-31T08:58:00.000-08:00

After a longer hiatus due to our giant keyboard project, I'm back fiddling with bruce.

Today, I learned an important lesson about RTAI, which the wiki as well as Paolo Mantegazza from RTAI helped to solve: Once a thread becomes real-time-scheduled, you need to explicitly pass control to the scheduler. Otherwise it will preempt any lower-priorised task (which, in my case, meant more or less everything including network traffic...)

Paolo showed me a way to overcome this in my current API/Application design. I hopefully can try that out tomorrow.

Additionally, I began thinking about and exploring bonjour, and it's linux incarnation - avahi. I will use the excellent Pyro to communicate with the robot itself, controlling it and publishing position feedback. But to discover it, the pyro-nsd seems to be a bit more limited or unconvenient than I want it.

So far, it seems to work rather nice, I can advertise a new service under linux. Now I need to figure out how to

get rid of the glib-mainloop in the avahi demo-code
find the service from OSX
communicate the pyro URI over bonjour

But I'm pretty positive none of the above will impose any greater hardship.

Stay tuned...

RTAI scheduling works

2007-12-06T09:59:00.000-08:00

Today I made it happen - the tight 1ms control loop is working. I have actually not the slightest idea why RTAI kept bugging me for so long. The testsuite worked flawlessly, and so I expected no troubles. Yet it crashed and kernel-dumped and generally bitched around. No offense to the really great folks that make RTAI! Paolo Mantegazza was helpful, and I bet it's been me all the time.

Once I started creating a test-application step-by-step, I finally made it to the point where I had my control loop established.

Now the work on the PID-controlling of the motors begins. I decided to go with a python-prototype first, as I don't see through my old code anymore. Nothing unheard of in the wonderful land of C.

But always marvelling is the ctypes-python-to-C-bridge. Together with GCCXML, it's easy as cake to glue together the various bits & pieces of my controlling functions to yield a really powerful control application. Or just some unit-tests.

Working WIFI

2007-11-29T13:45:00.000-08:00

What can I say? One of my bigger fears - not getting the WIFI connection to work - turned out to be completely baseless.

Once I found a decent hardware distributor who actually sold me a NIC with atheros-chipset, I just followed the instructions at madwifi and got connected without a hitch to our office-network.

Gosh, if had known it would be so easy, I might even have bought a Linux-notebook instead of a Mac Book Pro. Just kidding....

Tomorrow, the fight against RTAI will continue!

basment under current

2007-11-29T03:54:00.000-08:00

Ah, what a relief! Today I finally managed to get the motors and sensors located in the basement section of bruce running.

This has given me troubles mainly because I don't own a wiring diagram of the robot. So I didn't have any detail knowledge about the emergency shutoff circuiting anymore.

But now that I found the secret (again, all this I knew 2 1/2 years ago - but the GC obviously did a good job) of attaching the emergency switch connector to a stub on the robot that precisely is there for making it work without it's outer hull - the place where the actual switch is located - things got brighter within a second.

up and running

2007-11-23T06:15:00.001-08:00

Yesterday I finally managed to get the NIC running. After the umpteenth building of the kernel, rebooting with the robot - and failing miserably.

One of the main problems was the lack of a working keyboard on the robot itself. Thus I had to resort to the following procedure for creating new kernels & configs:

plug the HD into my office PC
do whatever I intended to do
halt the machine
remove the HD, plugging it into the robot
reboot
fail miserably
goto 1.

At some point I became desperate and decided to attach a USB-controller to the robot. It even has ports on-board, but not as common USB ports - they need an extra cable.

When booting a standard distro kernel (added complexity: not having a working keyboard means there is only one kernel to boot - the default one....), I got USB-support, and thus finally access to the machine.

After reading some logfiles, I finally stumbled over this. I didn't realize that there is a

/etc/udev/rules.d/z25_persistent-net.rules

that pins the NIC to a certain MAC-address. And because of the exchange of the HD, of course my PC's NIC has a different one, resulting in the Robot's NIC being assigned (and of course not configured) to eth1 instead of eth0.

Ok. Finally sorted that one out...

Kernel panics

2007-11-18T05:20:00.000-08:00

Today, I tried and finished the RTAI kernel. First, I got hold of a vanilla 2.6.23 kernel. It took quite a while to create a minimal, working configuration. Part of that was because of me not realizing the sheer amount of new options which nest deeply in the configurations.

When it finally ran, I got the latest RTAI-distribution, and tried to start. The RTAI-Wiki suggested some ADEOS-patch to apply, so I investigated that. But it turns out that RTAI is based on it's own fork of ADEOS, which I grasped after finding this fine RTAI-tutorial.

So I patched the kernel. Or tried to.For some reason some things called "ipipe" weren't working in the patch. Finally, I found that because of the misapplied original ADEOS-patch
my vanilla kernel sources first had to make a run for themselves, with the effect of creating the files necessary for the "ipipe"-stuff. After that, the patching went flawlessly, and I was able to build a kernel.

Rebooting into it, I started building RTAI itself. At this point, it puked on me for not having CONFIG_MODVERSIONS disabled. I'm sure that is told you somewhere, but I missed it. So it was recompiling the kernel again.

After than, the next hurdle was that I used GCC 4.1, but the RTAI-Lab didn't work with that. I removed it from the configuration, as for now I'm not really interested in it. A view I got to question sometime in the future.

Building went smooth afterwards. Naturally, that wasn't all there was to it. When trying to run the latency-tests, the loading of the kernel modules failed muttering about APIC being enabled but not available. I found this discussion about it, but didn't get the enlightenment I hoped for.

So I disabled the APIC in the kernel, and recompiled. I wish I had a Euro for each time I recompiled the kernel in the last few days...

In the end, it didn't help - but after reading this, adding lapic to my kernel boot parameters did the trick.

I finally have a working testsuite of RTAI. Whopee!

Now all I need to do is to make that kernel run on the Robots own board. And then add WIFI support for it.

return to the future - installing debian

2007-11-16T07:29:00.000-08:00

I'm currently having troubles setting up the linux to become the real-time-OS for bruce. First, burning the installer CD failed. Then the installer crashed, until I found out that I had used some unstable one. Then the selected mirror (which was charite, the famous Berlin hospital I can actually see from my window) wasn't reachable. Doh. I presume real-life proximity doesn't correlate to much with network connectivity...

So overall this feels a bit like the first linux installation troubles back in the mid 90ties, when I started using it. Oh well.

Hopfully installing the RTAI-kernel will go somewhat smoother. I need a new 2.6-one, because I want WIFI on the robot - and from my sparse, but really annoying paste experiences with that under linux, I doubt I should try anything but the latest and greatest.

If anybody has a tip on what networking card to use - I'd be all ears.

2007-11-16T07:13:00.000-08:00

This is bruce. Stripped and naked. I will be posting in-detail-photos once I got hold of decent camera, and not that piece of c...amera built into my equally great phone. On top you can see the beamer, and the power cords. Left of them is the dreaded emergency controller thingy. Turning on the robot will make it emit a nerve-straining clicking. And unfortunately no power is available.

Below is the section with the two PCs - you can dimly see a blue triangle, that's a control cable reaching down into the "basement" from the servo to go card. On the right is the MultiMediaPC.

This is the beast. You can turn it off, with just a few clicks - but that's needed every time the robot is boted. Sigh.

Genesis

2007-11-16T06:59:00.000-08:00

Today, I started the actual work on bruce - afte I got the harddisk from the van Abbe museum. Initial findings: apart from the wicked emergency switch stuff, everything seems to be in order. But my C-code from 2 1/2 years back sucks....

Let the taming begin!