Not a clanking humanoid, of course, but some sort of roving semi-autonomous vehicle.
I’m going to strip down a few old dot-matrix printers to get some reasonably powerful stepper motors; I want to dispense with an ‘umbilical cable’ to the controlling computer, so I thought I’d put it onboard; I have an old 486 subnotebook that will do nicely.
I might even chuck a wireless network PCMCIA card into the subnotebook, so that it can communicate with a much more powerful (but non-motile) computer which can handle some or all of the AI.
The idea is that eventually the machine will be equipped with a directable ultrasonic distance finder, so that it will be able to correct it’s notional position on a virtual map, plus a camera (with which I probably won’t be trying to do anything as clever as optical recognition, just take pictures) - I want it to develop into a kind of electric guard dog type of thing.
But my main problem for now is a purely mechancal one; for small ‘turtle’ style robots, it’s sufficient to have only two wheels and turn by driving them in opposite directions, but my robot is going to be quite large and fairly heavy, so there seem to be a few options:
[li]Still have only two ‘driven’ wheels, but have one or more swivel castors; my problem with this is that the machine may have to traverse slightly uneven ground and castors aren’t all that good at dealing with this.[/li][li]Have one pair of driven wheels and one pair of steering wheels (exactly like a car); this is going to make maneuvers more complex to program.[/li][li]Have front and rear pairs of driven wheels; turning being achieved by driving the front and rear wheel on one side in the opposite direction to the others; this looks like the best compromise, although I realise that the wheels are going to be subject to some sideways forces this way.[/li][li]As above, but include a mechanism to swivel the wheels so that they are aligned on the circumference of an imaginary circle, then drive them in opposite directions, then swivel them back to being parallel to travel in a straight line; lovely solution, but very difficult to implement.[/li]
So, any advice on this and any other issues I might face would be gratefully recieved.
If you want to try for some kind of dead-reckoning manuevering, stay away from the car-type steering. Most indoor mavigation robots use two-wheel drive with swiveling castors front and rear. Us the largest diameter wheels you can will help with the unevern terrain problem - of course, this means gearing your drive system motors high for lower wheel speed and higher torque.
You might also want to consider a six wheeled design, with the two central wheels slightly below the front and rear ones. This will handle irregular terrain better than the two-wheeled design.
Also, check out http://www.npcinc.com for some good drive systems. They’re not cheap, but pretty rugged and powerful - these people cater to the robot combat competitions.
As far as I’m concerned, the most important principle is to design the mechanical hardware, electronic hardware and software concurrently.
The uninformed might think that one should design the mechanical hardware, then design the electronics, then develop the software. Sometimes, you can get away with that. Often though, these elements will be interrelated, such that they impact each other significantly.
For example, what kind of compiler would you like to use? This will impact the electronic design.
Also, will you use brushed DC motors, stepper motors, or some other kind of actuator? This will impact the type of electronics that you use. (You may want to get a microcontroller with a pair of PWM outputs, or implement your own PWM capabilities using DAC’s and comparators.)
The electronic design may also impact the mechanical packaging, since you’ll need places to mount the circuitry.
So I say, come up with preliminary concepts for all these aspects, then refine them each incrementally and concurrently.
BTW, if you don’t use an off-the-shelf robot brain, you may be out of luck. Rumor has it that Positrons 'R Us may be closing down, due to the economic slowdown. You may need to locate an independent distributor, or harvest your own positrons from the wild.
Mangetout: You can put the castors on the front and back, but raise them and balance the robot such that when it’s going forward its nose is in the air and it’s running on the two drive wheels and the back castor. If it goes the other way, the back castor becomes the front. So the thing’s always cruising around with its nose slightly in the air. That gets you over rough surfaces and low obstacles.
I dunno about using steppers for drive motors, unless this is a slow, methodical robot. I’d think that two motor controllers and possibly shaft encoders for measuring rotation would work better.
Idea: if it’s a household robot in a house where the furniture doesn’t get moved around much, maybe you can rig up a beacon system - I’d go for radio or infrared - to help it find it’s way around.
The problem with castors is the wonky shopping trolley effect; when you reverse the direction of travel of a castor, the swivelling action can exert sideways forces causing one of the drive wheels to slip and throw the machine off alignment.
I’m thinking about including some sort of sensor based on a magnetic compass so that the machine can find an alignment datum.
I still fancy the four swivelling drive wheels idea, but it means having an extra motor to turn them (the idea is like this):
|<=>|
Driving: #
|<=>|
/<=>\
Turning: #
\<=>/
(The wheels are aligned in parallel when driving, but in a circle for turning).
for the control interfac, I’ve seen a board kit that connects to a PC parallel port and offers four stepper motor control outputs, eight logic in, eight logic out, plus one analogue in, this sounds ideal.
I’ll probably write the control software in Delphi.
Polaroid makes an ‘experimenter’s kit’ that includes one of the sonar transducers used in their auto-ranging cameras. The kits are cheap (under $100, I believe), and gives your robot the ability to do sonar rangefinding. There are also some very tiny gyroscopic Direction indicators available. If I were building an auto-navigating robot, I might use GPS for absolute positioning, sonar for manoevering through obstacles, and gyroscopes for determining position. You could go anywhere with that setup. And I think you could build that complete navigation system for $500 or so. Then maybe put a few bumper sensors onboard, and off you go.
I’ve made ultrasonic sonar distance finders before, but never connected them to a computer (they were analogue devices), but the principle is the same; you send out a pulse, start counting and stop counting when the pulse returns (or give up after a fixed interval), so that ought to be fairly easy.
On the software side, I was planning to develop it in ‘layers’
The ‘bottom layer’ would be a set of basic functions consisting of things such as ‘move 1 step forward’ or ‘turn 1 step clockwise’
The next layer would be a library of common and parameter-driven commands ‘Move x metres forward’ or ‘turn x degrees clockwise’ (there may be no real need to separate this from the layer below)
The layer above would be a database with a table of interlinked nodes (describing the robot’s ‘known universe’) with defined routeIDs to navigate between them, alongside this would be a table of instructions detailing the exact commands that are necessary to move from any node to any other(linked) node.
It’s then just a case of using a ‘travelling salesman’ algorithm to determine the best possible route from the current node to the desired destination (SQL/databases are great for this sort of thing)
Above this would be a layer that does the AI and allows the user to command the robot; if the machine has enough of the right sort of sensors, it ought to be possible to get it to ‘explore’ and add nodes/links to its universe database. This layer would also attempt to track the absolute position of the robot by trigonometry (you know where you started, you know in which direction and angle you have travelled, the rest is easy), periodic datum checks could be carried out against known landmarks.
GPS sounds promising, but the resolution may be a little coarse for what I had in mind; the machine will have to navigate in between aisles of picking shelves in a warehouse.
I can see me quickly running out of input/output lines; I may need to use say four or five of them as a binary addressing system (to tell the machine which sensor I want to interrogate), then another to carry the actual signal.
I LOVE THE IDEA!
a robot dog thing patroling a warehouse
COOL COOL COOL!
wheels: there was a thing on british robot wars(uk) a couple of years ago about these wheels. they were like a normal set of drivewheels, that drove forwards or backwards, ala notrmal wheels, but instead of a ‘tyre’ they had lots of wheels running perpendicular to teh direction of travel, so that they could be ’ pushed’ sideways.
i rember thinking about them, had a quasi(very childish diagram) of them drawn up, snd then some guy took out a patent on them.
grrr.
please, please, for me, could u make it whistle soem REALLY irritating tune as it pooters around?
that would make my day!
i know this is a bit ahead of itself. but have you got any ideas for a name?
i know i cant spell. i know i cant type. i know no-one ever reads my posts. so i dont care
