A tabletop balancing bot

[Mark Johnston]

I mentioned in a short video meet with a few HBRC folks last week a balance bot that is moving along nicely.   Short video is:

https://drive.google.com/file/d/15NY0icU2I5-YUrM4z6C30o05U69H_Lwp/view?usp=sharing

- Uses Nema 17 semi-beefy steppers run from A4988 stepper drivers.  

- Dev is for my own Esp32 Dev board seen in MANY of my things http://www.mark-toys.com/Esp32_Dev_Board.html

- This fires up a web server but I want next to use a RC controller to run it about

At this time it has 3 PID loops.  1 for balance, 1 for position and 1 for speed.  I think the PID code is very acceptable for ballance but I will not be able to evaluate speed and position till I get my FlySky controller on Saturday.

Just showing as I did mention this to a few folk last week.

Mark of mark-toys.com

[Chris Albertson]

Is there are good source of information about "balance bots"?    I really need to understand the balance PID and some theory about modeling balance.    Yes I can Google but I get a billion hits.   I assume you had to learn this to make the 'bot work.

Today I might have a dog-kinematics working.  The test software does forward calculations then inverse and check for a match.  Then adjusts the parameters and does more full-cycle tests.  This is a stand-alone package I'm assembling.  Next I want to think about leg motion I have that working in 2D only now. 

But "balance" is coming, and I know I don't understand it.  A trotting dog spends half his time standing on two diagonally opposing legs, and I see this as exactly the same problem as your robot.     My plan is to move the pair of legs that are in contact with the round either left or right to maintain balance.

Not handling balance is why so many quadruped robots use "feet stamping" to walk.  It is a simple algorithm that cycles servos between two positions fast enough that the robot does not have time to fall over.  The better robots can stand on two legs for a fair amount of time.

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/ec9c4dbc-e0ad-485e-b738-8f173be4b9dbn%40googlegroups.com.

--

Chris Albertson
Redondo Beach, California

[Sergei Grichine]

For a two-wheeled balancing robot, search "nbot balancing robot" - D.P.Anderson's classic work. There is plenty Arduino code on github. DFRobot sold kits. But balancing a legged robot is, of course, different.

Best Regards, 

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/CABbxVHu5MykOFotwKOcLAHBY5VxJPV82NAP%2BZGmnCdhSJqkQag%40mail.gmail.com.

[Mark Johnston]

I should have added that I 'started' with but have greatly hacked this code   https://gitlab.com/kloppertje/balancingrobot

The youtube that explains next to nothing but is fun is:   https://youtu.be/D7hvI_Tb0o4

The page that is very valuable is:    https://elexperiment.nl/2018/11/high-speed-balancing-robot-introduction/

There are a great many segway bots based on the Nema 17 motors.  This one is focused on use of Esp32 so I liked it.

This is by Wouter Klop but a great deal of code had 'hacker' sort of issues like hard coded constants and extreme lack of comments.

I do feel that Wouter Klop DOES get PID and all of this technology so i will give him benefit of the doubt to say he offered it all and this was just some 'diversion' project.

I am VERY well aware that to go from working project to fully documented and supportable code is a MASSIVE effort so i wil say he put it out there but it is 'crude'.

I have my own code greatly documented beyond his so contact me if you 'really' are doing this.   Don't ask me if you are NOT really going to do this.

There is near zero discussion of the PID parameters so I added a great deal of explanation there.  I think 'Wouter' gets it but mere mortals will have to struggle with his original code (with near zero comments).  His PID stuff is written in a super concise way that is not at all 'self documenting' in reading it.

Ideal PID code for readability separates the P, I , D components for the next output sample nicely in variables.   He jams it all together with zero comments. 

I did 3D printed wheels, the lower 'chassis' for holding the Nema 17 motors then made my own upper body to nicely match my own bot seen in the video.  I used some of his lower body ideas but found other wheels that are for 5mm shaft of the Nema 17 motors and had to enlarge them a tiny bit to properly hold these big O-Rings used for the floor surface 'tires'.   Nuff of that except to give you the thought that the body of a robot generally always needs tweeking for what materials you can have and find.

Today I got my   'FlySky i6'  RC transmitter and I already had a receiver but await a receiver with direct PPM output.   I will at this time try to use RC filter into a couple A/D inputs.  I am learning a great deal about RC control that I feel is an area I lacked before so 'it's all good'.    For details on the FlySky i6 which is 6 channel but there are hacks with firmware for up to 10 channel.  This controller has a great many control switches, joysticks and even pots so I think I will get a lot of milage out of this transmitter. The main thing about RC is there are older AFHDS receivers and then the newer AFHDS 2A receivers that are a HUGE improvement. 

So high level:   I hope to have full movement ability with this RC controller that is FAR FAR FAR more 'friendly' than the onboard webserver and I suspect more responsive as well.    This will be a fun weekend I suspect!!!!!

Mark

[Mark Johnston]

Oh, I neglected to answer the question of Chris.   I feel the code this guy has although not written for documenting this process WILL be of value to you as I know you known how to 'grok' source.     The short answer is this code uses 3 pid loops and his webpage nicely in a basic way shows a block diagram.   He has one pid loop for balance which is   pidAngle loop.  Then he has one for 'position' and one for 'speed'.     So in a nutshell he prioritizes balance then adds/subtracts components required for position and speed.    Position is nice in that I can pull the robot away a bit and it returns to starting spot thus is demonstrating balance and position.  I will know more about speed which basically modiies position perhaps late today or tomorrow. 

[Mark Johnston]

I am attaching my current hacked main.cpp as I feel it s massively easier to get it than his  'competent hacker near-zero commented' code.  

Do note that MY code attached is specifically setup for my Esp32 dev board but I (unlike him) have nicely grouped together all Pin/GPIO defines with comments so my code should be massively easier to follow.    Consider it to be changed a LOT but at least it helps document balance bot a bit better.

[Richard Chycoski]

Mark - I've worked on so-called "production grade" code far worse - the
assembler code had been replaced but the comments had not been edited
(and no longer made any sense for the existing code), there was
self-modifying code, and tricks were used to refresh dynamic RAM with
far fewer instructions than should have been expected, because the
wizard programmer sprinkled the supervisor with figured out instructions
that had byproducts that tickled CAS lines. ;-)

Kids, please do *not* do this at home!!!

- Richard, VE7CVS

[Chris Albertson]

Thanks a bunch.  I read it quickly, top to bottom.    I found the guts of the algorithm, I think it is just this one line of code

avgMotSpeedSum += pidAngleOutput/2;

This was my guess about getting a dog to walk, do all the walk-stuff then apply a "balance bias"   That is exactly what the above does.  (The dog moves in two dimensions so I add a "balance vector" but, same idea.)

Oh, and I liked where you turn off the control input if the 'bot is too far from  vertical.  You need an RC servo with a stick to lift the bot back to upright.    My 'bot will have legs and I hope I can find some may to make it self righting after a fall.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/c6844aaf-e77d-47b9-80f9-50a85d561331n%40googlegroups.com.

[Mark Johnston]

Am adding velocity and turning now using a  FlySky FS-i6 controller.  Have added on 2 pins GPIo change interrupts that correctly are showing the FlySky controller PWM input values nice and stable.    So maybe tomorrow my wiring will be complete and my 'push goal' so to move this bot around using the FlySky 

This by the way is a very well thought of 6 channel AFHSD 2A transmitter that I have prior to buying it found that there are some hacks to make custom firmware to support the many separate switches and a couple extra pots.   I only have a AFHSD receiver at present but am doing inbound PWM decoding on the ESP32 so 'all is well'.    I'm very much enjoying the learning experiences around FlySky RC xmitter/receivers and the signals involved.  ALWAYS more to learn!   RC control ROCKS!

I have programmed my Esp32 C code to correctly use PWM GPIO state change interrupts on Platform Io code to properly interprit my velocity and 'turn' pwm channels.

This is getting very cool and a new area for me to really dig into RC controllers and receivers.

[Chris]

In response to Chris Albertson's request for, "understand the balance PID and some theory about modeling balance "  :

In Steve Brunton's series, he finally gets to the meat of balancing robot control:

https://www.youtube.com/watch?v=qjhAAQexzLg

But you really need to grok the whole framework of the state space method.

If you have the time, the entire series playlist is fantastic:

https://www.youtube.com/watch?v=Pi7l8mMjYVE&list=PLMrJAkhIeNNR20Mz-VpzgfQs5zrYi085m

This was my attempt to give a walk through the process:

https://youtu.be/1sSmTWue2Sw?t=1513

-Chris Tacklind

[Mark Johnston]

Nice stuff ChrisT!   Thanks.
I now have full ability  to read 2  PWM RC inputs for velocity and steering so that is some progress.  My PPM receivers get here next week but frankly, I have nice velocity and turn values now so may not even use PPM but the code seems to have proper decode if I ever decide to go that route.   Not now, bigger fish to fry.

Although not entirely unexpected, the code goes non-linear when I enable use of said RC control values.   Some sort of scaling or other issue that is not at all documented in this codebase is likely in need of sorting out.    Perhaps tomorrow.   I am closer, that is a +.   Not loosing ground.  

Also worked out a problem with use of wifi makes my Esp32 do 'brown out' faults.    Solution for now is disable WiFi, I am doing this all RC at this time anyway.

For anybody reading main.cpp, it is dynamically changing so don't use the earlier posted stuff.   Patience will pay off.   Wait for solid main.cpp

Mark

[Mark Johnston]

Up and running and now has the name BalBoaBot is this Esp32 based balance bot using Nema 17 stepper motors.

Had to do some more tweeks but it is controllable with my FlySky FS-i6 RC controller ... I just need to learn how to drive it a bit better ... lol

https://drive.google.com/file/d/16eFSEeM0CRTL_QDHk4RGwRxuEK6mRzcs/view?usp=sharing

This unit uses my Esp32 dev board from my mark-toys.com site.  I feel most Esp32 dev boards could be used if you adjust the section where I clearly define each input and output.  There are some restrictions on certain Esp32 lines so a little know-how would be required for use of any other board but it's doable.

It handles really well, I'm lovin it!   I'll be updateing it to move around an arm and do other things as time moves on.  

[Mark Womack]

Bravo! Really well done, Mark! 

Mark

--

You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hbrobotics/59329a07-8143-4156-a393-92b03db4d915n%40googlegroups.com.

[Mark Johnston]

Wow!   I have found it is extremely easy to drive it around and rotate it in place and do all sorts of shenanigans. This is certainly the fastest and easiest to move about at high speed ( > 1 Meter/sec )  I stop moving and it snaps back to vertical.   So very fun.  I now have to make some sort of body/shell on it for 'croud appeal'.  This would 'Kill' at Maker Faire sort of event if it looked 'fun'.  Upright bots are way easier for non-robot-knowledgable people to relate to if they look at all 'human'.  Im currently thinking 'gnome' as it is about the size of a garden Gnome.   Leaves room for all sorts of anamatronic things, even eyes perhaps!