Efika 5200B ProjectCapek Robotin category Robotics
proposed by knickels on 26th April 2007 (accepted on 27th April 2006)
Project SummaryExistant Hardware
Capek (formerly TCR, or the Trash Can Robot - named for its appearance) is designed for navigating in indoor office environments. It was concieved after two or three years of student groups spending the entire year creating a platform for robotics research, only to find that;
the time was all gone, with no real research accomplished, and
the platform didn't have enough payload to carry anything except its own infrastructure.
So this project was started by a couple of mechanical engineers. The original specifications included:
actuators selected for a minimum floor speed of 50cm/sec.
shaft encoders on the wheels
surplus payload of 10kg
power system designed for ship/shore power, with easy switchover and battery charging
a bumper system that would detect, to within +/- 30deg, the presence and location of a ``soft'' collision.
a hardware disable of the motor driver on bump (irrespective of computer commands)
Note that no computer control was included in the first pass.
In later semesters, different parts were added;
a low-level (PIC) microcontroller, with "manual" steering inputs, to implement PID control of the motors
a ring of eight Polaroid sonar sensors, with Timer/Counter interfacing
a PC-104-based linux computer, with Advanced Digital Logic's DIO-48S digital I/O card to interface to all of these.
The drive train (motors, H-bridges, shaft encoders) are working at 100%. They were designed with modular connectors (just 25-pin d-subs), so swapping out other controllers is no problem. The payload specs were proven out by lugging a 10kg stack of books across the floor (in addition to the 25kg robot!)
The Power system is pretty hacky - currently running on all 12VDC. The hot-swap circuitry was never designed well, nor the automatic connection of the battery charger to the battery when on short power.
The electronics (i.e. switches) for the bumper system are installed. The hardware bumpers were never designed. The interface to the H-bridges were not completed.
The Gentoo-based kernel drivers required to interface with the DIO-48S are working. We ended up interfacing through single-bit and whole-byte /devfs devices to do IPC between the user-mode and protected-mode program. This design has always felt like a hack to me.
The Polaroid sonar modules require that the controller do timing. This has been done with standalone 68HC11 and OOPIC boards at various times, but is not integrated with the main controller.
Replace the PC/104-based stack with an EFIKA.
Run QNX on the EFIKA to ensure real-time response, and avoid the user-mode/protected mode issues that linux has.
Replace the Polaroid sonar sensors with Devantech SRF02 modules. These do the timing themselves, and communicate via the I2C bus. Thus, I should be able to make a thread in QNX to handle this, separate from my main thread.
Use an OOPIC to do PID control for the H-bridge/Encoder circuits (i.e. wheels). This should accept commands from the EFIKA via the I2C bus.
Complete the bumper circuit, wire to the H-bridge brakes. Would like to get this status back up to the main computer. (May monitor with the OOPIC and send status back to the EFIKA via the I2C bus.)
Actually get some students doing robotics research with this thing :)
Project Blog Entries
posted by knickels on 8th July 2009
Capek resurrected - with SUSE/Efika plus usb/i2c
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.
- 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)
posted by knickels on 18th December 2007
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.
posted by knickels on 4th December 2007
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 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)
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!
posted by knickels on 17th July 2007
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.
posted by knickels on 13th July 2007
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.
posted by knickels on 10th July 2007
USB-I2C and SRF02 working
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.
posted by knickels on 9th July 2007
Motor Controllers Here, Starting to mount electronics.
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!
posted by knickels on 3rd July 2007
Software Kind of Moving, Hardware coming together
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.
posted by knickels on 6th June 2007
Getting hardware & software together
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...
posted by knickels on 16th May 2007
SRF02 Sonars Working (with OOPIC)
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.