Bing 3
by DerekZahn
Thu Jan 25, 2007 4:43 pm
Thanks for the kind words, your homebuilt bot looks awesome!
It's looking like we could get a nice turnout of bots for RoboGames though it always happens that some drop out near the end because of disasters or lack of sufficient progress. My only real goal is that I not be one of those!
I might sign up for the Demonstration event in addition to wrestling, it depends on whether I am likely to get enough capabilities to put together a 2 minute routine.
It's looking like we could get a nice turnout of bots for RoboGames though it always happens that some drop out near the end because of disasters or lack of sufficient progress. My only real goal is that I not be one of those!
I might sign up for the Demonstration event in addition to wrestling, it depends on whether I am likely to get enough capabilities to put together a 2 minute routine.
Do you know if there have been any significant changes to the rules for Robo-1 at the RoboGames? (Like there were for Robo-1 Japan)
by DerekZahn
Sat Feb 03, 2007 9:45 pm
Well, it was a bunch of work, but I built 10 circuit boards for current monitoring and surgically implanted them into various parts of Bing's anatomy. I also built a rather elaborate head but in the end I was not happy with it so I decided not to use it. I will use it as a prop of some kind in a demonstration. So Bing's head is actually going to just be a racketball, at least for now.
I'm pretty close to Bing being "finished"... by "finished" i mean that I have to get started on the software. I bet that by the end of the day tomorrow I'll be done. Still a rat's nest of wiring in the upper torso to deal with and then test everything to make sure I didn't do something really stupid.
bigger: http://happyrobots.com/bing3s2.jpg
I'm pretty close to Bing being "finished"... by "finished" i mean that I have to get started on the software. I bet that by the end of the day tomorrow I'll be done. Still a rat's nest of wiring in the upper torso to deal with and then test everything to make sure I didn't do something really stupid.
bigger: http://happyrobots.com/bing3s2.jpg
by JonHylands
Sat Feb 03, 2007 11:29 pm
Wow, very nice Derek!
I love the way you hid the wiring, it helps to not only make it look cool, but it also will keep the wires from snagging on anything, which is pretty important for these kinds of robots.
How do you plan on using the current monitoring information? The AX-12 servos I use all have current monitoring built in, but so far I have found it difficult to differentiate between the current the motor draws to move the servo versus the load presented by outside forces.
- Jon
I love the way you hid the wiring, it helps to not only make it look cool, but it also will keep the wires from snagging on anything, which is pretty important for these kinds of robots.
How do you plan on using the current monitoring information? The AX-12 servos I use all have current monitoring built in, but so far I have found it difficult to differentiate between the current the motor draws to move the servo versus the load presented by outside forces.
- Jon
by DerekZahn
Sun Feb 04, 2007 12:03 am
My main purpose at the moment is to use the information to help make sure I don't burn out servos. On the last version of Bing I lost a couple servos because the pose it was standing in put more stress on the servos than I was expecting and I basically just forgot about it while the servo overheated.
I have imagined other things, like estimating momentum changes based on integrating current use, watching current use to help figure out "natural" stances (perhaps even adjusting a stance automatically to do that), and helping detect interactions with the environment by looking for unusual current demands, but I don't have any plans to use those things right away. I was also wondering about having a "semi-rigid" mode for making poses where the servos hold their position unless the current demand gets above some threshold (which would occur when manually forcing a servo).
I have imagined other things, like estimating momentum changes based on integrating current use, watching current use to help figure out "natural" stances (perhaps even adjusting a stance automatically to do that), and helping detect interactions with the environment by looking for unusual current demands, but I don't have any plans to use those things right away. I was also wondering about having a "semi-rigid" mode for making poses where the servos hold their position unless the current demand gets above some threshold (which would occur when manually forcing a servo).
by DerekZahn
Sun Feb 04, 2007 3:20 am
The final assembly went more smoothly than I anticipated, and for now at least Bing 3 is mechanically and electrically complete. The next step is to move on to the software, which I have only thought about a little bit so far. I guess the first thing is to do some sort of calibration of the servos so I can address them more conveniently than just in pulse width microseconds, which won't work out too well when I have to replace a servo.
I had delayed the final foot assembly until the end for fear I would damage something while hammering the rest of Bing into place, but now the "shoes" are attached:
bigger: http://happyrobots.com/bing3t2.jpg
Final statistics:
Height: 33cm to the top of the shoulders, 40 cm to the top of his racketball head.
Weight: 2.9 kg
bigger: http://happyrobots.com/bing3u2.jpg
We'll see how long it takes until the first big repair job! Hopefully not too soon!
I hope the chronicle of this build process has been interesting or entertaining to some of you. I'm not sure how much I will post in this thread after this point... I may just leave the progress as a surprise for RoboGames... which begins in 132 days!
Thanks for all the kind comments and I hope to meet some of you at RG in June.
I had delayed the final foot assembly until the end for fear I would damage something while hammering the rest of Bing into place, but now the "shoes" are attached:
bigger: http://happyrobots.com/bing3t2.jpg
Final statistics:
Height: 33cm to the top of the shoulders, 40 cm to the top of his racketball head.
Weight: 2.9 kg
bigger: http://happyrobots.com/bing3u2.jpg
We'll see how long it takes until the first big repair job! Hopefully not too soon!
I hope the chronicle of this build process has been interesting or entertaining to some of you. I'm not sure how much I will post in this thread after this point... I may just leave the progress as a surprise for RoboGames... which begins in 132 days!
Thanks for all the kind comments and I hope to meet some of you at RG in June.
by DerekZahn
Sun Feb 04, 2007 4:15 am
For amusement, here's a family photo: Bing 2 and Bing 3.
bigger: http://happyrobots.com/bing3v2.jpg
Bing 2 was flawed and never really walked acceptably. I think I could have gotten him to walk more or less if I had stuck with it but I decided that building bots was so much fun that I'd start right in on the next version.
I never thought it would take a year and a half though!
bigger: http://happyrobots.com/bing3v2.jpg
Bing 2 was flawed and never really walked acceptably. I think I could have gotten him to walk more or less if I had stuck with it but I decided that building bots was so much fun that I'd start right in on the next version.
I never thought it would take a year and a half though!
by JonHylands
Sun Feb 04, 2007 2:29 pm
DerekZahn wrote:Those are just little pieces cut from sheet rubber. I'm not sure what adhesive to use, I'll start with some strong double-sided tape and if that proves insufficient I'll try some epoxy.
Derek,
The feet look great - how did you end up fastening the pieces, sensors, and rubber discs together?
- Jon
by DerekZahn
Sat Feb 10, 2007 5:25 pm
I decided to keep posting progress reports because some of you might find this phase of development to be interesting.
Enough of the software is working so that I can start to do some things with the robot. I have "calibrated" the servos so that I can work with joint angles inside the software, and this allowed me to define a hardcoded standing "neutral pose". On powerup, the joint positions are approximated from the feedback voltages (the wires I soldered to the potentiometers on all the servos), and over the course of one second, Bing transitions to the neutral pose so it will remain standing.
bigger: http://happyrobots.com/bing3w2.jpg
Notice the wires coming out of the shoulder. For the first few months of its life, Bing will operate on this tether, which contains an external power source so I don't have to charge the battery all the time and for a fast reliable serial data connection. The wire bundle goes up to the end of a long piece of flexible steel springy wire (like a coat hanger wire) which allows the cables to go straight up no matter whether Bing is standing or lying down, without being under much tension at all.
For the power connector, I took an idea from Combat "robots". I use a four prong receptacle, which lets me plug different things in for different functions:
With nothing plugged in, Bing is dormant because nothing is attached to the power. The top scenario is a plug that is an internal power switch like would be used at a competition or for an untethered run about the house. The middle scenario is the tethered operation with an external power supply. And the bottom plug would be used to recharge the internal battery.
124 days to go until RoboGames (competitions and the deadlines they bring with them add a little excitement and motivation to hobbies I think). I have some time to just play around with things... in particular, I want to start playing around with the sensors.
Here's an experiment I'm working on right now... To start thinking about balance, I poke Bing in the chest while it's standing still, causing it to rock backwards about 5 degrees. Here's a graph of some sensor data:
To me, this stuff is really interesting and I'm having great fun looking at graphs like these. The total time of the data graph is about 10 seconds.
The blue line labeled "FB" adds up the sensor readings from all four of the pressure sensors at the front of both feet, then subtracts the readings from the backs of the feet, so it will have a positive value when the robot is leaning forward, and a negative value when the robot leans backward.
The green line labeled "Accel" is the accelerometer that is sensitive to tilts and accelerations forward/backward.
The Red line labeled "Gyro" is the gyro sensitive to rotations in the forward/backward direction.
Although the accelerometer is sometimes called a "tilt" sensor because tilting it will change its reading, it is not good at measuring tilt in a dynamic situation. Looking at the green line in the graph, you can see that the acceleration caused by me poking Bing's chest overwhelms the initial movement backwards and the graph value actually goes up. Then when the robot rocks back forward again, the accelerometer reports this new acceleration. Those accelerations are very interesting but they do not help estimate tilt angle and in a situation like this, the accelerometer is pretty much useless for determining tilt, but when the bot is still it is a very accurate tilt measurement.
The red Gyro line best shows the oscillations that the robot goes through as it rocks backwards, then forwards, then backwards again, settling down pretty quickly to standing straight up again.
The black line is the beginning of a (rather standard) approach to computing the actual tilt. The idea is to "integrate" the gyro reading to estimate the tilt angle. That sounds mathematically fancy but it's actually pretty simple. I measured a "steady" reading of 248 from the gyro while it's standing still. All I have to do is measure the difference between the current gyro reading and 248 to get the current rotation rate. Then just keep a running total of those numbers. As you can see from the black line in the graph, it gives a pretty nice tilt response. However, if you look closely you can tell that the whole black line is slowly drifting upwards over time. There are several factors that cause this. First, this integration assumes that the rotation rate is the same for the entire period between readings (about 13 milliseconds in this case). That is actually not quite true, though it's pretty close to being true. Second, the steady value of 248 is not completely accurate. Suppose that the actual real world value is 247.5. Then each sample, an error of 0.5 would be added to the sum and over time those errors add up. That's the major cause of the long term drift. Also, noise in the sensor and my electronic circuits plus some lowpass filtering that I do in my electronics all cause errors to creep in.
The solution to this that people usually use is to move the tilt reading toward the accelerometer's estimate of the tilt by just a little bit each cycle. In the short term, the fluctuations caused by accelerations won't cause much damage to the estimate because it's only a small variation. In the long term, as long as the "little bit" of correction is larger than the long-term drift, in the long run the tilt estimate will be pretty close to accurate. I think I'll play with that next, which requires a bunch more calibration to get right. When that's done, I'll have a "tilt angle" measurement that I can use in the software.
Fun stuff. Kind of a lot of text to read but hopefully interesting to somebody. None of this is original to me, I think this method of using a gyro and an accelerometer together is a pretty normal simple-minded approach for coding an IMU.
Enough of the software is working so that I can start to do some things with the robot. I have "calibrated" the servos so that I can work with joint angles inside the software, and this allowed me to define a hardcoded standing "neutral pose". On powerup, the joint positions are approximated from the feedback voltages (the wires I soldered to the potentiometers on all the servos), and over the course of one second, Bing transitions to the neutral pose so it will remain standing.
bigger: http://happyrobots.com/bing3w2.jpg
Notice the wires coming out of the shoulder. For the first few months of its life, Bing will operate on this tether, which contains an external power source so I don't have to charge the battery all the time and for a fast reliable serial data connection. The wire bundle goes up to the end of a long piece of flexible steel springy wire (like a coat hanger wire) which allows the cables to go straight up no matter whether Bing is standing or lying down, without being under much tension at all.
For the power connector, I took an idea from Combat "robots". I use a four prong receptacle, which lets me plug different things in for different functions:
With nothing plugged in, Bing is dormant because nothing is attached to the power. The top scenario is a plug that is an internal power switch like would be used at a competition or for an untethered run about the house. The middle scenario is the tethered operation with an external power supply. And the bottom plug would be used to recharge the internal battery.
124 days to go until RoboGames (competitions and the deadlines they bring with them add a little excitement and motivation to hobbies I think). I have some time to just play around with things... in particular, I want to start playing around with the sensors.
Here's an experiment I'm working on right now... To start thinking about balance, I poke Bing in the chest while it's standing still, causing it to rock backwards about 5 degrees. Here's a graph of some sensor data:
To me, this stuff is really interesting and I'm having great fun looking at graphs like these. The total time of the data graph is about 10 seconds.
The blue line labeled "FB" adds up the sensor readings from all four of the pressure sensors at the front of both feet, then subtracts the readings from the backs of the feet, so it will have a positive value when the robot is leaning forward, and a negative value when the robot leans backward.
The green line labeled "Accel" is the accelerometer that is sensitive to tilts and accelerations forward/backward.
The Red line labeled "Gyro" is the gyro sensitive to rotations in the forward/backward direction.
Although the accelerometer is sometimes called a "tilt" sensor because tilting it will change its reading, it is not good at measuring tilt in a dynamic situation. Looking at the green line in the graph, you can see that the acceleration caused by me poking Bing's chest overwhelms the initial movement backwards and the graph value actually goes up. Then when the robot rocks back forward again, the accelerometer reports this new acceleration. Those accelerations are very interesting but they do not help estimate tilt angle and in a situation like this, the accelerometer is pretty much useless for determining tilt, but when the bot is still it is a very accurate tilt measurement.
The red Gyro line best shows the oscillations that the robot goes through as it rocks backwards, then forwards, then backwards again, settling down pretty quickly to standing straight up again.
The black line is the beginning of a (rather standard) approach to computing the actual tilt. The idea is to "integrate" the gyro reading to estimate the tilt angle. That sounds mathematically fancy but it's actually pretty simple. I measured a "steady" reading of 248 from the gyro while it's standing still. All I have to do is measure the difference between the current gyro reading and 248 to get the current rotation rate. Then just keep a running total of those numbers. As you can see from the black line in the graph, it gives a pretty nice tilt response. However, if you look closely you can tell that the whole black line is slowly drifting upwards over time. There are several factors that cause this. First, this integration assumes that the rotation rate is the same for the entire period between readings (about 13 milliseconds in this case). That is actually not quite true, though it's pretty close to being true. Second, the steady value of 248 is not completely accurate. Suppose that the actual real world value is 247.5. Then each sample, an error of 0.5 would be added to the sum and over time those errors add up. That's the major cause of the long term drift. Also, noise in the sensor and my electronic circuits plus some lowpass filtering that I do in my electronics all cause errors to creep in.
The solution to this that people usually use is to move the tilt reading toward the accelerometer's estimate of the tilt by just a little bit each cycle. In the short term, the fluctuations caused by accelerations won't cause much damage to the estimate because it's only a small variation. In the long term, as long as the "little bit" of correction is larger than the long-term drift, in the long run the tilt estimate will be pretty close to accurate. I think I'll play with that next, which requires a bunch more calibration to get right. When that's done, I'll have a "tilt angle" measurement that I can use in the software.
Fun stuff. Kind of a lot of text to read but hopefully interesting to somebody. None of this is original to me, I think this method of using a gyro and an accelerometer together is a pretty normal simple-minded approach for coding an IMU.
by DerekZahn
Sat Feb 10, 2007 5:54 pm
Oh, one other interesting thing about that graph. Notice in the time between pokes that the various sensor lines are not flat. One reason for this is that the sensors, despite my best efforts, are kind of noisy. Another reason which can be clearly seen is that when supposedly standing still, Bing is actually rocking back and forth just a little bit. This is caused by the servos trying to hold their positions and setting up resonances in Bing's natural dynamics. I think many robo-one style robots have this problem. The motion is quite small so I'm not too worried about it much, though I'd prefer it didn't happen.
by DerekZahn
Sun Feb 11, 2007 4:06 am
Thanks Jon. Hey, you're a gumstix guy so you'll be amused by another project I need to get working on for Bing... As far as I can tell, the 400mhz gumstix board is just about the biggest mips per cubic centimeter option i can find, so I'll be using that to run Bing's code. I don't really want to run linux though... for this type of task it seems like a ridiculous amount of overhead and extra junk. I'm more comfortable just treating the chip like a raw microcontroller. So I'm working on getting a Windows-based gcc environment I can use to build raw code that I will just replace the gumstix kernel with.
So far I have some leads on arm gcc distributions for windows, and I have a rough idea what u-boot does.
This is kind of an idiotic project so I probably won't post much about it but I thought you'd be a little interested since you're familiar with the gumstix from your own work.
So far I have some leads on arm gcc distributions for windows, and I have a rough idea what u-boot does.
This is kind of an idiotic project so I probably won't post much about it but I thought you'd be a little interested since you're familiar with the gumstix from your own work.
by JonHylands
Sun Feb 11, 2007 4:27 am
Hey Derek,
I'd advise you to get in touch with my brother - he probably has some ideas about how to accomplish that...
http://www.davehylands.com
Personally though, Linux gives you some nice stuff, including the ability to use wifi, bluetooth, and/or MMC cards (which can be read/written from Windows). I hate all the config crap you need to go through with Linux, but on something like the gumstix, being able to use the built in serial drivers and such makes my life much simpler.
- Jon
I'd advise you to get in touch with my brother - he probably has some ideas about how to accomplish that...
http://www.davehylands.com
Personally though, Linux gives you some nice stuff, including the ability to use wifi, bluetooth, and/or MMC cards (which can be read/written from Windows). I hate all the config crap you need to go through with Linux, but on something like the gumstix, being able to use the built in serial drivers and such makes my life much simpler.
- Jon