Bing 3
by DerekZahn
Sat Feb 17, 2007 10:10 pm
I'm continuing on with sensor processing for now, and probably will for another week. One of the things I know I want is an estimate of the location of the center of mass, especially in relation to Bing's feet. It doesn't have to be hugely accurate but the closer to reality the better.
To figure this out, I need an internal model of the robot, which means storing the geometry and doing transformations based on joint angles. Then, each major part of Bing has a weight assigned to it and I can sum up the weights and locations to find the center of mass.
To help me debug this, and maybe to help with visualization tasks (and just because it's cool), I decided to make a display window that takes the joint positions and the tilt readings I'd been posting about recently and display a current view of Bing in real time.
bigger: http://happyrobots.com/bing3b3.jpg
If I poke Bing in the chest I can see its avatar rock backward in my window, and I can watch it track from an initial poisition to the neutral pose on startup. The joint movements caused by sliders in my UI also track properly, so the model is accurate.
Computing the center of mass from here should not be too hard.
Edited to add: If anybody wants to try something similar, I can recommend this web site:
http://www.directtutorial.com/DX9/Direct3D/dx9-B.php
I worked through the tutorial as far as lesson 9, adapting it to my needs as I went along.
To figure this out, I need an internal model of the robot, which means storing the geometry and doing transformations based on joint angles. Then, each major part of Bing has a weight assigned to it and I can sum up the weights and locations to find the center of mass.
To help me debug this, and maybe to help with visualization tasks (and just because it's cool), I decided to make a display window that takes the joint positions and the tilt readings I'd been posting about recently and display a current view of Bing in real time.
bigger: http://happyrobots.com/bing3b3.jpg
If I poke Bing in the chest I can see its avatar rock backward in my window, and I can watch it track from an initial poisition to the neutral pose on startup. The joint movements caused by sliders in my UI also track properly, so the model is accurate.
Computing the center of mass from here should not be too hard.
Edited to add: If anybody wants to try something similar, I can recommend this web site:
http://www.directtutorial.com/DX9/Direct3D/dx9-B.php
I worked through the tutorial as far as lesson 9, adapting it to my needs as I went along.
by DerekZahn
Sun Feb 18, 2007 8:41 pm
Thanks Jon! We can all inspire each other.
There's so much fun stuff to do with these sensors that I'm starting to wonder whether I'll ever get around to making Bing actually do anything!
Here's a view of the current UI application.
bigger: http://happyrobots.com/bing3c3.png
The graphs are just whatever I feel like showing at the moment and aren't particularly important. In this screenshot I'm only showing 5 of the 8 possible graphs. Anybody paying close attention will notice that I eliminated the camera view and replaced it with the 3D model view. Unfortunately, the driver for the USB webcam had an annoying habit of grabbing the whole machine for a second at a time now and then which wrecks my timings, so I had to get rid of it. I'm not sure how useful it really was anyway.
I finally got my data stream code pretty much finished. Consider the following graph from that screenshot, showing tilt as i manually rock Bing back and forth:
The blue line is the output of the tilt computation and the green line basically right on top of it is a weighted average of tilt values over the previous 50 milliseconds. The red line is the derivative of the tilt reading, and the black line is a weighted average of that derivative over the previous 100 ms. Hopefully I have the flexibility to get whatever flavor of raw or smoothed readings I will want later.
Here's one other interesting piece of the UI:
The blue '+' represents "robot zero", which is the origin of the robot-centric coordinate system. The green outlines are the projections of the feet (derived from the 3D model). The red 'X' is the location of the center of mass (here centered just about perfectly since Bing is standing in its neutral pose). The blue dots in the feet are derived from the pressure readings. The location of the dot represents the "center of pressure" on the foot, and the size of the dot represents the sum of the pressure readings. A perfectly balanced Bing would have both dots in the center of the foot and the dots would be the same size.
I have lots of little bugs to fix and so on which isn't the most exciting stuff to do, but sometimes you have to just put the nose to the grindstone to get the rewards. It's getting close to being what I was imagining.
There's so much fun stuff to do with these sensors that I'm starting to wonder whether I'll ever get around to making Bing actually do anything!
Here's a view of the current UI application.
bigger: http://happyrobots.com/bing3c3.png
The graphs are just whatever I feel like showing at the moment and aren't particularly important. In this screenshot I'm only showing 5 of the 8 possible graphs. Anybody paying close attention will notice that I eliminated the camera view and replaced it with the 3D model view. Unfortunately, the driver for the USB webcam had an annoying habit of grabbing the whole machine for a second at a time now and then which wrecks my timings, so I had to get rid of it. I'm not sure how useful it really was anyway.
I finally got my data stream code pretty much finished. Consider the following graph from that screenshot, showing tilt as i manually rock Bing back and forth:
The blue line is the output of the tilt computation and the green line basically right on top of it is a weighted average of tilt values over the previous 50 milliseconds. The red line is the derivative of the tilt reading, and the black line is a weighted average of that derivative over the previous 100 ms. Hopefully I have the flexibility to get whatever flavor of raw or smoothed readings I will want later.
Here's one other interesting piece of the UI:
The blue '+' represents "robot zero", which is the origin of the robot-centric coordinate system. The green outlines are the projections of the feet (derived from the 3D model). The red 'X' is the location of the center of mass (here centered just about perfectly since Bing is standing in its neutral pose). The blue dots in the feet are derived from the pressure readings. The location of the dot represents the "center of pressure" on the foot, and the size of the dot represents the sum of the pressure readings. A perfectly balanced Bing would have both dots in the center of the foot and the dots would be the same size.
I have lots of little bugs to fix and so on which isn't the most exciting stuff to do, but sometimes you have to just put the nose to the grindstone to get the rewards. It's getting close to being what I was imagining.
by DerekZahn
Mon Feb 19, 2007 5:07 pm
A little bit of explanation about that final diagram and why it might be interesting:
Imagine an outline that surrounds both of the feet (that is, includes both of the green outlines in the picture). If both feet are on the ground and the robot is not moving, the robot will fall over if the red X is outside that outline, and it will not fall over if it is inside the outline.
In my simple testing, this seems to be working. If I tilt the robot forward, it falls over at exactly the point where the red X goes past the front of the projected foot. Sideways, it falls over a little bit early. The reason for this is that tipping it sideways puts very large stresses all along the leg, especially at the hip (the current in the hip servo goes crazy). Because of this stress, the leg bends by a substantial amount but my 3D model does not know that, so it becomes inaccurate by the amount of the bending (in this case it is a little more than 1 cm).
I don't think it's worthwhile to fight to make the robot more rigid. Having some compliance is useful in damping down oscillations, and it would be very hard to make it perfectly rigid and yet lightweight anyway. Either I can attempt at some point to guess at the bending based on servo current values or I can just live with the fact that the 3D model is only approximate. I'll start with that latter approach and not futz with the other stuff unless the inaccuracy makes it impossible for Bing to move effectively.
Imagine an outline that surrounds both of the feet (that is, includes both of the green outlines in the picture). If both feet are on the ground and the robot is not moving, the robot will fall over if the red X is outside that outline, and it will not fall over if it is inside the outline.
In my simple testing, this seems to be working. If I tilt the robot forward, it falls over at exactly the point where the red X goes past the front of the projected foot. Sideways, it falls over a little bit early. The reason for this is that tipping it sideways puts very large stresses all along the leg, especially at the hip (the current in the hip servo goes crazy). Because of this stress, the leg bends by a substantial amount but my 3D model does not know that, so it becomes inaccurate by the amount of the bending (in this case it is a little more than 1 cm).
I don't think it's worthwhile to fight to make the robot more rigid. Having some compliance is useful in damping down oscillations, and it would be very hard to make it perfectly rigid and yet lightweight anyway. Either I can attempt at some point to guess at the bending based on servo current values or I can just live with the fact that the 3D model is only approximate. I'll start with that latter approach and not futz with the other stuff unless the inaccuracy makes it impossible for Bing to move effectively.
by DerekZahn
Fri Feb 23, 2007 3:55 am
I think that coming up with some way to use the sensor data to improve balance while standing and walking is going to be the key to making Bing successful in the Robo-One arena. IF I can figure out how!
The first attempt was not very pretty. I thought it might be rather straightforward, but I was unable to make a simple algorithm using the gyro and tilt that would make Bing react in a very useful way to being poked in the chest. If I dialed down the parameters enough to avoid oscillation, it didn't do much to improve the stability.
I made a video, the quality of which is not great but I'll get better at making them as time goes by.
<object width="425" height="350">
<param name="movie" value="http://www.youtube.com/v/I4R0mav6twY"></param>
<param name="wmode" value="transparent"></param>
<embed src="http://www.youtube.com/v/OF1gP5AVjk8" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>
Maybe I'll call that "walking" and declare victory!
I'm going to embark on a more intense study of why this is failing and hopefully in a week or so I'll have another report.
The first attempt was not very pretty. I thought it might be rather straightforward, but I was unable to make a simple algorithm using the gyro and tilt that would make Bing react in a very useful way to being poked in the chest. If I dialed down the parameters enough to avoid oscillation, it didn't do much to improve the stability.
I made a video, the quality of which is not great but I'll get better at making them as time goes by.
<object width="425" height="350">
<param name="movie" value="http://www.youtube.com/v/I4R0mav6twY"></param>
<param name="wmode" value="transparent"></param>
<embed src="http://www.youtube.com/v/OF1gP5AVjk8" type="application/x-shockwave-flash" wmode="transparent" width="425" height="350"></embed></object>
Maybe I'll call that "walking" and declare victory!
I'm going to embark on a more intense study of why this is failing and hopefully in a week or so I'll have another report.
by DerekZahn
Sat Feb 24, 2007 8:41 pm
To help me think about the things involved in this balance problem, I thought it might be fun to see if a computer simulation could be of use.
So I went and grabbed the code for the Open Dynamics Engine http://www.ode.org
This is a little physics simulation package. I put together a simplified but more or less accurate model of Bing focusing only on one fwd/back ankle joint, and I can write little bits of code to try different control strategies.
Here's a snapshot from a test of a (very unsuccessful) balancing attempt. The simulation puts an impulse into the model (simulating the poke in the chest). In this picture, the algorithm overcompensates and Bing is in the process of violently falling over.
bigger: http://happyrobots.com/bing3f3.jpg
I am not sure how helpful this is going to be -- I am hoping to use it to get ideas for strategies, but I don't think the simulation is accurate enough to just transfer the code directly.
I need to make a couple things more realistic -- in particular, time delays for sensor readings / motor actuations, and a more realistic model of the servo in the ankle.
It probably won't be of much use, but it's been interesting to play with so far.
So I went and grabbed the code for the Open Dynamics Engine http://www.ode.org
This is a little physics simulation package. I put together a simplified but more or less accurate model of Bing focusing only on one fwd/back ankle joint, and I can write little bits of code to try different control strategies.
Here's a snapshot from a test of a (very unsuccessful) balancing attempt. The simulation puts an impulse into the model (simulating the poke in the chest). In this picture, the algorithm overcompensates and Bing is in the process of violently falling over.
bigger: http://happyrobots.com/bing3f3.jpg
I am not sure how helpful this is going to be -- I am hoping to use it to get ideas for strategies, but I don't think the simulation is accurate enough to just transfer the code directly.
I need to make a couple things more realistic -- in particular, time delays for sensor readings / motor actuations, and a more realistic model of the servo in the ankle.
It probably won't be of much use, but it's been interesting to play with so far.
by DerekZahn
Sun Feb 25, 2007 9:12 pm
This ankle system is fairly complicated! To help me get a feel for control strategies, I decided to build a version of the simulation that I could control manually.
bigger: http://happyrobots.com/bing3g3.jpg
Because it's sort of fun, I decided to let other people download it and try it (Windows only, sorry). Here's a zip file with the program inside:
http://happyrobots.com/anklegame.zip
The black number in the display is in milliseconds of the simulation.
After 100 milliseconds, an impulse is delivered to the model. The idea is to use the ankle servo to minimize the worst tilt that occurs, and bring it to stability as quickly as possible.
To control the servo, put the mouse cursor inside either the "Counterclockwise" or "Clockwise" boxes. Doing so sets a desired servo angle. The magnitude of the angle corresponds to the distance from the center line. You can see the joint angle with the red display. The units are tenths of a degree, and the joint angle is graphed.
The Blue and Green display/graph values are the tilt (in hundredths of a degree) and gyro reading (in tenths of a degree per second).
The model has a delay built in for the sensor readings in the graph (set to 15 milliseconds) to simulate the time delay for sensors, hardware low pass filtering, and delivering the sensor data to the code. However, that delay does not really factor into the interactive game because the 3D display is always accurate real-time.
A delay is built in to the servo control. Servo commands (desired servo positions) do not take effect for 20 milliseconds. This is to simulate the transmission delay of Bing's serial protocol and also the time in between pulses sent to the servos (which will average 10 ms).
The servo model is not as realistic as I'd like -- it has a fixed operating speed of 3 radians per second (0.3-ish seconds for 60 degrees), a large torque limit, and no acceleration delay. I'm not sure the physics is accurate enough for me to bother with a more sophisticated model anyway.
A lot of the important dynamics seem to revolve around border issues such as when the foot breaks contact with the ground, exactly how "bouncy" the foot is, and so on.
Press the SPACE bar to pause the simulation.
It's interesting to play around with, and it's giving me some insight into the issues involved in trying to use these sensors in a closed loop way to do things like maintain balance.
bigger: http://happyrobots.com/bing3g3.jpg
Because it's sort of fun, I decided to let other people download it and try it (Windows only, sorry). Here's a zip file with the program inside:
http://happyrobots.com/anklegame.zip
The black number in the display is in milliseconds of the simulation.
After 100 milliseconds, an impulse is delivered to the model. The idea is to use the ankle servo to minimize the worst tilt that occurs, and bring it to stability as quickly as possible.
To control the servo, put the mouse cursor inside either the "Counterclockwise" or "Clockwise" boxes. Doing so sets a desired servo angle. The magnitude of the angle corresponds to the distance from the center line. You can see the joint angle with the red display. The units are tenths of a degree, and the joint angle is graphed.
The Blue and Green display/graph values are the tilt (in hundredths of a degree) and gyro reading (in tenths of a degree per second).
The model has a delay built in for the sensor readings in the graph (set to 15 milliseconds) to simulate the time delay for sensors, hardware low pass filtering, and delivering the sensor data to the code. However, that delay does not really factor into the interactive game because the 3D display is always accurate real-time.
A delay is built in to the servo control. Servo commands (desired servo positions) do not take effect for 20 milliseconds. This is to simulate the transmission delay of Bing's serial protocol and also the time in between pulses sent to the servos (which will average 10 ms).
The servo model is not as realistic as I'd like -- it has a fixed operating speed of 3 radians per second (0.3-ish seconds for 60 degrees), a large torque limit, and no acceleration delay. I'm not sure the physics is accurate enough for me to bother with a more sophisticated model anyway.
A lot of the important dynamics seem to revolve around border issues such as when the foot breaks contact with the ground, exactly how "bouncy" the foot is, and so on.
Press the SPACE bar to pause the simulation.
It's interesting to play around with, and it's giving me some insight into the issues involved in trying to use these sensors in a closed loop way to do things like maintain balance.
by JonHylands
Mon Feb 26, 2007 3:18 am
Derek,
What I found works best is if you wait for the first impulse motion to stop - where it stops after rocking back, but before it starts rocking forwards again - and you "flatten" the foot at that point, there is virtually no oscillation.
(bigger - http://www.bioloid.info/Bing-Test.PNG)
I don't know if this helps at all...
- Jon
What I found works best is if you wait for the first impulse motion to stop - where it stops after rocking back, but before it starts rocking forwards again - and you "flatten" the foot at that point, there is virtually no oscillation.
(bigger - http://www.bioloid.info/Bing-Test.PNG)
I don't know if this helps at all...
- Jon
Last edited by JonHylands on Mon Feb 26, 2007 4:41 pm, edited 1 time in total.
by DerekZahn
Mon Feb 26, 2007 3:42 am
Cool, so the strategy there is to "absorb" the perturbation then gradually straighten up again.
The opposite strategy involves turning hard the other way immediately to push the ankle joint past the center of mass and "catch" it (like balancing a pole). Then glide back down. The worst-case tilt is much better in this case though the whole thing takes a little longer and the gliding back down part is considerably more complicated.
Introspection and foolish-looking experimentation reveal that if I get poked in the chest I sometimes use the first strategy and sometimes the second (toes in the air). I'm not sure how I choose which to do.
Of course I also bend at the hips and my arms flail about and so forth, whichi should all be part of a real answer.
The opposite strategy involves turning hard the other way immediately to push the ankle joint past the center of mass and "catch" it (like balancing a pole). Then glide back down. The worst-case tilt is much better in this case though the whole thing takes a little longer and the gliding back down part is considerably more complicated.
Introspection and foolish-looking experimentation reveal that if I get poked in the chest I sometimes use the first strategy and sometimes the second (toes in the air). I'm not sure how I choose which to do.
Of course I also bend at the hips and my arms flail about and so forth, whichi should all be part of a real answer.
Modeling with Marilou Robotics Studio
by LR
Mon Feb 26, 2007 12:44 pm
Hi,
I'm very interesting in the ODE simulation you made. I've downloaded it and i will try it soon. I'm the founder of the Marilou Robotics Studio and i'm searching someone witch should be interested to try modeling these robot inside the Marilou simulator. You can create the entire robot, attach sensors like servo, motors , ir, us , laser and others ! I hope someone would be interested
Thank you
www.anykode.com
I'm very interesting in the ODE simulation you made. I've downloaded it and i will try it soon. I'm the founder of the Marilou Robotics Studio and i'm searching someone witch should be interested to try modeling these robot inside the Marilou simulator. You can create the entire robot, attach sensors like servo, motors , ir, us , laser and others ! I hope someone would be interested
Thank you
www.anykode.com
Last edited by LR on Wed Aug 13, 2008 6:37 pm, edited 1 time in total.
