Linux Controlled Autonomous Vehicle ("Grumpy Snail")

They said it couldn't be done!

2008-07-15T11:41:00.000-07:00

- ...but I'll show them. I'll show them all. Muahahahaaa. Igor, you can put the lightning conductor away now.
- Yeth marthter.

Ok so I finally managed to wade through the Internet's mire of awful Googled code to my goal of actually writing a message on an LCD panel. Who said the internet was the greatest research tool ever devised? Not me that's who.

Anyway, I still have a few bugs to iron out of this LCD panel interface code (it could be faster, the sleep() calls are excessively long at the moment) but at least my wiring is vaguely sane.

Soldering on in the face of adversity.

2008-07-12T09:33:00.000-07:00

I thought I'd treat myself to a bit of raw electronics this week. Nothing too complicated though, my electronics knowledge is something I really need to work on one day.

So, anyway I bought a couple of LCD panels ("DEM 16217 SYH-LY" see here) so that I can have some means to display status information while the robot is disconnected. By "status information" I really mean a way of monitoring when all daemons have started, if and when any daemons die for some reason and also things like RAM usage, CPU load and uptime.

Currently I'm half way through setting up a prototype circuit on a breadboard so that I have something to send instructions to, from the C code that I'm throwing together to make sure everything is going to work nicely.

As soon as I have written a message on the LCD panel with my software I can tear the prototype to bits and solder the chopped cable to the LCD panel permanently. I'll need to get an enclosure box for the panel too to prevent any damage that it would otherwise sustain as a result of GS's murderous, bloodthirsty rampages.

When this is done the LCD driver daemon will be similar to the logfile daemon in that any other daemon can send messages to it and have them displayed on the LCD panel any time. I think I may finally be getting somewhere with LCAV.

Smokin' Pipes

2008-07-03T10:32:00.000-07:00

I have designed a simple but hopefully effective means for the various daemon processes to communicate with eachother. Before any daemons are started, the parent process populates an array, each element contains a pipe (pair of integers), a function pointer (for the daemon to execute when it starts) and an integer in which to store the PID of the daemon after it has started.

These pipes are all initialised in the parent process and all the function pointers are filled in. Then a macro causes the set of daemons to fork() and store their PIDs in the array.

This means that every single daemon has access to all of the other daemons' pipe handles. So at run time each daemon can talk to any of the others simply by open()ing whatever pipe handle it wants to talk to and writing messages to it. Info about the parent process is also stored in the array so it can talk to its daemons if needed.

This is all very neat and tidy and simple to code but it's probably not very robust as far as detecting when any of the daemons have died for some reason. I still need to do some investigations into it but I suspect that I could either test the pipes in some way to check the remote end is still open using standard system calls) or possibly by periodically polling each pipe to prompt a timely response from the remote end.

I chose this method over TCP sockets for two reasons: 1) its faster and 2) I don't plan to move any daemons onto different computers, this will not be a distributed computing platform (at least not to start with).

Enlightenment

2008-06-21T07:52:00.000-07:00

I spent the last year in Tibet learning about nirvana and being at one with whatever, got bored with yak milk, came home. That neatly explains my lack of blog activity lately.

I'm tearing up my original designs for Grumpy Snail and I'm redesigning the LCAV software from scratch more or less. This is because I've learned a heap about linux server/daemon programming since 12 months ago.

My new design is going to be more stable and fault tolerant and basically simpler than the previous ideas.

I've had a few sparks of interest from my chums at VBForums.com and so I'm kind of resurrecting this project from the limbo state it has been languishing in since last summer, plus it's a good a project as any for practicing my linux programming away from work.

Make like a tree

2007-06-06T13:22:00.000-07:00

The last few days have been too hot / busy / drunken to get any useful coding done on this project.

However, tomorrow I'm going to start designing the makefile(s) for the compilation / linking of the various modules together.

As I've said previously, I'm going to have the default make target (of each individual module) perform the compilation (-c) of the object files. A secondary (recessive) target will be called "standalone" and will perform a full compilation to an executable for that particular module.

This means I can easily unit-test each module separately from the main application. This will be most useful for valgrind and gdb debugging. To handle special cases where the actual code needs to be different (for instance, providing a main() function) the standalone targets will all provide #define STANDALONE, which will let the compiler make sense of the code for its module. The master makefile may also have a standalone target that makes all of the standalone binaries all at once, although this will be of limited usefulness apart from code-sanity testing.

This will undoubtedly get a bit complex later on in the development. I'm not sure how I'll get around the pipe comms issues in the standalone versions but I'll burn that bridge when I come to it.

the makefiles will be arranged in a tree, one master makefile in the top-level directory and then another makefile for each module inside that module's code folder. This will allow all the standalones to be segregated away from each other and should minimize makefile rot, as most of the sub-makefiles will be almost identical to each other and therefore can easily be repaired / recovered. This will be a bit more work but in the long run should save some dependency hassles.

DB test successful

2007-05-27T09:43:00.000-07:00

Just finished hooking up the toolchain test for MySQL and GCC. Everything compiled and ran successfully apart from an alarming number of memory issues in MySQL and the Velleman K8055 libraries, as reported by valgrind.

As a simple test I have setup the k8055 board and I'm reading its input channels every second and inserting the values into a table in the database. This is actually pretty close to the main functionality of the gsk8055d daemon as I had originally designed it. There will be extra functionality in the final version that allows ad hoc channel reads / writes. These extras will need to go into a separate table because of efficiency optimisation.

As it stands, I have just compiled this as a standalone program for now. The main daemon tree will need much further planning before any real functionality is inserted. I feel it more important to have the skeleton working robustly (kernel signals, logging etc) before everything else.

I'm designing the daemon modules to be compilable as standalone / embedded anyway so they can hopefully be debugged as standalones before being united into one big app much later on in the project.

Handover.

2007-05-26T12:10:00.000-07:00

Moved all the live source to grumpy. Also made a start on the mysql tables. I'll be backing up source and DB to external HDD every few days or after every major bug fix.

Wifi

2007-05-24T10:58:00.000-07:00

I've spent the last day or two fiddling around with my shiny new PCI WiFi card (sitecom WL-171).

I'm actually very impressed with it so far. But even more impressed with NDISWrapper, which against all my jaundiced, cynical expectations worked perfectly first time. Put simply, ndiswrapper lets you use the readily-available w!ndows drivers under Linux. So basically if you go buy a wifi card randomly off the shelf (I went for the cheapest one I could find @ £25 :D) you get the stupid w!ndows / mac driver CD and never anything for Linux. NDISWrapper just takes what it needs from the w!ndows disk and configures your linux box as required. Very, very cool indeed.

And what's more I even installed it from source tarball (which is sometimes fraught with dependency problems but that went smoothly too).

Setup as it currently stands:
- Fedora Core 6
- 802.11g ("turbo" mode) networking
- P3@1GHz, 20gb HDD, 396MB Ram
- gcc/g++ version 4.1.1 (for compiling the main systems)
- mysql-5.0.27-1.fc6 (for storing a ridiculous amount of telemetry and configuration)
- httpd-2.2.3-5 (for serving up status pages to remote machines)
- php 5.1.6 (mainly for things like low-workload operations or for bootup scripts and mysql stuff)
- SDL-1.2.10-6.2 (for reading gamepad data and also for webcam data visualisation :D)

There is only 1 major obstacle left to overcome now, that of battery power!
I'll need a SLAB (sealed lead acid battery) rated for at least 12AH at 12 volts. When idling, this box draws 37 watts of juice from the mains supply its currently running on. When loaded its closer to 65watts.

Hopefully I can get at least 3.5 hours of runtime (without anything like stepper motors running).

I'm going to have a look at reading a webcam's raw data over the next few days though. Decoding such a data stream will be a major asset for LCAV. It will enable computer vision algorithms to influence the decisions grumpy can make.

Also I am going to have the gskilld daemon have multiple triggers. If it detects that any of the 'essential' systems have gone offline for whatever reason it will initiate the failsafe sequence and bring the wifi connection UP to make sure that an SSH login can be established.

Triggers for gskilld will be things like:
- the BRB (big red button)
- the demise of the (wishlist) webcam decoder process (can't have it running around blind, relentlessly slaying people)
- main battery low (not sure how to detect this from a SLAB, maybe a custom circuit?). This will probably also initiate a complete poweroff (with a hold-off override).
- wifi going offline (see "Runaway", 1984 Tom Selleck)
- Loss of mysql/httpd daemons (unlikely)
- One of the gamepad buttons (or a combination / sequence)

No doubt these runtime checks will probably be quite computationally expensive, but who cares? Not me that's who.

The project begins.

2007-05-19T03:38:00.000-07:00

After much hunting around for a cheap and small PC to use as the base of this project I saw this in a shop window...
Its a Fujitsu-Siemens Scovery. Basically it is a Point Of Sale PC, Pentium 3, 1ghz. So brute force isn't is main priority, but it does have lots of expandability options, including 2 PCI slots, USB and its even got an AGP4 slot! Legacy ports like 2 serial and 1 LPT port mean that low-level diagnostics and troubleshooting will be easy.

I did upgrade the RAM to 396MB though as FC6 (which I installed yesterday) isn't the smallest distro available.

I chose FC6 because of its good hardware support and its numerous system tools. I installed virtually every software dev tool I could find in the setup menus, including things like electric fence and valgrind.

For the time being I will still be developing the core of the project software on my laptop (FC4) because its easier for now just to use a known-good dev setup and scp all the binaries over to the
new box as and when required.

I've named the new box "grumpy".

Over the last day or two I've been designing the daemoning system for the core program gsroot. This is a good and concise article about how to daemonize a single process program: http://www-theorie.physik.unizh.ch/~dpotter/howto/daemonize

For the purposes of LCAV I've modified the techniques detailed in the article in order for the main process to stay alive and spawn several separate daemon processes as detailed in previous blog entries.

The system logging is a very handy feature for both debugging and auditing. Daemonizing in this way has many benefits, such as asynchronous processing, fault-tolerance, built-in redundancy and the ability to selectively activate / deactivate specific modules as needed.

I'll be using pipes to enable communications between the different modules, as this is simple and fast.

Each of the modules will be compiled separately into object files and linked into gsroot using probably only 1 or 2 function calls. This makes the task of selectively compiling gsroot very simple. In the makefiles I plan to use precompiler macros to specify what functionality will be built into the application.

The next few things on the agenda:
- Try out the test code I wrote for the Velleman experiment board. If that all works ok then I can begin work on the digital/analog IO module (DAIO).
- Write the code for general comms between modules. This will probably be in the shape of a separate set of object files that can be shared by all the modules.
- Setting up a MySQL database (maybe on a different machine to ease CPU usage) to shove various data into (probably stuff like DAIO logging and general status info. Definitely things like startup/shutdown times and parameters).
- I think it would be cool to have Boa (or Apache if Boa's not man enough) running so I can generate a pretty status page that shows high-level details in a remote web browser (means LCAV can be monitored by any nearby machine with WIFI.

- ...More ideas as they occur :D.

Distro Selection

2007-05-04T11:33:00.000-07:00

From the very start I have seen the selection of a suitable Linux distro as a potential stumbling block for LCAV.

I'm a long-time Fedora Core 4 user and I love its diverse range of standard tools and packages. GCC G++ valgrind, GDB and so on. These are the sure sign of a truly great distro - letting average users have access to professional level dev tools. I have to salute the Hedhat and Fedora teams for this attitude.

However this does come at a price. Storage and cpu power is something I'll be running low on once I have selected my motherboard. Remember the aim is to create a small autonomous self-propelled computer. So I have to select a distro that can step up and honestly say that it doesn't give a shit about user-friendliness. I will happily forgo a desktop environment because I know just how many resources they soak up, resources I cannot afford to waste.

I therefore need something fast, stable and text-only.

I did try Damn Small Linux (DSL), as it is purported to be a good distro for linux-curious folks with low-spec hardware. And as such it does a good job. However it seems to be rather inflexible with regard to installing permanent modifications. It does live up to its name though, taking up about 3% of a 4GB hard disk. That is quite impressive.

But no, DSL is not suitable for LCAV.

I also tried (purely as an experiment) stripping down a base install of Fedora Core 4 until there was little left...this proved difficult as the dependency tree is thick and tangled (but thats not to say disorganised, I'm a huge FC4 fan).

Experimentation over. The first distro that I am really going to put any effort into (with regards to LCAV) is caos.

One thing that really caught my eye was the compiler support. Other things like Apache, MySQL and the small ISO make this a very promising setup to get this project up and running.

Watch this space.

Daemonic Possession!

2007-04-22T01:17:00.000-07:00

LCAV will require multiple systems to be monitored simultaneously. I think the most sensible way to do this is with a series of daemon processes that all spawn from a single master process.

(The naming convention: "gs.....d" denotes "grumpy snail daemon".)

Master Process: gsroot
- gspowerd: Power monitoring. ACPI?
- gslogd: General purpose logging
- gskilld: Monitors the kill switch. I think this is worthy of its own daemon, since it cannot be allowed to go unnoticed.
- gsk8055d: Communications with the Velleman K8055.
- gscommandd: Will allow a supervisor to give explicit controls to GS, for debugging purposes or in order to have a good laugh driving GS around with a wireless gamepad. That's going to be awesome :D

I've just modified my old wireless XBox controller receiver to remove the 5pin proprietary microsoft USB connector and replace it with a sensible one (see here: http://www.dangray.org/xbox). I also removed the two enormous memory card sockets, they are completely unnecessary. Now Linux can see it on the USB bus as a hub device. Switching on the gamepad itself and running dmesg again yields the following results (under Fedora Core 4)...

usb 1-1.4: new full speed USB device using ohci_hcd and address 4
usb 1-1.4: configuration #1 chosen from 1 choice
hub 1-1.4:1.0: USB hub found
hub 1-1.4:1.0: 3 ports detected
usb 1-1.4.1: new full speed USB device using ohci_hcd and address 5
usb 1-1.4.1: configuration #1 chosen from 1 choice
(((gamepad switched on here)))
input: X-Box pad as /class/input/input5
usbcore: registered new driver xpad
drivers/usb/input/xpad.c: X-Box pad driver:v0.0.5

Might even have a daemon especially for watching the gamepad device.

When booting the master process I will probably supply commandline args (or use a config file) to select which daemons will be spawned. This lets us selectively add or remove modules as and when necessary, effectively making it a general-purpose robot, which is nice.

To this end I'll need a central library of standard commands that can be used by any daemons that need to be able to control the robot directly. This project is starting to get complex.

It's about time...

2007-04-21T13:07:00.000-07:00

...that I explained the point of this project.

I've been interested in Robotics for a very long time now, but only as a casual observer. I've dabbled in electronics now and then over the years but without a good project to put any effort into, my interest has waned from time to time.

I've spent the last 18 months or so using Linux almost exclusively, and I've grown to love its elegance and simplicity. No other operating system I've used so far has shown the same qualities. Linux was born for multitasking and system-critical jobs. If you've got a task that ABSOLUTELY MUST NOT go wrong, then you use Linux or Unix.

Those who know me, know my disdain for Windows. I've used Windows for well over a decade now and I've developed applications for it for more years than is healthy. As soon as I switched to Linux I felt like I had been given a shot of adrenaline. Linux is what computers grow up wanting to do. My enthusiasm for software development is replenished daily now, and not sucked dry by Microsoft any longer.

Linux made this project a possibility. It certainly made it worthwhile...

I've used the word "robot" rather liberally so far but this project isn't really about robotics. I won't be designing any multi-joint dynamic-geometry manipulators, or designing any 3D computer vision algorithms (at least for the time being).

I just want a machine that can intelligently make decisions about what it should be doing at any given time. Be it movement, analysing its surroundings, sleeping to conserve energy, asking for help, or whatever.

The only thing that the operator should have to provide (and thus the only technological limitations (apart from my own competence or lack of)) are electrical power in the form of battery recharging and supplementary instruction via a WIFI LAN connection.

LCAV should be able to do what it wants and justify its actions in a rational manner. Coherent action is the real goal.

Some progress

2007-04-17T12:14:00.000-07:00

After a little further investigation I have decided not to use the K8055 as a motor driver as previously planned. This is due to the limitation of the PWM outputs on the board. And so instead, I'll probably use the PWMs as ultrasound drivers instead. Anyway, so far I've allocated the following:

(AI, AO, DI, DO = Analog Input/Output, Digital Input/Output)

AI5 = KILL button. The sole purpose of this is to COMPLETELY shutdown the robot FAST, before it kills someone. Lets we forget the carnage that was cut from the "Short Circuit" movie.

AI1 and AI2 These are addressable as both on/off and also as counter values. It may be useful to use these as X axis and Z axis tilt counters in order to detect rough terrain.

AI3 This may be used as a battery-low detector, for the motion battery. When fully charged this will be 1, if battery drops to 0 for 100 readings in a row then go into a safe status and alert user via logging or signals.

AI4 Similar usage as AI3, but for the sensor battery. In many ways this is more vital than motion battery status. Mainly because it determines behaviour governing the still powered motors. We don't want LCAV to unleash electric death upon all who stand in its path simply because someone turned the garage lights off. LCAV shouldn't be that grumpy.

DO8 = Heartbeat This will power a highly-visible, high brightness LED that should flash at 2Hz which indicates that the core systems are optimal and that LCAV hasn't gone insane with the lust for human blood.

D01-DO7 As yet undefined.

AO1, AO2 Front: left and right ultrasound. I need to think about this in detail. Might turn out to be stupid / impractical.

Velleman K8055 Board

2007-04-14T09:03:00.000-07:00

Ok, the first part of the project has begun in earnest.

With the help of this library I've been able to modulate the digital outputs of a single K8055. Sounds simple enough but I spent most of today trying to compile that library into a C++ binary, it just wasn't having it, all manner of ugly hacks and kludges prevented -ansi and -pedantic being usable.

Anyway I'm not here to flame that library because it is actually rather easy to use (once I'd given up and compiled it into a plain vanilla non-fussy C program instead). I'll need to measure the performance of this board at some point, then I'll be able to judge how detailed the environment-scanning algorithm can be.

Next thing though, will be obtaining a matched pair of stepper motors that can be controlled by the k8055. Possibly gearboxes too. If I can get LCAV moving on its own then thats a good starting point for the rest of the project.

W.

The Monster Has A Name

2007-04-12T10:32:00.000-07:00

This is the blog for my big Summer project.

In a nutshell, I'm building a small autonomous 'robot' (although I hesitate to use the term).

It will be basically a PC mother board mounted on a ruggedised chassis and running some kind of Linux distro. Upon this I shall be building all manner of insults unto the Lord, such as GPS, wireless LAN, caterpillar tracks for mobility and sensors (digital and analog) for to see thee with.

At the time I write this entry, I have done nothing but purchase a few likely items and test out one or two suitable host Linux Distros. The one I'm gravitating towards is Damn Small Linux (Google it). It takes hardly any resources and it runs entirely in RAM if need be. That makes it a good candidate for host OS.

I have not yet designed the chassis or selected a good motherboard/PSU combo. It will almost certainly be a Nano/Pico ITX form-factor motherboard. Paired with a 12V SLAB (sealed lead-acid battery) to supply power. Motive power will most likely be a second SLAB of different spec.

Initial thoughts have guided me towards the Velleman K8055 experiment board for prototyping this robot (henceforth monikered LCAV).

That's all for now. I'm off to do a bit more planning.

Wossy.