Self-erecting, self balancing 'bot

[Brooks]

My 2017 resolution is to stop veering off onto new interesting projects, and finish the ones I have already cooking.

The latest, and doggone-it-I'll-finish-it, is a self-erecting, self-balancing 'bot. Here's my self-created pre-prototype:

This gives me a very rough idea of how I want to lay it out. Here's the visualization from the fellow who's doing the metalwork for me:

I'm hoping to get the metalwork in a few weeks.

I'm currently working on software development for the MPU-6050 using a Teensy 3.2. The Teensy makes a great host processor. Once I get decent position info I'll integrate that with the steppers and see what's what.

The lower horizontal bay is for electronics: the teensy and the two stepper drivers. The two stepper motors themselves mount below the bottom, with the MPU mounted between them, in line with the motor axles.

The narrow vertical bay is for the battery. I want the center-of-mass as high as is reasonable to minimize balance "twitchy-ness".

The wider vertical bay is for two servos. The first will mount high on the frame. Its output will connect to an arm extending downward ending in the second servo. The second servo's output arm will extend back upward and end in a foot.

I'm hoping I can arrange for the two servos and arms to bring the 'bot upright. I also think it would be neat that the upper servo swings the lower servo to aid in balancing. I suspect that once in nominal balance I could keep it upright with just the servo...

Updates to follow...

[jwatte]

Interesting! I have two questions if you don't mind.

Why does higher center of mass leads to less twitchyness? It leads to higher rotational momentum and more torque needed. I don't see what is it with higher torque that leads to less twitch, but I bet there's some math that would explain that?

Also, I would assume that the best point for a balancing sensor would be at the top, where acceleration movement is most easily sensed (similar to how human balancing functions are in the ears) but you're putting the sensor inline with the axle? I'd love ot hear the explanation for that, too!

[tician]

If the center of mass is too close to the axis of rotation, then you can too easily end up with a thwack combat robot instead of an inverted pendulum balance robot. Moving the center of mass further away to increase the moment of inertia leads to slower, smoother movement of the pendulum for a given movement of the wheels.

[jwatte]

I see, so it's a function of resolution of movement of wheels versus rotational inertia. That makes sense!

[Brooks]

I believe Tician has the right of it regarding the positioning of the center of mass.

Regarding the positioning of the sensor at the level of the axle instead of up high, I want to measure the inclination of the 'bot as it rotates around the axles. If the sensor is higher, inclination changes become both a small change in inclination plus a large positional change. I'm not expressing this well, but I want the sensor to be rotating at the center of a circle rather than riding around the circumference. Does this make sense?

And I'm probably stating the obvious, but I need to have the mechanical assembly be as stiff as possible. I want to be doing calculations on, and making adjustments to, a static mass. Trying to stabilize an object whose center of mass is moving around would get old fast. This means that if I have servos as I described I can never un-power them or set them to zero torque. If they relax they'll "sway" with wheel movements - I'll have a bot that's really good at falling over!

[jwatte]

Well, math seems to say that the rotation for a point at the circumference is exactly the same as the rotation of a point at the center.
The thing that matters is the acceleration change -- at the center, that should theoretically not change at all, whereas at the circumference, acceleration should change with change in angular velocity.

Given that the older balancing robots only used acceleration sensors (before gyros were cheap) perhaps that's an outdated idea. It would certainly be nice to know that "down" can be absolutely measured at the center, rather than be affected by the angular velocity.

[Brooks]

Well, math seems to say that the rotation for a point at the circumference is exactly the same as the rotation of a point at the center.
The thing that matters is the acceleration change -- at the center, that should theoretically not change at all, whereas at the circumference, acceleration should change with change in angular velocity.

Given that the older balancing robots only used acceleration sensors (before gyros were cheap) perhaps that's an outdated idea. It would certainly be nice to know that "down" can be absolutely measured at the center, rather than be affected by the angular velocity.

Both of your points are intensely interesting! This whole area is one that's consuming me. Luckily, these seem to be issues that I can tackle as the hardware comes together. I've already purchased a length of pipe-insulation (to cushion topples!) for use during debugging.

Two of the areas I want to explore during debugging are:
* Integrating the aggregate movement of the wheels so that I don't necessarily try to keep the 'bot vertical, but rather keep the center of mass over the axles. I should be able to clip on a pair of vice-grips and have it be able to operate that way.
* Keep track of the aggregate uncommanded-by-an-external-controller movements of the wheels so it stays in one place.

[m3atsauc3]

Interesting point regarding the centre of mass. This discussion is interesting, generally it depends on how you look at it, e.g. from a physics vs control point of view. A longer pendulum will take longer to fall, hence will be easier to control while your offset from vertical is small, but if you veer off too far (e.g. from an external disturbance) it will be heavier hence will need fast acceleration / better motors to correct it. Just like the classic broomstick on finger balancing! On the other hand, a short length will need more "twitchy" to control as already mentioned. Easy for a control system but harder for a human.
So at the end of the day I guess it depends on what you want! If the aim is for it to never veer too far off centre, then longer is better, but to be able to compensate for large offsets you may need to make it shorter, or at least have powerful motors.
The Matlab website has a great intro on turning the theory into a system of equations.

Good luck in finishing the project! I know what it's like to be pulled into different directions with personal projects, but at least you have a well-defined goal!

[Brooks]

I think traction becomes the biggest issue once the center of mass gets too far away from the axles. The further away from upright the more of the mass of the 'bot is in free-fall (contributing nothing to traction). My plan is to keep the 'bot as upright as possible, shoot for a fairly high maximum ground speed, and plan to use smooth [de]accelerations. Oh, and lots of padding during debugging!

The metal-work is underway and I'm working on the MPU software. I'm trying to decide if I should plan on small cooling fan(s) for the stepper drivers, and if I should make a motherboard for the Teensy (3.2), stepper drivers, and fans.

[jwatte]

It's almost always better to up-size your stepper drivers one step rather than try to manage slim margins with fans.
If the drivers only get "still touchable" hot, then you probably don't need to do anything.