Take your positions!

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

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

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

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

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

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

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!