All terrain mobile platform

Thanks to all contributers. Within this sub-thread we will further investigate alternative steering techniques:

[Steering] : The Base Station PC will read the joytick position and interpret it to two velocity data (differential steering), one for left and one for the right set of wheels. For the mechanical simplicity we are considering differential steering rather than Ackerman steering.

We are looking forward to receive your further contributions.

References: Steering :

Differential Steering : Ackerman Steering :

Thanks to all contributers. Within this sub-thread we will further investigate alternative computer HW, OSs and memory/disk etc alternatives:

[Base Station & Platform Computer] : Initially we would like to control our mobile platform via joystick interfaced to a notebook PC as "Base Station" with a wireless ethernet which communicate with a computer (which will be decided later on) on the platform (Platfrom Computer).

We are looking forward to receive your further contributions.

References: Computer HW :

Operating System: . . . ???

Thanks to all contributers. Within this sub-thread we will further investigate how to implement communication subsystem between Base Station and Platform Computer.

[Communication between Base Station and Platform Computer]: During the initial testing and debugging process the Base Station and Platform Computer will communicate with each other via wireless ethernet. We are expecting the wireless networks to wors fine within 50-100m radius (line of sight) without any special antenna and/or power amplifier. Later on the we are planing to have longer range (slower) two-way radio modems.

We are looking forward to receive your further contributions.

References:

Wireless Ethernet (Long Range):

Radio Modems (Long Range) : . . . ??

I normally use a simple homemade knife switch with a large loop ripcord handle to yank on, to kill power. it always works as a last failsafe method. I did tinker with using some IRF MOSFETS in parallel and drive them on 100% to provide a solid state on off switch, but I haven't gone all that far with this method yet. I think I'll do that for the next robot. My checklist still uses the tried and true steps like so, insert fuses, check and engage knife swtich cutoff, stand at the side of robot, second person has hand on emergency cutoff, and turn on power to CPU, and then turn on power to motor drive units. etc. Fuses or solid state crowbar circuits are a must too. Run the CPU system off a separate power system from the drive system. Thus you can test the CPU system separate form the drive system. depending on how big you build it, you need a good base to set the robot on so the wheels don't touch the ground while testing (for many many many hours). Do not ever just go full forward and then slam it into reverse, otherwise you will get a spectacular parts explosion as the drive train lets go.:) If it is late at night or on a holiday and the stores are closed and you run out of fuses, DO NOT PROCEED, give it up until you get new fuses or such items. You don't want to get injured or killed, because your not being safe. Late at night, been up 20 hours, early in the morning, that's when your likely to get hurt. Big robots are extremely dangerous.

wrote in message news:4168e288$0$23893$ snipped-for-privacy@news.optusnet.com.au...

Sorry just got back from the pub when posted, tend to revert back to some beer-fuelled "common sense" at that point. I guess I decided that no acceleration meant "not moving" having reviewed my post! :)

But this is the part that doesn't hold up to scrutiny. You are thinking of a hard drive intended for a static, safe application. A ruggedized hard drive, like those used by the military, cost many thousands of dollars. They are made just for this type of thing, and standard commercial drive won't cut it. Flash memory, even with a limit of about

1,000 write cycles, will still outlast the average hard drive in an abusive environment.

Two gigs of Flash would cost only a little more than the typical non-ruggedized hard drive. It's used for storing the OS and programming. RAM and EEPROM are used for program space and data, as they are in any typical microcontroller.

You must go solid state with a heavy robotic vehicle used in the "outback" (my estimate is that with a 25-35 horsepower gas engine this vehicle would weigh in the neighborhood of 400-500 pounds, minus its

100+ pound payload). Failure-mode risks are just too great otherwise.

-- Gordon Author: Robot Builder's Bonanza Budget Robotics:

These are good safety ideas, but none of them is an example of a failsafe implementation. You can use a normally open relay which is energized closed by your watchdog signal. You could also have brakes which are energized open by your watchdog signal. A deadman's switch is also a failsafe idea.

Mitch

Earl Boll> I normally use a simple homemade knife switch with a large loop

No I am talking about computer memory as in RAM, not a hard drive. You can get a gig of pretty standard pc2700 DDR ram for about £90 inc vat and postage. You can run a ram drive in that and it will be long lived, robust, extremely fast compared to flash and reasonably cheap. A gig of flash memory is about £60 for comparison. The idea is you use a conventional hard drive to load data into it at boot time then either totally remove the drive or spin it down and park the heads before you start.

I've no idea about the power consumption issues but if you are going to be running a pc on your robot then you probably already have more than enough.

can you post pictures of your robot(s?) that have this on them? I'd like to see some big ones. I'll post pictures of mine when I get something worth looking at built.

Rich

H-Bridge Driver Circuits: ================== Stamp-Controlled High Power H-Bridge 30v 30Amp 900W

. IR3221 Fully Protected H-Bridge for DC Motor 5.5v to 35v 20A High Power 24v DC H-Bridge motor driver circuit (Current rating =?) H Bridge Speed controller

Power MOSFETs: ============= IRF2804 40v 75A RDS(on) 2.0mOhm

IRF1404 40v 202A RDS(on) 0.004Ohm IRF1010E 60v 84A RDS(on) 12mOhm IRF3808 75v 140A RDS(on) 0.007Ohm IRF540n 100V 33A RDS 44mOhm IRF3415 150v 43A RDS(on) 0.042Ohm

I'm also sorry for being a bit snippy. I have an illness in my family which is taking up most of my energy. :(

-- D. Jay Newman

The best way (probably only way) of doing this is to use a SCAAT Kalman filter as at

under dissertation. This is not difficult maths if you have some maths training. It uses Jacobian matrices. But for a complete beginner at maths the thesis would be impenetrable (give it a try). There is no way of doing this with 'simple' maths, but you should be able to understand what the maths is doing.

A normal Kalman filter has to work with an 'observable' set of measurements (data from sensors), this means that the measurement must completely specify the position of the vehicle. With SCAAT it is much easier, as each single measurement (which is not 'observable' because it does not specify the position of the vehicle), can be incorporated into the filter one at a time.

It basically estimates the expected measurement, and compares it with the actual measurement, and adjusts the internal Kalman filter notion of position to be in keeping with the actual measurement in a statistically sound way.

I am implementing a SCAAT Kalman filter for a automated guided vehicle and would be happy to open source the code. It is not yet finished, and I have problems with the design of the filter, but the code is all present. It is written under GNU/Linux in C++, using Blitz++. I am keen to have other people use and test the code.

Let me know if you are interested.

Jack

THANK YOU for the reference and your offer to share your C++ code for SCAAT. We are now looking at the

and we are also looking forward to hear from you when we can work with your code.

Kind regards,

Roberto,

Please email me, so that I can email you a tar file of the code.

Jack