Welcome to Rocky's Website!

This site is dedicated to the discussion of the Rock Quoll autonomous universal robot/rover currently under development, called 'Rocky'.

Rocky is a Class II autonomously guided robot, designed specifically to work both inside and outside, navigating steps and stairs, recovering from flips and stuck situations, able to handle undergrowth AND avoid pets, and with a built-in homing behaviour for power management and recharging.

Rocky will also use some fairly complex 'pose' (heading, orientation, position, geolocation) algorithms - both to maintain a known pose, and to perform some simple mapping and navigation, starting with coarse 'geolocation' (GPS-based) and integrating that into a local dynamic map (IR/Sonar based). But that's a while down the track!

For now, on this site I'll be discussing things like :

how Rocky got started
the overall design process
why certain decisions were made, and the thinking behind them;
...and future directions.

How to find what you're looking for...

I've decided to break down the whole design process into more easily digestible lumps. So looking at the main menu at the left, I'll be discussing the history, design considerations, and subsystems. That way, you can easily turn to the area you're interested in, and ignore the fluff. Hopefully...

In the very near future, I'll be putting together contact and feedback pages as well, but for now, please use the forum to get things discussed.

What's here now?

For now, please have a look at the Photo Gallery, this will give you some idea of the level of detail I'll be covering in the various sections.

I've also started on Rocky's Chassis description. (I'm waiting for permission to use some of Venom's artwork on the site,so fingers are crossed!)

I've also begun describing the selection of the MCU and the steps taken to ensure it's fail-safe and so on.

The Circuit Description is also up and running now.

I hope you enjoy the site, and the concepts, and feel free to contact me if you'd like to see something not already covered.

-PC Pete

What's Rocky's status right now?

At this stage, Rocky is only just barely 'alive'. I reached a point in the development where a problem with the MCU needed the manufacturer to step in and faultfind (synchronous PWM issue). Because this is early in the design process, I need this working before I proceed further, and I didn't want to continue development without starting to document as much of the design fundamentals as I could. So it seemed a good point to stop and document!

Not only am I in the process of bringing various development blogs into this site, but I also want to incorporate nearly 11 years' worth of notes (more than 1700 pages!), various calculations, website addresses for components, gotchas, and future ideas.

Right now, as of July 2010, Rocky is a "rolling chassis", with rudimentary PWM motor control and battery management all working. I got stalled with a glitch in the eZ80F91 PWM outputs (only 2 of the PWM outputs work synchronously, Zilog is working on the problem), but my workaround is to use the 2 working PWM outputs. So steering (which uses the other 2 PWM outputs) is waiting for the fix from Zilog.

C woes...

Meanwhile, I've been reading up trying to find workarounds for the (many, many) problems I've been having with the C language (well, the compilation process mainly), and I think I know why some parts of my code weren't working as expected. I know now from my own painful learning (and from experts who don't disagree) that even fairly simple multi-file C projects are a pain in the arse, full stop, and even worse for developers coming from properly-integrated languages like Turbo Pascal/Delphi, Ada, Modula/2, Eiffel, Python, Perl, BASIC, Ruby, etc., etc.

After 25+ years of working with the wonderful Borland Pascal implementations, to go back to what feels like prehistoric code parsing (include files and scope rules were sorted out for Turbo Pascal in 1985!) and learning all the gotchas when using header files (like remembering to have an #IFDEF multiple-include limiter), learning all the pros and cons of #defines vs the badly misnamed "constants" (there's no such thing in C, I now know), and figuring out the bizarre and unhelpful compilation process (why do I have to add the same include file into the source AND into the makefile, for example?), I know now how to simplify my firmware design so that the hyper-simple C language compilation process can cope with what I need.

It helps that I'll be using Zilog's own RTOS kernel (Real-Time Operating System), since then the complexities of threading models, resource allocation, and timing are all done for me. And the Zilog Developer Studio is excellent at hiding all the bizarre and confusing command-line compilation traps and pitfalls, and it's well supported too. It also has an excellent boot loader and in-circuit debugger! If only I wasn't so spoiled by Pascal/Delphi...

I got so frustrated by the neanderthal intricacies of the C compilation process (even when masterfully hidden by the ZDS IDE) that I started teaching myself compiler writing so I could understand why the C language doesn't allow seamless includes, nested functions (WTF?) and all the other modern and elegant facilities that I've been accustomed to working with since CP/M days. But it turns out I'm not nearly smart enough to write my own lexical scanner/parser/compiler. Oh well, back to ZDSII and the page-oriented language I must master... If wishes were fishes, C developers would use Pascal!

Rocky's Current Evolutionary Status is :

This is what the noise and blather is all about.
At front is the core board, with the main eZ80F91 CPU module (purple daughterboard), power supply, I/O connections, motor control,
ADC, Accellerometer, programming/debugging header, I/O board connection, and so on.
The right front wheel is dismounted so the odometry disk can be seen (one for each wheel for fallback).
At this stage, the original motor (Fireball 55) is mounted, but it's been replaced by a better motor.

Sugar and Spice and Everything Nice...

That's what Rocky's made of!

The breakdown of Rocky's components (as of build 16.3, the latest one (see Mea Culpa below for things I know I have to fix yet)), is as follows.

Please note that all these parts and subsystems have been designed using commonly available hobbyist-type parts - with the exception of the accellerometer, all the parts are completely modular, off-the-shelf parts. If I can design this in Australia, imagine how easy it would be in Europe, Asia, the UK, or the US!!

System	Type	Details	Image
Chassis	Venom Creeper	See the Chassis page for details	See the Chassis page for more details...
CPU/MCU	Zilog eZ80F91 Module	256k + 1Mb Flash ROM; 16k + 512k SRAM; onboard JTAG/Programming header
Power Management	TI UC3906 SLA Charger, 6.2V SLA battery, AC input	6.1V SLA charger with auto switchover, and 3-stage charge control
Motor Control	Motormind-C dual motor controller	PWM/analogue/TTL control of 2x4A/26V motors, only one used
Dedicated Inputs	4 x Encoder inputs	For wheel encoders. Using one per wheel allows parametric analysis of traction in all modes, even including 4x4, since that uses non-locked differentials - when one wheel locks, the opposite one spins!
Dedicated Outputs	2 x PWM outputs (in addition to steering and motor PWM)	For "later" :)
Comms	Xbee Pro 100mW module	The Xbee will be used for telemetry and remote commands queued for execution - this will be during testing, at least!
Sensor Suite
- GPS	SUP500F 65-channel Venus634 Chipset	Sparkfun's most affordable reasonable spec GPS sensor.
- Sonar	4 x Devantech SRF-08	Earlier SRF modules used raw time-of-flight and other measurement options; The SRF08 uses simple I2C messaging protocols with direct sense measurements in inches or mm.
- Compass	Devantech CMPS03 3° resolution	The CMPS03 has been superseded by other, more fancy compasses, but this is a very easy, and very forgiving sensor compared to some of the fussier sensors I've tried. The only con is that it isn't tilt-compensated, but then that's what the accellerometer is for, right?
- Accellerometer	Bosch BMA150 triaxial accellerometer	I'm actually using a superseded device, the Bosch SMB350, which has the same pinout and major specs as the BMA150, which is what the final prototype will probably use.

Who cares about this "toy" 'bot?

I don't want it to be my "toy" anything.

I've been helped by some marvellous, generous people to get this project to the point where I'm ready to show it off. Because of this, and the way Rocky's been designed from scratch, there's a huge amount of flexibility in terms of the electronics, electrics, CPU, motors, steering, navigation, and sensors - and even the chassis can be upgraded or changed. There's nothing stopping anyone from using all or none of the design as a starting point for their own ideas.

There are only two rules for use of this design. They are :

Any vehicle you make based on this design (or parts thereof) would be welcome for display back here on this site. And...
It would be very much appreciated if any such design is presented as a "Rocky class" rover type. It's my one utterly selfish request.

If there is enough interest, we'll set up a "Rogues' Gallery" so you can show off your own roverbot. And for the hardcore out there, I'd be really interested in setting up a competition track, á lá Sparkfun's annual navigation contest. That way, improvements and ideas can be shared synergistically.

So even if what works for me doesn't work for you, there are plenty of design parameters that can be changed. In fact, you could even use an Arduino - or just about any other technology that you can think of - to control and manage this type of Rover. The possibilities are limitless. (Or at least asymptotic!)


Front/Rear transaxle module. A matched pair.	The "smarts". eZ80F91 module, motor controller, power management, accellerometer, ADC, etc	The gearbox module. The front and rear transaxles mount to either end, while the payload (electronics) is mounted on top, using standoffs.

This was actually one of the most important (and expensive!) design decisions made - to design Rocky from scratch as a modular project. The trick was to ensure that the modularity didn't come at a high cost in complexity. I'm not entirely sure the design "walked the fine line", and there were some compromises made, but hopefully the overall design flexibility will make the project appealing to as many folks as possible.

Forum! Woo Hoo!

We've now opened a discussion forum to help anyone with questions or comments about the design of this rover in particular, but also how to design and implement the many inter-related technologies required to make a good roverbot.

Please note that the forum is new, and bear with me as I get on top of the management thang.

Mea Culpa Time...

Oh, yeah, when I got the PCBs back from the manufacturer (Futurlec, in Thailand, a great service and great support BTW!), I suddenly discovered a few "Peterfaults".

The ADC chip footprint I designed was too wide for the MAX1239 sample I got from Maxim. I patched some fine lead wires across from the pads (and before anyone asks, I've fixed the footprint design for the next PCB run!)
The Bosch accellerometer (a BGA device, yuck) is too close to the line follower header for manual soldering. One or the other has to be moved...
I need to use ALL the ADC inputs so I can measure current INTO and OUT OF the battery and charger circuitry. Relying on switchover parameters to toggle a "battery low" input just isn't reliable enough. All these need to use zero-sensing : the sensor (0.1Ω resistor) is in the ground leg of the circuit, so I don't have to use a level shifter to protect the 3V ADC inputs.
I changed the GPS module from the now very hard-to-get ZX-4120 module to the cheaper, faster, and more sensitive Sparkfun SUP500F