Dr. Dobbs Journal has published a detailed, technical paper chronicling a successful 22-month development effort by two Intellibot Robotics software engineers to port a $33,000, autonomous floor-scrubbing robot from an OS-less 68K-based design to embedded Linux running on an off-the-shelf x86-board.

The paper was originally presented at the Embedded Systems Conference (ESC) in April by David Knuth and Daniel Daly, of Intellibot Robotics. Formerly known as Kent Company, Intellibot Robotics is a 15-year-old company that had previously marketed six generations of autonomous floor-scrubbing robots. It was acquired in 2003 by Henry Hillman, an entrepreneur based in Portland, Ore.

Linux selection

According to the Knuth/Daly paper, new Intellibot management in 2003 was confident that embedded Linux could meet the company's needs, in part because of Linux's prominent role in academic robotics research. No technical or license feasibility work was undertaken by Intellibot before deciding to migrate its robot to Linux, according to the authors.

Board selection

The existing robot design incorporated a number of peripherals attached via an SPI bus (serial peripheral interface), so the team sought and eventually found an x86-based board with SPI. The board came with Linux pre-installed on a 32MB CompactFlash card, and the vendor touted the board's Linux support, a factor that proved invaluable when a BIOS bug was found, because the vendor quickly fixed the bug.

Early development triumphs

In moving from an OS-less design to Linux, the development team was delighted to find that they could mount the robot's root filesystem via NFS. This enabled files to be tranferred “effortlessly” between development host and target. And, since NFS worked over WiFi, the team was able for the first time to do untethered development of its mobile robot. “This was much more convenient than programming ROMs, as was done in the past,” the authors note.

The team decided to build its applications using dynamic linking, to save filesystem space and RAM usage. Libraries pre-installed on the board were out-of-date and did not support POSIX threads, but were easily replaced by copying select libraries from the develoment host, after running ldd against the applications to see which libraries were needed.

Driver challenges

The team had to develop several device drivers. They were initially built as modules, to facilitate changes, but were later built into the kernel to minimize file count.

The team wished to re-use existing SPI peripherals, and wrote drivers and applications to interface with them. Initially, drivers were kept very basic, with most peripheral control handled in the application. However, the threaded nature of the system, in which several threads share the SPI bus, made it more efficient to move to an interrupt-driven driver, because the kernel's efficient resource allocation algorithms were easier than writing a lot of thread-safe control functions into the application. The new drivers were also able to exploit rich SPI hardware built into the robot's x86-compatible processor.

Another change in moving to an OS-based design was the need to handle power-off gracefully. The team wrote a 41-line C module, in one day, that triggers the robot's main power relay after the kernel has executed a shutdown.

Linux's real-time (dis)abilities

Another challenge involved Linux's level of real-time support. Attaching a logic analyzer to the SPI bus revealed that several usleep 200 commands aimed at giving microcontroller-based SPI peripherals time to execute operations were actually producing delays of 10 milliseconds, rather than 200 microseconds. Luckily, a console error message made it easy to trace the problem to the 100Hz default resolution of the kernel's main timer, which is defined in include/asm-i386/param.h.

The team initially tried increasing timer resolution 10-fold. This helped, but such fundamental changes can have unintended consequences, and in this case led to a WiFi driver breaking due to its routines timing out much too quickly. And, the timer resolution still was not adequate to provide the soft real-time results needed.

The problem was eventually solved by using a gettimeofday() loop, after the team verified that this function offers microsecond granularity, and does not lock up the CPU completely while counting.

Knuth and Daily note that in solving problems related to timing, being able to search the kernel source code for specific console error messages proved invaluable. They encourage driver authors to create unique, informative run-time error messages.

Impressions of Linux

Overall, Knuth and Daily are clearly pleased with Linux as an RTOS (real-time operating system). Linux is familiar, for one thing. And, while large compared to typical RTOSes, Linux is “organized so that understanding it does not require swallowing it whole,” they write. “The important thing is that you understand just enough to get your job done, and this is possible with Linux.”

However, the authors cite Jamie Zawinsky's famous critique of Linux in noting that “what you gain by not paying money for Linux is lost in the time you spend bending it to your will.”

Support is not optional, the authors suggest, but can be free. The info is out there, they suggest — “the variable is your ability and willingness to reach the information.” Additionally, the cost in time of using free support pays back a greater dividend of knowledge than traditional technical support models, they note.

The authors praise Rubini and Corbet's Linux Device Drivers.

In total, the project was completed by two software engineers in 22 months, two of which were spent on device drivers, and 13 of which were spent fine-tuning applications and adding support for new SPI peripherals.

The complete (lengthy) paper can be found here.

---

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.