Shop OBEX P1 Docs P2 Docs Learn Events
Memsic and my humanoid balance issue... — Parallax Forums

Memsic and my humanoid balance issue...

moomoomoomoo Posts: 27
edited 2005-01-17 17:48 in BASIC Stamp
I have a robo-one style humanoid that I want to keep balance while walking and fighting. Currently, I have the memsic working so that he keeps his balance while standing at attention, and he can keep his balance while walking. BUT, I can't seem to get it smooth enough. I've dropped the resolution to .001 on the memsic input and slowed the speed of the servos, but it still seems "jerky" and he over corrects too much.

I've seen some·picture of a guy at the robo olympics that had a two wheeled robot similiar·to the segway transport but smaller.

http://robolympics.net/photos/2004-03/DSC08556.jpg

·I haven't seen it go but the robot can follow lines and run around balanced. How does he do the so smoothly? I saw some description somewhere and I can't find it. I believe he was using a memsic and bs2, I think. I had some more stuff on it somewhere.

I placed the memsic in the middle of his body and level ( at least level for him ).
Can someone come up with a simple program so it doesn't over compensate. I have got the memsic input number at 1500, which is the 1500 center of servos, and the input number goes back and forth·from there. Falling forward would be·input higher than 1500 and backwards lower than 1500. I'm
serout to a servo controller.

Since bs2sx doesn't support interupts, how can I do this in real time while he is walking. The only way I·have been·doing this is to put the subroutine 'balance' in the walk sequence a whole bunch of times.

·

Comments

  • allanlane5allanlane5 Posts: 3,815
    edited 2005-01-13 18:24
    Hmm. Try a Ubicom SX28? 50 MIPS, and the new SX/B 'Basic' macro assembly language has great possibilities.
  • trendtrend Posts: 112
    edited 2005-01-13 19:17
    Wow.. You might be able to get by with a bs2 with just balancing itself to move (I don't see a viable way to do this.. but I am more a less a newbie so their might be a great way [noparse]:)[/noparse])· But on the fighting while moving/balancing.. I would really think that you would need an uC with interupts.

    Basicaly I am just replying to so I can subscribe to this thread [noparse]:)[/noparse]


    Hope you figure this out

    Lee
  • moomoomoomoo Posts: 27
    edited 2005-01-13 19:39
    I just looked that up and I didn't know about the contest or I would have bought this sooner. But then I'm terrible at programming. I can build humanoids, but I can't program 'em.
    That's the reason I have stuck with basic because it's easier (notice I didn't say easy). I don't think I can get albert2 ready in time for Feb.28 deadline if I tried. But I guess I could get the sx28 anyway seeing as it supports interrupts but it doesn't look like it has anything in the way of memory or program space?
  • steve_bsteve_b Posts: 1,563
    edited 2005-01-13 20:26
    If you have access to a good newstand...go pick up a copy of this months Nutz & Voltz.· They go through an explanation of PID controller systems.

    Basically, PID's (Proportional, Integrated, Derivative) is a way to 'smooth' out processes.

    ie: When you set your thermostat to 60deg.· If you let things run automatically with no PID type processes...then, as soon as the temp drops below 60deg the furnace comes on....then when the temp goes about 60deg the furnace turns off.·

    Now, heating and cooling a room isn't all that instantaneous, but you can bet that your thermostat will be clicking every 10-15 minutes or so.

    So, the newer thermostats have a PID interface so you don't get this rapid on/off succession.·

    I won't go in to too much of an explanation since it'll take up too much room.· If you can go find the magazine, then do it!· (it's a good mag for lots of things).

    And, it WILL be somewhat code intensive....well, there are easy ways to do it and harder ways!·

    At work we control servo's on a radar....and when we tell it to go to a certain elevation position this how it breaks it down.· If the current angle is more than 10deg different then it moves at 10T-units (T-units are just an internal unit to this particular machine...but it's all relative)....now when the current angle gets to within 5deg the T-units decrease to 6....then within 3deg they drop to 4 and when you are within 1-2deg the T-units are at 1 or 2 themselves.· So, there is this big acceleration/error slope that the computer uses to tell the servo how to get to where we want it without it 'overshooting' it's target.· Now, this isn't a perfect system, but without it, when we gave an angle command the antenna would move at max speed to the angle and would then overshoot, so now it reverses direction until it gets to the angle and then reverses direction again as it overshoots.

    It's like parking your car by holding the gas all the way down and just shifting from forward to reverse....



    Anyhow, I said I wouldn't get too descriptive yet I ramble on! haha

    Google it too...I'm sure some people have come up with some simplified code that you could get an idea from!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve
    http://members.rogers.com/steve.brady
    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • Jon WilliamsJon Williams Posts: 6,491
    edited 2005-01-13 23:13
    allanlane5 said...
    Hmm. Try a Ubicom SX28? 50 MIPS, and the new SX/B 'Basic' macro assembly language has great possibilities.
    SX/B is an inline compiler -- not a macro language.· To Allan's point, it's easy to use and lets one exploit the processing speed of the SX.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Jon Williams
    Applications Engineer, Parallax
    Dallas, TX· USA
  • moomoomoomoo Posts: 27
    edited 2005-01-14 00:46
    Thanks Steve_b!

    I think I see what your saying. So just decrease the speed of the servo in increments as it approaches the desired point.

    I'm going to try that right now!

    Thanks!
  • steve_bsteve_b Posts: 1,563
    edited 2005-01-14 01:02
    I'm not entirely sure how you might do this in a fairly easy way.



    But if you take the pulse value you use for moving your stepper and you need to come up with a multiplier to use in a slope calculation.

    I can sort of think of it in my head, but am having translation issues with getting it in to understandable english to understand! haha

    Anyhow

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve
    http://members.rogers.com/steve.brady
    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • LarryLarry Posts: 212
    edited 2005-01-14 01:40
    For an insight into smooth balance control, start reserching PID - Proportional·Integral Derivative.· It's a big step beyond static balance techniques.

    Balance in a dynamic environmant depends on how far off the desired attirude the robot is, how fast it is moving and in what direction, and how well the current algorythms are addressing the problem. PID handles all these issues.

    Larry





    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • Jim McCorisonJim McCorison Posts: 359
    edited 2005-01-14 02:52
    Larry said...
    Balance in a dynamic environmant depends on how far off the desired attirude the robot is, how fast it is moving and in what direction, and how well the current algorythms are addressing the problem.

    Basically how humans react to off balance situations. If we are far off balance we move more quickly to correct the problem, slowing as we approach what we perceive to be centered. But in normal activities like standing, our flat and level walking, or corrections are slow and slight.

    Now the next step, how do we make a stamp self aware. smile.gif

    Jim
  • moomoomoomoo Posts: 27
    edited 2005-01-14 03:01
    Hey Steve, I'm using standard hobby servos, 21 'em. And I tried the lowest speed it has and it is still not what I'm looking for, but it was worth a try.

    Now....., PID what?
    *scratchin' my head*
    I'll have to do some research on this and see what you's talkin' 'bout thar.
  • steve_bsteve_b Posts: 1,563
    edited 2005-01-14 03:21
    Do a google on PID theory.
    It WOULD sort out your problem except for the fact that you probably want to do it in software, which means you need some good bits of coding going on.

    How are you controlling all the servo's?· From some sort of MUX's?· Obviously not from the same stamp.
    Anyhow, you need to create some slopes.

    Graph X vs Y where X is time and Y is acceleration.....you want a nice curve.· What you have now is basically a Very sharp increase...you need to soften that up and let things happen gradually....

    But, I'm guessing that your movements are small enough that the stamp would need some very tight code to be able to see where it is and where it has to be and adjust on the fly.·
    Maybe the SX/B type chips might help, but you'll definately have to keep things tight otherwise.
    Try working in steps....can you ramp the speed of your servo's?· I remember some code being passed around on the yahoo site, maybe do a search in the archives.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve
    http://members.rogers.com/steve.brady
    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • steve_bsteve_b Posts: 1,563
    edited 2005-01-14 03:31
    Here's a quick site for you on PID interfacing....

    http://www.seattlerobotics.org/encoder/200205/PIDmc.html

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve
    http://members.rogers.com/steve.brady
    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • edited 2005-01-14 04:02
    There are also some BASIC Stamp PID coding lessons in the Industrial Control text, available for free download from www.parallax.com -> Downloads -> Stamps in Class Tutorials.

    The P (proportional) in PID provides adjustment proportional to the measured error. The measurement error is how far off you are from where you want to be. I (integral) and D (derivative) also make corrections based on error. I is a summation of the errors over time, like a moving average. It can smooth out jumpy motions. The D is derivative, and it's a measure of the rate of change. It's useful because it can react more quickly than proportional if your bot starts leaning too far because it detects the rate of change in your bot's lean. In a typical PID loop, each of the calculations has a certain influence on the bot's motion. That is, each of the controls, P, I, and D, make a certain contribution to the servo control. PID has a good chance of correcting your bot's jitters, but it takes a lot of testing and tuning.

    One of the problems you are up against is the fact that acceleration into movement causes a change in the tilt measurement. Because the tilt measurement now reflects an acceleration component, it is no longer correct. Imagine if you used partially filled soda bottle in the passenger seat to determine whether you are driving uphill or downhill. So long as your speed is constant, if the soda in the bottle is level, so is your car. But, if you speed up or slow down, you get false readings because the soda sloshes around in the bottle. While the accelerometer you are working with uses heated nitrogen gas instead of soda, the principle is still the same. It measures the temperature profile of the nitrogen. When you are holding it still and just tilting it, the cooler nitrogen gas sloshes downhill while the warmer nitrogen gas rises, and a temperature sensor array and some other circuitry converts the temperature measurements to pulses that correspond to tilt. If you move it, the acceleration into the motion causes a similar sloshing of the nitrogen gas, so the tilt measurement is no longer correct.

    Of the three, the I, in particular, might be helpful in evening out the slosh factor since it gives you a moving average of the measurements.

    Post Edited (Andy Lindsay) : 1/14/2005 6:23:09 PM GMT
  • moomoomoomoo Posts: 27
    edited 2005-01-14 18:50
    Mr. Lindsay

    That was a perfect "hold my hand" explanation, now PID makes a little more since to me, thank you.

    I Googled PID and came up with all sorts of stuff including software algorithms, industial controllers, and formulas for all sorts of commercial problems, but it all came down to the formula part....simple actually. Now it is a matter of implementing it into my program......

    OK...

    I have been thinking about it after your post, Andy, and the only thing I can do right now, I guess, is get a microcontroller with interupt capability and try some PID formulas.
    I'm still going to be using standard hobby servos as my motor selection.

    Maybe I'm getting in over my head with a humanoid, but I love the challenge. After seeing the japanese with their little humanoids in the Robo-one, I was hooked. So the last two years I've come up with two humanoids designs that are, I think, can fight among the best of them. And with a 'balance system' , everything else will be fairly easy; walking, stair climbing, and karate kicks to name a few.

    So I'll be back for more help once I get another microcontroller.

    Thank you, everyone for your help for now.
  • steve_bsteve_b Posts: 1,563
    edited 2005-01-14 21:04
    Thanks Andy!· English is supposed to be my first language, but dang nabbit if I could put the words together to explain PID without getting TOO abbreviated or wordy!

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    ·

    Steve
    http://members.rogers.com/steve.brady
    "Inside each and every one of us is our one, true authentic swing. Something we was born with. Something that's ours and ours alone. Something that can't be learned... something that's got to be remembered."
  • edited 2005-01-14 22:06
    moomoo said...
    I have been thinking about it after your post, Andy, and the only thing I can do right now, I guess, is get a microcontroller with interupt capability and try some PID formulas.
    I'm still going to be using standard hobby servos as my motor selection.
    You won't need a microcontroller with interrupts to get started on PID with hobby servos.· The BASIC Stamp·2 will do just fine.· Try the PID resource I cited earlier (repeated in the quote below):
    Andy Lindsay said...
    There are also some BASIC Stamp PID coding lessons in the Industrial Control text, available for free download from www.parallax.com -> Downloads -> Stamps in Class Tutorials.
    The Industrial Control text features hands-on PID lessons with a resistor heater in a film canestar.· True, it's very low speed, but after you get familiar with that, just take out the pauses and start applying it to your servos with the BASIC Stamp.· The coding techniques are the same, just running at a faster refresh rate.
  • moomoomoomoo Posts: 27
    edited 2005-01-15 19:15
    Andy,

    I read the PID portion of the handbook you mentioned and I'm still a little lost on how I can apply this to what I have.I attached a copy of my code that keeps him balanced while at attention (standing straight up) and the walk while balancing program.·In the attention program, when I try to push him backwards, his body bends forward to compensate for x-axis·and he moves his hips side to side for y-axis. When I pick him up and place him on unlevel surface he adjust everything pretty quick to keep from falling over.

    Now, that's all fine and dandy until I try to get him to walk which·is a different story. I tried to stick the balance subroutine in the walk sequence. This doesn't help much in that he moves a sequence then checks balance, moves a sequence then checks balance, etc. I would like the balance to be the dominate part of the of the walk sequence so that balance is in the forfront and everything else is in the background.


    Would it help if I put· balance as the main and the walk as the subroutine?

    How can I use the PID formula for this?

    Maybe I need to read again.

    I need help out of this rut, ...not me but albert.
  • LarryLarry Posts: 212
    edited 2005-01-15 19:42
    I think the balance routine needs to be on top. Think of it this way- with a balancing (wheeled ) robot, forward or backward motion is achieved by simply providing a lean offset into the direction of intended motion. As the PID tries to compensate, the robot moves. The PID routine is doing the work.

    With a walking robot, it basically the same. For a small correction, the robot can lean, but larger corrections are going to involve a step in the direction the robot is falling. PID will determine the size and direction of the step.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
  • edited 2005-01-16 04:11
    I take it that your bot goes through too much of the sequence, then jerks into an adjustment because it just realized it's tilting quite a bit more than it was at the beginning of the sequence. You can fix this by reorganizing your program a bit. I attached an example program that demonstrates part of the left_step routine. It calls the balance routine the instant before it needs to make the balance adjustment. Hopefully, that will remove the abrupt over adjustments from the walking.

    In a sense, you are already successfully implementing the P = proportional part of PID with the balancing program. Although the program skips the various coding formalities, the program's hip and bend servo outputs are definitely proportional to the tilt measurements.

    Sunday, 1:20 PM Pacific Standard time: PartOfAStep.bsx had some bugs.· I deleted it and replaced it with PartOfAStepCorrected.bsx

    One other thing.· For each servo that is updated, make sure your program is instructing the servo controller to ramp gradually from the previous duration to the new duration.· Using ramping will be crucial to smoothing out your bot's walking.

    Post Edited (Andy Lindsay (Parallax)) : 1/16/2005 10:13:31 PM GMT
  • moomoomoomoo Posts: 27
    edited 2005-01-16 23:05
    Ya know Andy, I really appreciate you going through the trouble to help rearrange my program because it really helps me to see and learn it a little different and definitely alot easier!

    I plugged in your code and there are only two problems ( ones you wouldn't have known unless I told you). First, for some reason the pololu servo controller hates variables placed into the serout command and I don't know why. The servos go all over the place and eventually it's going to break my servos! I've talk to Jan @ Pololu about this many times, and he doesn't seem to understand what I'm talking about. So I have ordered another servo controller from Picobytes which is a 20 channel controller. So the 'servo' in the serout command confused the servo controller. I've been dealing with this for a year. So that's the reason for the all the serout commands.

    Secondly, in the 'servos data' the "0" at the end of the statement is actually the servo channel 0 for the controller. The channel labels are 0-15 for 16 servo channels. So it would have sent a blank to the controller and really confused it.

    But all is good, because the picopic controller doesn't do this. So I'm going to put this code in the (stronger, better, faster) humaniod and it should work fine.

    The way you wrote this code takes up alot less space than all the serout commands that I had in there! Now I can stuff some more moves into him.

    With the picopic controller the '18' in the duration command is actually now going to be '1500' , which is a word variable. How is that going to effect the data statement? Will it effect it at all?

    Oh yah, also how many numbers can I put in the data statement?
  • edited 2005-01-17 00:50
    moomoo,

    I hope, at some point, you will give the sixteen channel·Parallax Servo Controller a try. It's very reasonably priced, and has some really good features for humanoid servo control.· You can cascade two along a single I/O pin for 32 channels.· It's also very robust in terms of features and has some very reliable serial communication routines.· Definitely good for talking with BASIC Stamps.

    There are some more coding examples you might find useful in Advanced Robotics with the Toddler, which is available for free download with all the other educational texts.

    Post Edited (Andy Lindsay (Parallax)) : 1/17/2005 12:56:29 AM GMT
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2005-01-17 14:34
    Did I miss something?· Has anyone read the Memsic documentation?

    There are two ways to use the device.· First is 'flat on its back' and the second is 'the flat is perpendicular to the horizon'.

    Forgive the description, but I think you get the idea.

    The importance is that in the first position, only about 60 degrees from level can be read with any accuracy.· Of course you have an X and a Y direction, but no Z.· If you want full rotational measurment, you go to the second positioning and they use the so-called X and Y to measure a full 360 degrees in one plane.

    Thusly, it seems that the reason for inaccuracies may lie in assuming that you can get more out of the first position than is really possible.· It would seem that a fully fuctional walking robot would need at least three Memsic sensors in order to move freely throughout the real world.



    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    G. Herzog in Taiwan
  • moomoomoomoo Posts: 27
    edited 2005-01-17 17:48
    Andy,

    I did buy the parallax servo controller and I had some problems with it. First, the speed for the controller made the servo move very "grainy" (for lack of a better word) and also when the servo was moving, it would glitch when it moved through center of servo. The servos were brand new at the time, so there was nothing wrong with them. I talked to Stephen Swanson of parallax, then sent the board back for him to check (he requested) and he said that there was nothing wrong with it other than I couldn't move all 16 servos at the same time. I told how I had it hooked up and sent the code I was using and it all checked out. So I didn't want to go through the trouble again with it, so I got a refund. The reason I got the parallax servo controller was the way the parameters were written for it; having the position and speed in one command line was nice. Definitely better than pololu's command layout.

    Kramer,

    I have the memsic laying flat, which works perfect for the robot. Accuracy is not the problem I'm having; it's the ability for smoother servo reaction and the ability for the microcontroller to read the memsic on a constant basis so the servos can react to the changes in the input of the memsic and still do the rest of his functions and keep his balance also.
Sign In or Register to comment.