| Porting a floor-mopping robot to Linux |
Jun. 23, 2006
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.
Related Stories:
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
news feed