Balancing Robot


184 posts   Page 1 of 8   1, 2, 3, 4, 5 ... 8
by pygmy_giant » Fri Apr 27, 2012 1:58 am
Anyone else think balancing robots look cool:

http://www.geology.smu.edu/~dp.....robo/nbot/



I am attracted to balancing robots as once they"ve got the balancing licked they are more stable on rough terrain than bots with more wheels, and I like the way they mimic human behaviour.

Such a complex project might be beyond me but it seems like a good pi project.

The biggest challenge would seem to be getting the gyro / accelerometer to work.

I wonder if there is a shortcut way of using an ir proximity detector to sense distance from the ground fore and aft in a cybernetic way like the microswitch used in this project:

http://technabob.com/blog/2008.....hen-falls/

Crude I admit but perhaps more do-able.

Measuring the angle of the bot seems to be the key…

I am attracted to balancing robots as once they've got the balancing licked they are more stable on rough terrain than bots with more wheels, and I like the way they mimic human behaviour.
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by john_wage » Fri Apr 27, 2012 5:19 am
I'm no expert for sure, but it has been my understanding that using a lower level micro controller to directly process the input and necessary outputs is faster than running it through a laptop (or RPi) and process it in an OS type environment.

I have no idea if the RPi would be fast enough, it might very well be, just adding my 2 cents :-)
Posts: 156
Joined: Thu Mar 22, 2012 6:20 am
by chorlton » Fri Apr 27, 2012 5:41 am
There's this Lego NXT Segway.

The RPi is surely more powerful than the Lego NXT Controller, although the NXT is self contained in terms of batteries. This one is simply using a light sensor to determine the angle. I say "simply" but that's just in terms of building the model rather than the programming (which is a PDI feedback controller). A gyro sensor might be more reliable.
Posts: 50
Joined: Mon Feb 06, 2012 1:57 pm
by gordon@drogon.net » Fri Apr 27, 2012 7:06 am
CPU "power" and speed isn't the issue for things like this - you can do it on a 8-bit micro running at 16MHz.

And that, or something like that is by far the best thing to use too unless you write your own OS for the Pi.

Out of the box the Pi runs Linux - a multi-user, multi-tasking operating system, and it's the multi tasking bit that will stop projects like this working... Your program can be pre-emptively interrupted at any time for any time too - e.g. a cron job kicks off to scan your SD card just as your robot takes its first steps, and it causes it to miss a few gyro readings and before you know it, you've fallen over...

However the Pi can be used for "overall control" - so if you had a dedicated micro-controller doing the actual balancing act, then the Pi can feed it instructions - like "take 4 paces forward", "turn right 15 degrees" and so on. The Pi handling the higher level stuff like reading GPS, following a map, camera & wifi, etc.

Heres a real example: Right now, I left my Pi running overnight talking to an arduino via USB serial - and looking at the LEDs on the Arduino, they're not running smoothly or fast... Switching inputs to my monitor to the Pi and I find the X windows screen saver has kicked in causing everything to slow down!

Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1543
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by SN » Fri Apr 27, 2012 9:03 am
chase a link on the youtube video - this is VERY cool

feature=related
Steve N – binatone mk4->intellivision->zx81->spectrum->cbm64->cpc6128->520stfm->pc->raspi ?
User avatar
Posts: 1008
Joined: Mon Feb 13, 2012 8:06 pm
Location: Romiley, UK
by pygmy_giant » Fri Apr 27, 2012 11:23 pm
Wow! that lego bot"s really impressive.

I wonder if there is a way to switch off the os bits you don"t need in Arch Linux – it seems to pride itself on lack of bloat and customisability….

… I also wonder if Puppi running in Ram would be faster than an OS running from media….?

… maybe somekind of port of RTLinux would be good…?

I can understand that processing speed and resolution of control would be important if you don"t want your balancing robot to look like it needs a wee.

I wonder if a large heavy ball bearing sandwiched between two vertical Force Sensative Resistors could act as a simple angle detector... (cant afford a gyro)
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by pygmy_giant » Sun Apr 29, 2012 8:43 pm
Chibios is an ARMv6 compatible RTOS that might cut the mustard: http://chibios.org/dokuwiki/do.....hitectures
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by hunternet93 » Mon Apr 30, 2012 6:21 pm
You could do this by removing unnecessary parts of the Pi's OS. For example, remove the graphical environment and stop all but the essential system services. Linux also supports configurable process priority, i.e your can tell Linux to give a certain program most of its attention.
Posts: 324
Joined: Mon Dec 12, 2011 4:34 pm
by gordon@drogon.net » Mon Apr 30, 2012 6:53 pm
hunternet93 said:


You could do this by removing unnecessary parts of the Pi's OS. For example, remove the graphical environment and stop all but the essential system services. Linux also supports configurable process priority, i.e your can tell Linux to give a certain program most of its attention.



that's do-able and if good... You can also tell a progral to lock all it's memory in RAM and not allow it to be swapped out.. However while it's good, it's not perfect. I really wouldn't like to trust a balancing robot to it...

Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1543
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by pygmy_giant » Mon Apr 30, 2012 11:44 pm
Expect it won"t be long till an RTOS port. This guy made an analogue balance bot without any microcontroller: http://www.wa4dsy.com/robot/ba.....ancing-bot Maybe I needn't trouble the pi with such mundanities as staying upright...?

Or then again maybe I will... It could be do-able - there seem to be a number of affordable accelerometer / gyro / magnetic compass modules that pop onto an I2C bus... seems I could have all 3 devices wired up in paralell to the Pi's bus using only 2 GPIO pins - just got to wait for someone to crack the kernel drivers....

...Think my first step will be to get some meaningful input from such devices...

...the second half of the problem would then be to get some output to the motors via somekind of pwm h-bridgey thingy...

...the third half would be to work out the coding and algorythms in-between...

...the forth half could be to trim down the os distro to maximise control resolution...

I've read that balancing algorythms are mind boggling, but I'm initially looking at something simple like:

1) take readings from gyro and accellerometer and note current wheel torque

2) if gyro's rate of angular change is 0 then the vehicle must be balanced - goto step 5, otherwise...

3) calculate balancing torque as a funtion of angular change and g force vector off-set in order to move wheels under g force vector sum - continue to step 4

4) compare balancing torque and current torque and modify current toque value to approach that of the balancing torque proportional to the difference between them and then return to step 1

----

5) take reading from wheel encoders to determine vehicle velocity

6) if vehicle velocity is the same as the desired velocity then maintain the current wheel torque and return to step 1) otherwise continue to step 7...

7) 'unbalance' by reducing torque if velocity is too slow or increasing torque if velocity is too high (according to safe ammount read from table)

Under these rules 'balancing' could mean lurching forward, and counterintuitively, step 7 allows the wheels to accellerate ahead of the centre of gravity before breaking in order to slow the vehicle down and slows to allow the body to tilt forward before re-balancing at a higher speed...!

could it work?
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by pygmy_giant » Fri May 04, 2012 11:56 pm
Forgot to say that loop returns to step 1 after 7.

NB – a 2 axis gyro/accelerometer would allow safe cornering as relative wheel speeds could could be adjusted to prevent vehicle tipping over sideways – 3 axis sensors could measure inclines and declines – this data could be used alongside magnetometer(compass) readings and wheel encoder data to map terrain, although ultrasonic sonar pings would also be needed to accurately orientate / avoid.
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by morphy_richards » Mon May 07, 2012 8:01 pm
It seems to me that the speed at which the pi can respond wouldn"t be that much of an issue... After all us humans can manage to balance a broom on our finger using the same method and we don"t exactly react within n ^-10 nano seconds. (I think this would be a great school project too!)
User avatar
Posts: 886
Joined: Mon Mar 05, 2012 3:26 pm
Location: London
by pygmy_giant » Tue May 08, 2012 1:15 am
Thanks for the encouragement Mr Richards

I thought of using a two wheeled chassis with a castor - then the robot could work either horizontaly on 3 wheels or verticaly on 2!

Dropping down from two wheels to 3 would be easy, but I cant think of a way to get up from 3 to 2 .....?

Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by morphy_richards » Tue May 08, 2012 8:41 am
pygmy_giant said:


Dropping down from two wheels to 3 would be easy, but I cant think of a way to get up from 3 to 2 .....?


I cant seem to se your picture - it might be filtered by my schools system but I assume you mean something like this?



IE. A standard three wheel turtle that pulls a wheelie to stand up and become a balancing robot?

If that's it then a sudden burst of forwards acceleration would get it to the standing up position.
User avatar
Posts: 886
Joined: Mon Mar 05, 2012 3:26 pm
Location: London
by pygmy_giant » Tue May 08, 2012 9:37 pm
Hmm – could work, that"s how skool kids show off on their mountain bikes round our way….

… another way could be to have a 4x4 chassis (no diffs or pivoting wheels – just tank type steering) eg:

4wd chassis

This could then climb a wall with its front wheels like those popular toys that flip over and shoot back the way they""ve come, but instead of flipping over the robot could stop halfway against the wall in the vertical position and waddle off in balancing mode. It would be easy to add this functionality to a balancing bot, or you could start off with a horizontal 4x4 robot and then work towards mastering balancing …

… a further adaption could be to have a castor mounted "upside down" mid-way on the roof so that the robot has a choice of 2,3 or 4 wheel modes!

… a simpler configurarion would be 2 motors fixed to the corners of a board with a castor positioned such that the bord is at an angle of about 45 degrees. driving into a vertical surface might tip the robot upright…?

Not sure if there is any practical advantage to any of this other than adapting to terrain and saving battery (I imagine balancing mode would use significant power just to stand still).

Would be funny though.
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by SN » Tue May 08, 2012 10:08 pm
Could this concept be extended to a home built Segway perhaps with a big 6v battery for raspi power just below the axle line... ;-)
Steve N – binatone mk4->intellivision->zx81->spectrum->cbm64->cpc6128->520stfm->pc->raspi ?
User avatar
Posts: 1008
Joined: Mon Feb 13, 2012 8:06 pm
Location: Romiley, UK
by pygmy_giant » Tue May 08, 2012 10:15 pm
perhaps – be careful though: http://www.bbc.co.uk/news/uk-e.....d-14167868

I2C seems to be the way to go... affordable gyro/accelerometer/magnetometer modules on ebay (god bless the chinese). Also an I2C combined h-bridge and pwm dc motor controller!

Got to wait for them there I2C kernel codes to be cracked first though ... would seem to be just a case of wiring all these I2C modules up to the Pi's I2C bus, supplying the juice ... adding some clever programming and good to go ... all seems too convenient somehow ... what am I missing ...?
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by gordon@drogon.net » Wed May 09, 2012 7:07 am
pygmy_giant said:


perhaps – be careful though: http://www.bbc.co.uk/news/uk-e.....d-14167868

I2C seems to be the way to go... affordable gyro/accelerometer/magnetometer modules on ebay (god bless the chinese). Also an I2C combined h-bridge and pwm dc motor controller!

Got to wait for them there I2C kernel codes to be cracked first though ... would seem to be just a case of wiring all these I2C modules up to the Pi's I2C bus, supplying the juice ... adding some clever programming and good to go ... all seems too convenient somehow ... what am I missing ...?



An operating system that won't pre-emptively interrupt your cafeully balanced program, causing it to fall over.

Gordon
--
Gordons projects: https://projects.drogon.net/
User avatar
Posts: 1543
Joined: Tue Feb 07, 2012 2:14 pm
Location: Devon, UK
by rew » Wed May 09, 2012 9:05 am
If you want to do "balancing" on Linux, I would write the actual time critical part in a device driver. Then you can request an interrupt say 100 times a second, and this will result in quite regular interrupts and processing time for the time-critical part. The problem is that it's slightly more difficult to program than a userspace program.

As to the mechanical issues, how about putting a front-wheel on a swivel so that by pushing the wheel away from the body at the front the robot becomes more and more upright until the balancing mode can take over.
Check out our raspberry pi addons: http://www.bitwizard.nl/catalog/
User avatar
Posts: 396
Joined: Fri Aug 26, 2011 3:25 pm
by morphy_richards » Wed May 09, 2012 9:13 am
GordonH said:


An operating system that won't pre-emptively interrupt your cafeully balanced program, causing it to fall over.


Call me naive and stupidly over-optimistic but I don't think the effects would be that bad. I mean the Pi is accessing solid state storage only, so no time taken for r/w heads to go clunking around in a hard drive etc.

The Pi is no "K" but it's fast enough ... I mean 700MHz plus the ability to protect the memory for the balancing program and move it up in priority means that at least for vast majority of the time it would work very well. If the robot begins to overbalance in one direction the pi should still have time to make a cup of tea, mow the lawn, walk the dog and a have a nap after reading the paper and then go "woops" and correct the balance. If you think about it, something over balancing actually falls over really sl.o.w..w..w...l...l...l...y.

Even if from time to time something really does slow it down and it actually does fall over, it's not the worst thing in the world because it's not as if it's life or death, its just an experiment / hobby / learning exercise.

I'm really interested in the gyro / accelerometer / magnetometer modules you have found on ebay for my own robot project pygmy_giant. Any chance you could link some?
User avatar
Posts: 886
Joined: Mon Mar 05, 2012 3:26 pm
Location: London
by pygmy_giant » Wed May 09, 2012 9:56 pm
Hi

Rew – thanks for the practical suggestion. I don"t know enough about linux (yet) to write my own bits and bobs but am open to learning and suggestion.

Gordon H – I have been banging on about the need for a minimal distro / RTOS for Pi projects like this on other topic threads to the point of annoying myself. In the absence of a better solution provided by someone else, I intend to try to strip down Puppi / Arch Linux to the point where it only accepts input from the SD card / RAM and outputs only to the GPIO pins.

Mr. Richards – example ebay product no.s:

110676648622 – I2C DC & Stepper Motor Controller

230643656408 / 140726174048 / 270953273103 – Magnetometer

270960242097 – Accelerometer

170832632390 / 170832639961 – Gyroscope + Accelerometer

251054636309 / 300679310751 / 330708962652 – Gyroscope

Loads more out there changing by the day… can"t wait for I2C support ( http://www.raspberrypi.org/forum/projects-and-collaboration-general/linux-device-drivers-for-rapberry-pi-on-board-io/page-4 ) – anyone have experience of I2C and its capabilities?

I find it hard to believe that the RPi hardware can"t  balance a robot, but accept that some os mods and driver tinkering may be necessary.
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by hunternet93 » Wed May 09, 2012 10:24 pm
With proper configuration, I'm fairly confident the the RPi could keep up with a balancing robot. A quick search found this: http://www.linuxpcrobot.org/?q=node/4 which used an Intel Atom based board running Linux to control a balancing bot.
Posts: 324
Joined: Mon Dec 12, 2011 4:34 pm
by pygmy_giant » Wed May 09, 2012 10:37 pm
Thanks hunternet93 the article states

"Regardless of the operating system and computer used on your robot project, unless it is a very tightly controlled “real-time” or embedded system, you will not be able to count on very precise time intervals. Most general purpose operating systems like Windows, Mac OS/X, Linux, and the various UNIX ® systems are horribly sloppy when it comes to timing. You"ll have to code your algorithms to take this in to account. Fortunately many modern computers (like the Intel ® Pentium and later) systems can often maintain very precise timing information in hardware. This means that rather than code your algorithms based on precise process scheduling, you base them on precise time measurement."

So use of clock and interupts needed to combat "horribly sloppy" linux timing…? as suggested by Rew / GordonH…?

Will bare this in mind – nice to see its been done before on Linux – Perhaps the QtonPi distro would be best as they mention 'Embedded' Linux on the Qt wiki - http://qt-project.org/wiki/Sup.....dded_Linux
Ostendo ignarus addo scientia.
Posts: 1569
Joined: Sun Mar 04, 2012 12:49 am
by hunternet93 » Wed May 09, 2012 11:24 pm
I believe the article means your should always use the CPU's clock instead of relying on the OS to run your code. As long as the PID program is given high priority, it should be more than fast enough to keep a robot balanced. You would need to make sure the PID code has enough CPU to function as more code is added (i.e. sensor processing, networking, etc.), but I think it could be done. Audio decoding/playing requires similarly low latency and the Pi's CPU can handle it.

To set a process's priority, use the 'chrt' command:

chrt -r -p 99 [pid]


The above command would give the process [pid] maximum priority. For more info on process scheduling in Linux: http://www.cyberciti.biz/faq/h.....y-process/
Posts: 324
Joined: Mon Dec 12, 2011 4:34 pm
by morphy_richards » Thu May 10, 2012 7:13 am
I think this balancing issue is really crucial. I"ve seen several threads mentioning drones, flight even sailing and not to mention quad copters and robots. All will require finding suitable sensors, processing and then adjusting attitude in response to the input so you"ve kind of hit a lot of nails on the head with this thread (imho).
My plans for pi next year at my school mainly revolve around robots. I"m planning to hook every single geek, nerd, sci fi nut etc at keystage 3 and convert a few more and give absolutely everyone a chance to find out if they are switched on by this sort of thing before getting the chance to choose GCSE computer Science at keystage 4. (that and I want my ICT department to be swarming with assorted robots. Imagine the droid section on an imperial star destroyer and you"ll get the idea)
So... In this big long ramble what I"m trying to say is that this sort of project is exactly the kind of thing to get kids hooked by computing :-)
User avatar
Posts: 886
Joined: Mon Mar 05, 2012 3:26 pm
Location: London