OK, after a lot of time trying to teach myself to write device drivers in QNX, I'm jumping back into the Linux world.
I've stripped the bot down to the aluminium, and am building it back up one part at a time.

Hardware setup - EFIKA running openSUSE10.3 (thanks Matt!), with devantech usbi2c dongle. Connected to the i2c bus is a devantech md23 motor driver with two MEB30 drive motors. I've got eight srf02 sonars waiting in line, as well as a usb camera.

Software setup - one nice thing about this, from a practical point of view, is that it's all user-space. The FTDI FT232R USB chip in the USBI2C has a linux kernel driver, so it's just a serial port interface.

Linux has a pretty nice high-resolution timer interface, new since I've delved very deeply into system-level programming with it. So I've got three threads, with shared memory spaces for inter-thread coms. The executive thread is a command processor, and (of course) spends most of it's time blocked waiting for user i/o. I've currently got a 10Hz process and a 1Hz process. Each process runs a set of FSMs (Finite State Machines). Each FSM is responsible for handling one task or piece of hardware. The FSM-based approach to robotics software is a bit hard to get used to, but is very powerful and expandable - I learned about it while on sabattical at NASA's Jet Propulsion Laboratory (Hi, Hrand!)

The software is a classic three-layer (plus system support) architecture. A device-driver level implements low-level interface algorithms and being largely independent from other modules (e.g. a set of md23 read/write routines). A device-layer level abstracts and utilizes these low-level routines into a FSM architecture that is called repeatedly. For example, one FSM monitors each motor, and utilizes md23 routines to start/stop/change speed for the motors. Finally, an application layer will coordinate these independent FSMs to perform useful work.

Current status

• System support for 10Hz, 1Hz, shm, signal handling, timestruct, and command processing working. Monitoring and alarming of system overload on 1/10Hz command queues.
  
• DDs working for md23 and srf02
  
• DL FSM working for MotorControl, written for SonarCtrl
  
• No APL layer yet (unless you count command processing)
  

I've been walking through the QNX documentation, writing (ok, copying) resource managers. Here is where the excellent design of the QNX infrastucture is starting to make itself known. Within a couple of days, I've implemented

• The example single-threaded resource manager (implementing /dev/null)
  
• The exmaple multi-threaded resource manager (implementing /dev/null)
  
• A multi-threaded resource manager with custom io_read and io_write functions, that takes over multiple names in the /dev/ namespace.
  

The next step is, of course, to design and implement a resource manager for the Devantech USBI2C or the Diolan U2C-12. Probably the Diolan, since I've got two student groups using this unit this coming semester.

This actually happened on Oct 9, but the end of the semester has been typically brutal.

Turns out that the big problem with getting the Ethernet driver to work is that it was compiled into my QNX image (AURA.ELF) instead of on the HD. So to get it to work, I just deleted it from my QNX image in momentics and copied it to the EFIKA hard drive, then rebooted. The gory details are below.

Now, I can use momentics on my linux host to code programs for the efika, and have them run in a graphical debugger, with the execution happening on the efika! Yea!



The Gory Details
On advise from bplan QNX support, I tried the provided AURA.IFS image. As I've seen before, an EXT2FS on the HD is not recognized by my system - this image attempts to mount the second partition of hd0 (/dev/hd0t131) as / (ext2fs).

Then, I tried putting the ethernet driver on the hard drive instead of in the image. My hard drive is a QNX4 partition followed by a FAT32 partition, so I have to plug it into my linux box and mount up the FAT32, copy the files over, then put it back in the EFIKA to do this. Specifically, the "ethernet driver" consists of two parts, devn-mpc5200.so and libbestcomm.so. I first just moved devn-mpc5200.so to the HD, with no joy. Then I moved libbestcomm.so, and the ethernet started functioning perfectly. (Acually, I already had these on the HD, I just had to remove them from the image, remake the image, and copy it to the thumb drive from which I boot.)

So my startup file in QNX now has (in part):

display_msg Starting on-board ethernet
# This is the ethernet driver for Efika. Copy this file in /lib/dll on
# your QNX root file system. It is a normal ethernet driver for io-net.
# To start it up.
#io-net -dmpc5200
io-net -dmpc5200 mac=(my MAC address) -ptcpip # only needed for TCP/IPnetworking
waitfor /dev/io-net/en0 10
ifconfig en0 (my static IP) netmask 255.255.255.0
route add default (my static gateway)
display_msg done.

So now I can ping back and forth, and more importantly, I can compile programs in Momentics and have them run in the graphical debugger on my linux machine, executing on the efika!

We have motion!

Currently using a linux box with the Devantech USB-I2C (I think I may have exhausted the almost infinite patience of the bplan QNX support guy :) ) I've gotten communications working with the four SRF02 sonars and the MD23 motor controller.

The sonar comm was pretty straightforward, just reset all the I2C addresses to get multiple sonars on the bus.

The MD23 gave me some fits (if you're interested in the details, see
USB-I2C - what's special about register 10?), since I tried to do a little demo program to read the battery voltage and ended up learning the protocol, timing, and hardware for I2C! Anyway, I've now got temporary cabling between the MD23 and my motor/encoder (the real connectors are on order), but I can command velocity, read encoder counts, etc.

Well, QNX on the EFIKA is definitely a beta product. I finally got a firmware update to enable this, and unexpectedly Linux quit booting. Hmm, turns out that the firmware abstraction layers used by the two kernel are different. Oh, well, bye-bye linux.

Anyway once I got the bplan patches integrated into my boot file, I got the EFIKA booting from QNX just fine. Then I started to descend into driver hell [:)/2] Turns out that the firmware doesn't like my Toshiba HD (see old blog postings) and the QNX driver doesn't like my other HD!! So I can either boot OR run QNX off a HD. Whew.

So anyway, I format the Toshiba to be one partition DOS and one partition QNX4 (for some reason QNX always thinks my EXT2 FSs are corrupt...), plug it into my Linux host, tar up the PPC QNX binaries to the DOS FS, move the HD back to the EFIKA, boot into QNX, untar the binaries to the QNX4 partition, and have a reasonably functional QNX system, finally! Reminds me of the early (92 or so) days of Linux installs. Remember collecting packages from various ftp and gopher sites?

So I have the hard drive working ok, I have USB working well, next fight is with the ethernet driver. DHCP didn't "just work". I'll probably try to figure out a manual routing table to try, just to see if the driver is working, on Monday. Also might go get another video card so I can see Photon on this beast - my student took my other Radeon to play with Debian on the second EFIKA during summer break.

Once I have a network, I expect things will start rolling quicker.

Since the linux kernel supports the USB-I2C (the FDDI FT232 chip) in the kernel, having it show up as /dev/ttyUSB0 (usually), connecting to the SRF02 was easy. It seems that all the demo programs are for WINDOWS, so I've provided my port of them at http://www.cs.trinity.edu/~knickels/capek/usb_i2c.tgz

The timing is still very non-realtime, but this set just prints stuff to the terminal (using buffered IO at that!). I can see the comm errors when the disk swaps or something. I'll try some timing tests later, but this gets at why I'm not liking Linux for robotics... nonpredictable latency.

I got the Devantech USB-I2C and the MD23 Motor Controllers here. While I'm trying to get the software straightened out, I'm getting them mounted and cable assemblies made up.

The FT232R was recognized by linux right off, next is to figure out how to communicate with it.

So the sonars, motor/encoder/drivetrain, EFIKA are mounted and in-place. We almost have a functional robot!

On the QNX side, I got the licenses all worked out and the host software installed and compiling the 5200 BSP. The setup is kind of a host/target arrangement, where you develop on a (Win/Linux/QNX/Solaris) host, then just download the final executables to the QNX target. However, the EFIKA version of the Lite5200 requires some tweaks to the bplan firmware, which are classified as Beta and haven't come through yet.

In the meantime, I've ironed out a number of hardware bugs by installing Debian on the EFIKA. I've had a recalcitrant hard drive, four graphics cards that don't work as well on (my?) EFIKA as they ought to, and a minor power supply issue. BTW, the final video card is an ATI Radeon 9250 AGP, the CompUSA house brand. I'll likely remove it once I get the installs over with - it takes almost as much power as the EFIKA itself (9W vs 12W)!

I've chosen Devantech's MD23 Motor Controller (talking I2C) to power my motors/process the encoders. I'm getting both the Devantech USB-I2C dongle and the diolan U2C-12 unit. The Devantech is smaller and more compact, but the diolan can process GPIO as well, which may become useful later. Hopefully these will get ordered today.

I've got the EFIKA, now gathering the power supply, switches, video card, keyboard/mouse, etc.

I've got the QNX site setup, but still need to figure out which BSP goes with the EFIKA. Posted to powerdeveloper, and working on figuring out the proper place to request support from QNX directly...

Since I haven't hooked up with Bill yet to get the EFIKA, I started playing with the SRF02 Sonars, to figure out control over the i2c bus. This is what I'll be doing with the EFIKA, eventually. The interface is pretty clean - you can just request a ping, wait 70ms, then read the result, or you can poll on the result if you want, shudder. So there are just three data bytes across i2c for each ping - no self-timing or any of that.