self balancing robot

[desijays]

Hello everyone,

Am sorry about this being a repost. But I was told that regarding the following topic posting in this section would elicit better responses.

I would like to design and build a self balancing robot something along the lines of "Botka - The barely standing robot".

Please visit the following link.

**broken link removed**

It will help to understand what Im talking about.

I would also like to know the areas in which I might encounter any difficulties while designing the robot. A brief description of how to make it work will also be helpful. I came across a bot by the name nBOT that is similar to Botka. And the designer of nBOT gave a vague and brief description of how it works on his website. The website in question is

www.geology.smu.edu/~dpa-www/robo/nbot/

Although I read through most of the site, I could only understand like 40% to 50% of it. It would be helpful if someone could fill in the gap in simple language or lend their own insight as to how such a thing might be built.

Thank you

 

[Hank Fletcher]

I can't remember off-hand, but I know I've seen gyro-chips for sale on the web (maybe Acroname, but I'm sure you could find them at various other locations). Use the gyro to determine the orientation of the robot (i.e. how much it's leaning over), and to power the motors proportionally. The proportional power adjustment can be heard from the motors suddenly moving quite quickly when the user knocks the robot over quickly in the video.

The trick seems to be to have the wheels constantly powered in the direction the robot is falling. Another way to think about this is to compare the robot to a drag racing car. As a drag racer accelerates, the body of the car "pops-a-wheelie," moving upwards and back over the axis of the spinning back wheels. The only difference with the robot is that when it's knocked over, it continues to accelerate past the point of perpendicular. At that point, the robot quickly changes the direction of the wheels to compensate in the other direction.

The effect is a robot that goes spastic when it's knocked over (on four wheels), but settles down once the feedback control realizes the perpendicular orientation. An important aspect of the design of this robot is to ensure that the motors can provide enough torque and acceleration to rotate the entire body of the robot around the powered wheels should the robot become parallel to the ground.

 

[Hank Fletcher]

Here's a gyro sensor along the lines I mentioned earlier:
https://www.acroname.com/robotics/parts/R40-PG2033.html

I also saw that Sparkfun had a dual-axis sensor for about the same price. With dual-axis, you could even make your robot a unicycle type! Come to think of it, if you want to get up-close-and-personal with the control process of your robot, you might try your hand at riding a unicycle yourself (warning: it's hard, especially on your balls). Either that, or buy a Segue.

 

[desijays]

Using a gyro would be an option, but I believe the self balancing act can be achieved by using a simple distance measuring sensor as well.

The following link will clarify what I am talking about...

https://www.electro-tech-online.com/threads/nifty-balancing-robot.34122/

I am not well aware of the advantage of using a gyro as opposed to using a 'distance measuring sensor' to achieve the self balancing act. If such knowledge is trivial please pardon my ignorance.

I do know one thing with a fair amount of certainty. And that is, whether a gyro is used or a 'distance measuring sensor' is used, the program logic that eventually drives the two motors to achieve upright stability will be almost similar. If a gyro is being used then the tilt and inclination of the 'self balancing contraption' is used as input to calculate the compensation, the motors need to produce.

Likewise, if a 'distance measuring sensor' is used then the distance from the ground will be used as input to calculate the compensation of the motors as in the case of the robot mentioned in the link above.

The challenge arises in trying to determine an exact algorithm that will measure the distance from the surface (if 'distance measuring sensor' is used) and control the motors accordingly. Needless to say, the algorithm must be pretty quick.

I was just wondering if such data is acquired only by trial and error or is there some mathematical formula that can be used to plug in the distance as input (obtained from 'distance measuring sensor') and obtain as output the speed the motors must possess to avoid toppling over?

I hope I haven't crammed too much into one single post.

 

[Pommie]

You should read up on PID feedback. Here is a **broken link removed**. Just skip the advert.

Mike.

 

[Hank Fletcher]

Do what Pommie suggests. What you can read about PID, I should add, can be "too much information," if you know what I mean. By the time you have this all figured out, you'll be amazed at how simple it all seems then. You might try developing a flow chart to help you organize your thoughts about what your robot will be doing at any given time, and how it will correct for error.

In your last post, you've neglected a detail that I no doubt expect is still important to you. If, for instance, your robot is remote controlled, you'll want to make sure that your control takes into account not just the immediate status of the robot and the necessary compensation for error, but also how to factor whatever the person remotely controlling the robot is trying to effect as the desirable action e.g. the robot is rolled along a path and hits an object, and it starts to fall so it begins to compensate, and at the same time the user sends a message directing the robot in another direction. What should happen?

By the way, the optical sensor robot seems to be using one of the Sharp IR sensors. You should know that these sensors only read at about 20Hz. Also, their output is non-linear, which could complicate things when calculating around the axis of the robot. And you'd need two optical sensors to do the job of one gyro sensor if you wanted your robot to balance on either set of wheels as in the video you've posted. Given the marginally greater expense but much greater precision and ease of use of the gyro sensor, I highly recommend you take that path instead. The Sharp sensors are great for what they are, but the gyro sensors are specifically designed for this type of purpose, albeit balancing R/C helicopters.

 

[desijays]

You should read up on PID feedback. Here is a **broken link removed**. Just skip the advert.

Mike.

Thanks for the link. The article helps to establish a different line of thought to designing the control system for the upright bot.

 

[desijays]

In your last post, you've neglected a detail that I no doubt expect is still important to you. If, for instance, your robot is remote controlled, you'll want to make sure that your control takes into account not just the immediate status of the robot and the necessary compensation for error, but also how to factor whatever the person remotely controlling the robot is trying to effect as the desirable action e.g. the robot is rolled along a path and hits an object, and it starts to fall so it begins to compensate, and at the same time the user sends a message directing the robot in another direction. What should happen?

Im not sure about any particular method to use to solve such an issue. But an obvious solution would be to use priorities. Lets take your own example. If the robot is just trying to recover from a fall and at that precise moment the user sends a command directing it to move in some other direction then we can set priorities to the robot so that it temporarily ignores the command of the user until it is stabilized. I have a hunch this could work but it could piss the user off. He/She could be left wondering "This robot never listens to me".

By the way, the optical sensor robot seems to be using one of the Sharp IR sensors. You should know that these sensors only read at about 20Hz. Also, their output is non-linear, which could complicate things when calculating around the axis of the robot. And you'd need two optical sensors to do the job of one gyro sensor if you wanted your robot to balance on either set of wheels as in the video you've posted. Given the marginally greater expense but much greater precision and ease of use of the gyro sensor, I highly recommend you take that path instead. The Sharp sensors are great for what they are, but the gyro sensors are specifically designed for this type of purpose, albeit balancing R/C helicopters.

The problem with gyro's though, I believe, is that, they are sensitive to a lot of things and are susceptible to the infamous drift error. Rest assured all of those issues can be solved but at the expense of increased complexity. Im sure the IR sensors have similar issues, but solving them isn't so complicated.
But none the less, you have a point. I'll look into it.

 

[Hank Fletcher]

Seems like you're all set to make this project happen. As I said, I think you'll find working out the various issues actually quite trivial in retrospect (that is, after you've finished the project), and even to be enjoyable problems to resolve during the design process. Best of luck to you!

p.s.: I think I can speak for forum users when I say we're always interested in the final product, and even the process, of individual projects. Feel most welcome to post your progress!

 

[desijays]

I would like to think that this is just the beginning and Im sure of making this thing work. Maybe Im kidding myself when I say I'll do it without realizing the difficulties involved. But thats why I think sometimes ignorance is bliss. I just hope to get far enough into the project so that at that point backing out becomes a worthless option. Besides I think its a lot of fun. Leads to better things !!

Ill post my progress. I need to. Cos Im sure I'll need some help along the way . Besides, Im sure a lot of folks can learn a thing or two as I have learnt from you all, from the sidelines all this while.

Thanks for the encouragement hank.