[Robot] Dagda

Sparks

How about this; post one thread describing a robot you have built; give it a [Robot] tag in the title so we can spot those kind of threads, and let us see what you've done? And to get us started, I'll steal an earlier blog post or two (I haven't written the third blog post just yet, mind you...):

Dagda

Meet Dagda, which represents a good few years of my past life! It occurred to me recently that I’ve never put any details of the robot up on the web, so I figured I might as well correct that!

Dagda started life as a donated piece of hardware from Kentree, a small company in Cork who made bomb disposal robots until they were sold on to a British company and then a Canadian one in 2004. It was initially much smaller and designed to drive under cars to look for car bombs:



However, for our planned project – which was to research alternative approaches to teleautonomous behaviour – we would need more in the way of sensors than a single CMOS camera, and we would need an onboard computer (the original Dagda was remote-controlled with no onboard processing). There was also the point that as it was supplied, Dagda wasn’t exactly… well, working



It doesn’t look too horrible, but none of the electronics were functional at all. The physical hardware – the chassis, drive train gearing and wheels – were fine, and the motors were still working too. The CMOS camera sensor might have been functional, but we didn’t have any specs on it or how to interface to it. And what circuitry was in the chassis was basicly toast on arrival. I was of the opinion that the hardware should be dumped and a COTS system bought in; my supervisor thought it’d be a lot easier to just use the chassis as a base to build a new research platform on. So first things first, gut the robot of all broken circuits and see what’s left.



Not very much, as it turns out. In fact, the encoder mounts you can see in the middle of the main chassis compartment’s sidewall, while working, had to be dumped as well because they were attached to the drive chain rather than to a freewheeling wheel – so they had no way of telling if wheels were slipping or not. They could sense if the wheels were fully locked, but that wasn’t of much use to anyone (odometry is notoriously inaccurate even under the best of circumstances, but when all you’re sensing is a gear in the drive train, it’s almost a waste of time). So they would have to go and be replaced by sensors on the two free-wheeling wheels at the front of the chassis.

So, starting from the basics, the design had to have a power source as the robot was to be autonomous and tether-free. That meant lead-acid batteries, and they had to physically fit in the battery compartment and provide enough power to run everything for at least an hour so we could get experimental runs long enough to produce useful data. I also wanted to monitor voltage and current levels and condition the voltage levels because I knew that was going to be a problem later on. Next was motion – we had motors, and they were fine (if a bit odd, they were truck windscreen wiper motors). We’d need motion control though. We’d also need odometry, as mentioned before. We also wanted sensors – cameras, and a laser scanner for measuring distances. There was also to be sonar (though that was later dropped because it was about as noisy as the odometry and far less convenient). We would also need some sort of computer for running the whole system, obviously enough. Bear in mind that this is 1997 we’re talking about here, and small cheap computer platforms with enough oomph to do image processing and motion control didn’t really exist. So we went with a then top-of-the-line PC104+ platform running linux. Which was not cheap.

And of course, all that kit has to be bolted somewheres, so the chassis had to be enlarged with an extension frame. Design sketch time!



Now we had no metalworking capabilities at all in the lab (in fact, we had damn near no hardware manufacturing capabilities at all in the lab, which was a bit of a pain for a robotics lab) so we drew up the sketch in a more precise technical format and sent it off to a local light engineering company who built it for a rather extortionate price:



Sorry about the fuzzy photo by the way, this was 1997 and decent digital cameras cheap enough for a postgrad student to afford simply didn’t exist – these photos came from a reasonably high-end camera that could get all the way up to VGA resolution on a good day with a following wind…). The top and middle plates in the frame were removable with allen bolts and side panels could be attached using velcro to make everything look a little less complicated.



So now we had the basic frame taken care of, it was time to source some batteries.



These proved to be way too large, so we did source some smaller ones later on. The meter was to give an idea of the charge level in the batteries and was mounted in its own little power switching box off to one side. Here’s the power switch/meter box in the final build:



And here’s the final batteries and basic power wiring and some labelling:



Notice that the front-mounted CMOS camera has been ditched and that the encoders in the main compartment have moved and are now out on the front drive wheels. They may look a bit more complicated; that’s because they are – the mounting was a bit more difficult to arrange:





The two white plastic shields wouldn’t protect against much, but they were only there to protect against casual bumps in the lab, not for actual tootling about outside. Also, those two things on the front of the robot that look like buttons, aren’t – they’re lights to indicate power for the main systems and power for the motors (which were on a seperate, higher voltage rail).

So that’s the frame, the power and the encoders. Next up, the motor control. There’s two parts to this – a PWM source and a H-bridge to do the actual power switching. The PWM source was a COTS solution – a motion control board which I’ll talk more about later. The HBridges turned out to be one of the larger pains in the project, and also a major point of personal development for me

Sparks

The first stab at this was… a bit weedy. Standard circuit design, using a PAL for the switching logic and some rather underspec’d mosfets for the switches (I’m pretty sure the original design used actual mechanical relays but it was hard to tell from the toasted circuitry that came with Dagda on the first day):





If those heatsinks look a little small, that’s because they are; and if the whole board looks a little home-made, that’s because it is. I did the circuit design and the PCB layout, I etched the board myself (I still have the stains on one of my work shirts – ferric chloride is deeply nasty stuff), I hand-assembled and soldered the board myself, and I got to watch as parts of it melted under full load. So there was symmetry there at least…

My second attempt was a little better, in fact I think it was quite up to the task:







As you can see, much beefier heatsinks, much better arrangement on the board, much more mechanically robust, and it even had flashing LEDs to indicate function (very 1950s B-movie). Some of you may notice that there’s a mild resemblance between the arrangement of the heatsinks and the barrels of a double-barreled shotgun. This wasn’t actually intentional, it was just how the PCB layout came out in the end. Unfortunately for me, the day before one of our demos, I found that it was a functional similarity as well – the GAL chip which contained the logic was misprogrammed (I had a + instead of a – on some line of code) and instead of switching the power rapidly on and off across the motors, it basicly short-circuited two car batteries across a single transistor. There was an ominous humming noise, and as I looked down on the board wondering what the LEDs were indicating, the MOSFET gave up the ghost and vapourised, superheating the ceramic casing which then explosively shattered – and the heatsinks channeled the fragments straight up past a rather surprised me. I got a nice nick under one eye and learnt the difference between electrical and electronic…

…and I also learnt that this wasn’t what my PhD was about, so for the third attempt, I bought in a COTS H-Bridge board power rated to the appropriate level

So the HBridges, the 12V-to-5V power convertor (bought off-the-shelf), and a distribution board, all went into a cut-down standard 19-inch rack, which fitted nicely into the main compartment:





Tucks away very neatly down there. That double PCB you can see on the first level of the extension frame, by the way, was the sonar interface board. Bought in, off-the-shelf, and dumped eventually because the sonar sensors were so noisy (and because we had a laser scanner that was far better than them).

Sparks

The cameras we used were standard research ones we had in the lab at the time – fairly straightforward things, whose resolution would now be too low to be used on the most basic mobile phone (and which were strictly grayscale only), but which were fairly high end at the time:



They were small and light, which was a plus, but they needed special cables and power supply boxes, which was a bit of a pain:





Still, they let us get video reasonably cheaply. We did have another camera sensor, mounted on the very top, which Niall Winters was using for his PhD which was on Omnidirectional Video - it was one of the first panaspheric cameras, and again, mostly home-made:



Custom-made moulded plastic base and top, vision-quality transparent perspex tube and custom-ground mirror mounted at the top. These days, you can buy these off-the-shelf; not so much back then! Niall’s initial work was capturing the image and “unwrapping” it to get a single undistorted rectangularish picture from the initial input image, and that would feed into our teleautonomous control system; but because his PhD was on a tangential topic to this, the two systems were kept as decoupled as possible. The camera itself was mounted at the very top of Dagda to get the best field of view:



At the base of Niall’s camera there is a pan-and-tilt camera, one of the more advanced cameras we picked up in the lab. The idea was that the panaspheric camera could give a general view to an operator, but the pan-and-tilt camera could zoom in to pick out any key details.





The canon was about the most polished camera we ever put on Dagda – today, it’d almost be considered an antique!

Of course all these cameras have to feed back into something, and in this case, it was a pc104 framegrabber based off the BT848 chip – which obviously means that you can use linux on the platform doing the computing.

Well, it was obvious back then at any rate

As I mentioned earlier, we used a PC104+ platform for the main computer on Dagda. The thing to remember is that in its day, this was the top-of-the-line in embedded hardware, a real research system with far more processing power and memory space and disk space than any production design would have used; it ran linux (Debian 2.0.35 for those who remember ) to give a flexible development environment at a time when most embedded systems were in C if you were lucky. This was rather a big deal at the time – today almost every commercially built robot has some form of linux in it (and darn near all of the research platforms are linux based – and running python on your robot is no longer the prodigious feat it once was) but back then it was a novel thing to do.

So when you learn that the system used a 200MHz original Pentium processor with a whopping full load of 128MB of RAM, don’t laugh too hard Here it is, the Ampro Littleboard P5e. You won’t find it on the web anymore, it was actually obsolete the first time we had to call tech support!



Stacked on the PC104+ expansion bus on that board was an Imagenation PXC200 framegrabber which had five inputs (four monochrome and one colour, multiplexed with a composite-video input). It was based on the BT848 chipset, but I had to write some custom tweaks to get the standard BTTV driver to work on it (those tweaks got accepted into the codebase, which was neat because that was the first really useful open source code I’d written).



Stacked on top of the framegrabber was an Ajeco ANDI-SERVO motion control board with two output channels, which came with no linux driver – and that was the second useful bit of open source code I wrote (more on that in a later post).



And stacked on top of that board was a PCMCIA adapter board. We didn’t actually add that until a bit into the project, when we got a very advanced wireless communication system in the computer science department (you might have heard of it, it’s called wifi today… :roll: ). Another late addition was a high speed interface board to read a rotating laser scanner, but more on that later.

Sparks

All of this kit needed a case (and somewhere to fasten the connector ports to), so a plastic box got ordered from Farnell and then sent off to be custom-cut to produce… *drumroll* the LunchBox!



As you can see, we didn’t have SSDs or even laptop drives Over time, the handles up top were removed and the PCMCIA slot adapter installed there, and some other internal changes made, like the orientation of the disk drive and power take-offs for cameras and the like, but that’s the basic setup right there.









In the end, the Littleboard proved to be Dagda’s achilles heel. Late in 2001, it began to fail its boot sequence tests and would go into an endless rebooting cycle. It took some weeks to finally get an answer, but it finally got written off as being (in technical terms) “shot” by Ampro. By that point it was not just out of warranty, but fully obsolete (their closest match on their product line was about six versions removed from our board) and with the hardware budget coffers empty, that was the death knell for Dagda as it stood. It could still be restored (it’s still in the computer science department in TCD), if a new PC104+ board could be bought and fitted, but that’s neither likely to happen nor is it really a good idea, for reasons I’ll go into in the next post, on our laser scanning sensor, the later modifications to Dagda, and the lessons I learnt from building it.