Per Wiimote gesteuerter Roboterarm
Jau, der Titel sagt eigentlich schon alles. Jedoch arbeitet der Arn nur sehr rudimentaer, aber dennoch schon irgendwie cool. Fuer "mal eben so am Samstag Nachmittag programmiert" hat es was ... Video inklusive.
So, wie es jetzt realisiert wurde, muss erst die Bewegung vorgemacht werden und der Arm faengt auch erst dann an, wenn die vorgemachte Bewegung zu Ende ist. Die Programmierer geben allerdings auch selber an, dass sie aus Faulheit heraus diese leichte Variante gewaehlt haben und dass es alles andere als unmoeglich sei, es besser zu machen. Dafuer ist es um so amuesanter geschrieben ;^p
Ich stelle es mir ausserdem sehr lustig vor, wenn der Firmenchef beim iNet-Surfen zufaellig ueber ein Video bei YouTube stolpert, das seine Angestellten zeigt, die ihren Spass mit den was-weiss-ich-wie-teuren Geraeten wie Industrie-Roboterarm und dergleichen haben ;^) [...]
(show me)(don't show me)
(Note: ich habe nur einige der Bilder uebernommen, weil das Video schon das Meiste zeigt. Also, nicht zoegern und die Seite besuchen, wenn ihr die "volle Ladung" wollt ;^)
<<
WiiBot: How to build a sword-wielding, tennis-playing, WiiMote-controlled, friendly robot
1.22.06
Brian and I were talking in his office a couple weeks ago about the Kuka robots’ fast reactions to serial data, and I realized, hey, why not hook it to a WiiMote? We had both fallen for Nintendo’s plucky little controller like everyone else, and had seen plenty of other WiiMote hacks. It had been a number of weeks of work without any rest, so we decided to set aside the coming Saturday to hook up one of the robots to a WiiMote.
The idea was to take one industrial robot, add a laptop talking to a WiiMote, strap on a tennis racket, have it follow the swings that the user makes, and do it all in a few hours on a Saturday so we could get back to our busy schedules. Of course we had to put on a sword too, and if there was time, maybe an Airsoft gun. Also, we wanted it to fight people, but you can’t have everything.
I dragged myself out of bed at noon-thirty and called Brian to see if he still wanted to try the Wii hack. We met at the office (where we spend most of our Saturdays) and I set to work on the WiiMote-to-robot software. He began the epic process of attaching a tennis racket to the KR16 and programming the physical motions into it.
A KR16 is a small industrial robot by Kuka. There were a couple in the shop waiting to be installed for various industrial projects. The one we were using had a polishing wheel on it.
The Software
At first I was going to try to use GlovePIE for all of the WiiMote functions and have it send a number to a small VB app that would pass the move number on to the KUKA controller through serial. I hacked at it for a good hour, trying to use the maximum accelerometer readings from various swings to differentiate them. It only sort of worked, but could only differentiate a few swings, and was very tedious to tweak.
I decided to just suck it up and write some sort of pattern recognition algorithm so I could record the user’s swings and do a best match to some predefined swings. What resulted was an algorithm described by probably the loosest use of the term “pattern recognition” that isn’t punishable by instant banishment to programmer Hell.
First, I had to get the data from GlovePIE into a VB.NET app. Using the Generic Joystick Driver that comes with GlovePIE seemed like a good start. I downloaded PPJoy to emulate a joystick and fed it the output from GlovePIE. So far so good. Unfortunately, the joystick wouldn’t properly initialize in VB.NET, and I had already spent too long messing with it. I downloaded a sample project to interface with a joystick from CodeProject by M. Harris. It was in C#, which I’d never programmed in before, and I didn’t feel like using a converter. All these .NET languages compile to the same thing anyways, so it’s really just a little bit of difference in syntax. I went for it.
I wrote some of the worst code ever to record the accelerometer values in a circular one-dimensional array of 3-value structs. Each value was for one accelerometer. When the user hit the B button on the WiiMote, the program would record the move into my array. When they let go, it would compare that array to all the other recorded arrays and determine the closest match.
Notice the total lack of a graphical key, borders, and the mixed generic labels on the radio buttons, oh yes, this was the sort of attention to detail I gave this project.
First, the user would record the swing for each of 6 different swings (although I only ever used 5), and then he or she would select “Analyze.” When “Analyze” was selected, the swing would be recorded into a temporary buffer and then compared to all the recorded swings. I just took the mean distance between each datapoint in the recorded swing and each datapoint in the swing I was analyzing. The swing pair that had the lowest average distance between datapoints was the match.
The swing above is an underhand swing. The green line is what the user just did, the red line was the closest match in memory. The blue line is a bizarre representation of what the accelerometers are doing. I like to look at things graphically, so I just hacked something together in GDI+, so I’m not sure what the blue line shows, but you can tell when any of the three accelerometers change by watching it.
[...] skipped some pictures here [...]
Brian finishing with overhand--notice how he has to finish the move before the data gets sent to the robot to tell it which swing to make.
Me doing said parry.
As soon as the software worked without crashing, I tested it with a few different swings, and it actually worked surprisingly well. That was good enough for a Saturday afternoon, so I headed downstairs to the robot to see how Brian was doing.
The hardware
Brian was just completing the motions for the robot when I came downstairs. Basically, you drive the robot with a 6D mouse to points in space that you want it to hit, save those points, and the robot will interpolate between them. The 6D mouse looks like a knob sticking out of the side of the controller. You can push it in all three dimensions and twist it in all three dimensions, giving you your 6 degrees.
Brian had attached the tennis racket to the polishing wheel that was already there with the most elaborate set of tie-wraps I’d ever seen. Our hardware was this:
1x Dell Laptop
I couldn’t get XCode to do what I wanted, so no Mac, much to Brian’s chagrin
2x WiiMotes
in case we accidentally flung one, we had a spare
1x KR16 Industrial Robot
these run in the mid five-figures, I believe, and I have yet to find one at a garage sale
1x Serial-to-USB adapter called the AirLink 101
this is the best Serial-to-USB adapter I’ve used, it hasn’t dropped data on me yet. I found it in a bucket,
however, so I’m not sure where you can get more of them
3x Tubes of tennis balls
these were very cheap, and smelled kind of fishy. I would spend the extra 40 cents in the future for less fishy
ones.
1x Tennis Racket
1x Sword
this was from Brian’s garage, I’m not sure from where it came or for what it’s used; come to think of it, I don’t
really want to know..
3*10^45x Tie-Wraps
600lbs of SharpJet waterjet garnet
We had to stack some of the garnet we’re using in one of our products on the KR16 to keep it on the ground.
The torque from flinging that big arm around made it twist on the ground without it.
We hooked up the WiiMote to the robot and gave it a swing. It worked quite well, although it was a bit frightening before we put the 600lbs of garnet on the robot stand. We played with it for a while with the one tennis ball we had, and found that it was extremely difficult to get the robot to hit the ball. We meant to take some video, but we wasted too much time playing around with the robot. It was about dinnertime, so we headed out.
The next Tuesday
We dragged out the video camera and shot some footage on Tuesday night, the day after Christmas. Brian’s sister stopped by for a spell, so she did us the favor of holding the camera for the intro. It turned out that Philip, one of our programmers, had absolutely unreal abilities when it came to throwing a tennis ball at a racket-wielding robot. Brian and I had tried the same feat over and over on Saturday, and Philip managed to hit the racket very consistently.
As you might expect, we ended up swinging the racket and then throwing the ball at it, rather than trying to hit a ball that was already in the air. Since the software had to wait until the person completed his or her swing to send the swing to the robot, the delay was a little longer than I would have liked. You can see it in the video.
Philip succeeded in hitting me a couple times with the tennis ball while I held the video camera. Actually, it was really a group effort between Brian and Philip to hit me with the tennis ball. Brian did some nice swings; Philip did some nice throws; I did some poor dodging. It was a fun time.
Putting a sword on it
Since we had the camera out, we set to attaching a sword to the robot. I took Alexander’s approach to the rather Gordian problem of the tie-wraps, and simply took some diagonal cutters to them. I worked on getting the software to take an extra swing, while Brian attached the sword and programmed in the new movements.
The sword proved much, much, more frightening than the tennis racket. The KR16 has that model number because it can move 16kg at full speed and full accuracy. That’s a surprising amount of mass, and the sword doesn’t weigh anywhere near that mark. We all realized that the robot could decapitate us with little difficulty. Fortunately, the Kukas tend to be freakishly accurate, as in the robot is a freak even among other robots, not just among humans. They have accuracies measured in the hundredths of an inch, so we were never really in any danger of it accidentally hitting us. However, I wasn’t entirely convinced the sword wouldn’t come flying off mid-swing and stick in my head. I imagined that would be unsettling and inconvenient.
The software certainly wasn’t perfect and was pretty sensitive to the operator who trained it. It hardly ever knew which of Brian’s moves I was trying to emulate, and it could almost never get the right match between moves I had trained and Brian’s recreations of them.
Adding a gun
Unfortunately, I didn’t have time to write software that would convert the infrared targeting on the WiiMote to aiming points for the Kuka, so we couldn’t put an airsoft gun on it. Oh well. I would like to play with the WiiMote some more some other day and learn about the infrared.
It was certainly a project worth half of our Saturday and a lot of fun. I hope you enjoyed it too. Questions or comments can be directed to me, Aaron Rasmussen, through my email at: ai.rasmussen@gmail.com
>> # top # | Q: US Mecha Tronics.com
sent by Mika77
So, wie es jetzt realisiert wurde, muss erst die Bewegung vorgemacht werden und der Arm faengt auch erst dann an, wenn die vorgemachte Bewegung zu Ende ist. Die Programmierer geben allerdings auch selber an, dass sie aus Faulheit heraus diese leichte Variante gewaehlt haben und dass es alles andere als unmoeglich sei, es besser zu machen. Dafuer ist es um so amuesanter geschrieben ;^p
Ich stelle es mir ausserdem sehr lustig vor, wenn der Firmenchef beim iNet-Surfen zufaellig ueber ein Video bei YouTube stolpert, das seine Angestellten zeigt, die ihren Spass mit den was-weiss-ich-wie-teuren Geraeten wie Industrie-Roboterarm und dergleichen haben ;^) [...]
(show me)(don't show me)
(Note: ich habe nur einige der Bilder uebernommen, weil das Video schon das Meiste zeigt. Also, nicht zoegern und die Seite besuchen, wenn ihr die "volle Ladung" wollt ;^)
<<
WiiBot: How to build a sword-wielding, tennis-playing, WiiMote-controlled, friendly robot
1.22.06
The idea was to take one industrial robot, add a laptop talking to a WiiMote, strap on a tennis racket, have it follow the swings that the user makes, and do it all in a few hours on a Saturday so we could get back to our busy schedules. Of course we had to put on a sword too, and if there was time, maybe an Airsoft gun. Also, we wanted it to fight people, but you can’t have everything.
I dragged myself out of bed at noon-thirty and called Brian to see if he still wanted to try the Wii hack. We met at the office (where we spend most of our Saturdays) and I set to work on the WiiMote-to-robot software. He began the epic process of attaching a tennis racket to the KR16 and programming the physical motions into it.
A KR16 is a small industrial robot by Kuka. There were a couple in the shop waiting to be installed for various industrial projects. The one we were using had a polishing wheel on it.
The Software
At first I was going to try to use GlovePIE for all of the WiiMote functions and have it send a number to a small VB app that would pass the move number on to the KUKA controller through serial. I hacked at it for a good hour, trying to use the maximum accelerometer readings from various swings to differentiate them. It only sort of worked, but could only differentiate a few swings, and was very tedious to tweak.
I decided to just suck it up and write some sort of pattern recognition algorithm so I could record the user’s swings and do a best match to some predefined swings. What resulted was an algorithm described by probably the loosest use of the term “pattern recognition” that isn’t punishable by instant banishment to programmer Hell.
First, I had to get the data from GlovePIE into a VB.NET app. Using the Generic Joystick Driver that comes with GlovePIE seemed like a good start. I downloaded PPJoy to emulate a joystick and fed it the output from GlovePIE. So far so good. Unfortunately, the joystick wouldn’t properly initialize in VB.NET, and I had already spent too long messing with it. I downloaded a sample project to interface with a joystick from CodeProject by M. Harris. It was in C#, which I’d never programmed in before, and I didn’t feel like using a converter. All these .NET languages compile to the same thing anyways, so it’s really just a little bit of difference in syntax. I went for it.
I wrote some of the worst code ever to record the accelerometer values in a circular one-dimensional array of 3-value structs. Each value was for one accelerometer. When the user hit the B button on the WiiMote, the program would record the move into my array. When they let go, it would compare that array to all the other recorded arrays and determine the closest match.
Notice the total lack of a graphical key, borders, and the mixed generic labels on the radio buttons, oh yes, this was the sort of attention to detail I gave this project.
First, the user would record the swing for each of 6 different swings (although I only ever used 5), and then he or she would select “Analyze.” When “Analyze” was selected, the swing would be recorded into a temporary buffer and then compared to all the recorded swings. I just took the mean distance between each datapoint in the recorded swing and each datapoint in the swing I was analyzing. The swing pair that had the lowest average distance between datapoints was the match.
The swing above is an underhand swing. The green line is what the user just did, the red line was the closest match in memory. The blue line is a bizarre representation of what the accelerometers are doing. I like to look at things graphically, so I just hacked something together in GDI+, so I’m not sure what the blue line shows, but you can tell when any of the three accelerometers change by watching it.
[...] skipped some pictures here [...]
Brian finishing with overhand--notice how he has to finish the move before the data gets sent to the robot to tell it which swing to make.
Me doing said parry.
As soon as the software worked without crashing, I tested it with a few different swings, and it actually worked surprisingly well. That was good enough for a Saturday afternoon, so I headed downstairs to the robot to see how Brian was doing.
The hardware
Brian was just completing the motions for the robot when I came downstairs. Basically, you drive the robot with a 6D mouse to points in space that you want it to hit, save those points, and the robot will interpolate between them. The 6D mouse looks like a knob sticking out of the side of the controller. You can push it in all three dimensions and twist it in all three dimensions, giving you your 6 degrees.
Brian had attached the tennis racket to the polishing wheel that was already there with the most elaborate set of tie-wraps I’d ever seen. Our hardware was this:
1x Dell Laptop
I couldn’t get XCode to do what I wanted, so no Mac, much to Brian’s chagrin
2x WiiMotes
in case we accidentally flung one, we had a spare
1x KR16 Industrial Robot
these run in the mid five-figures, I believe, and I have yet to find one at a garage sale
1x Serial-to-USB adapter called the AirLink 101
this is the best Serial-to-USB adapter I’ve used, it hasn’t dropped data on me yet. I found it in a bucket,
however, so I’m not sure where you can get more of them
3x Tubes of tennis balls
these were very cheap, and smelled kind of fishy. I would spend the extra 40 cents in the future for less fishy
ones.
1x Tennis Racket
1x Sword
this was from Brian’s garage, I’m not sure from where it came or for what it’s used; come to think of it, I don’t
really want to know..
3*10^45x Tie-Wraps
600lbs of SharpJet waterjet garnet
We had to stack some of the garnet we’re using in one of our products on the KR16 to keep it on the ground.
The torque from flinging that big arm around made it twist on the ground without it.
We hooked up the WiiMote to the robot and gave it a swing. It worked quite well, although it was a bit frightening before we put the 600lbs of garnet on the robot stand. We played with it for a while with the one tennis ball we had, and found that it was extremely difficult to get the robot to hit the ball. We meant to take some video, but we wasted too much time playing around with the robot. It was about dinnertime, so we headed out.
The next Tuesday
We dragged out the video camera and shot some footage on Tuesday night, the day after Christmas. Brian’s sister stopped by for a spell, so she did us the favor of holding the camera for the intro. It turned out that Philip, one of our programmers, had absolutely unreal abilities when it came to throwing a tennis ball at a racket-wielding robot. Brian and I had tried the same feat over and over on Saturday, and Philip managed to hit the racket very consistently.
As you might expect, we ended up swinging the racket and then throwing the ball at it, rather than trying to hit a ball that was already in the air. Since the software had to wait until the person completed his or her swing to send the swing to the robot, the delay was a little longer than I would have liked. You can see it in the video.
Philip succeeded in hitting me a couple times with the tennis ball while I held the video camera. Actually, it was really a group effort between Brian and Philip to hit me with the tennis ball. Brian did some nice swings; Philip did some nice throws; I did some poor dodging. It was a fun time.
Putting a sword on it
Since we had the camera out, we set to attaching a sword to the robot. I took Alexander’s approach to the rather Gordian problem of the tie-wraps, and simply took some diagonal cutters to them. I worked on getting the software to take an extra swing, while Brian attached the sword and programmed in the new movements.
The sword proved much, much, more frightening than the tennis racket. The KR16 has that model number because it can move 16kg at full speed and full accuracy. That’s a surprising amount of mass, and the sword doesn’t weigh anywhere near that mark. We all realized that the robot could decapitate us with little difficulty. Fortunately, the Kukas tend to be freakishly accurate, as in the robot is a freak even among other robots, not just among humans. They have accuracies measured in the hundredths of an inch, so we were never really in any danger of it accidentally hitting us. However, I wasn’t entirely convinced the sword wouldn’t come flying off mid-swing and stick in my head. I imagined that would be unsettling and inconvenient.
The software certainly wasn’t perfect and was pretty sensitive to the operator who trained it. It hardly ever knew which of Brian’s moves I was trying to emulate, and it could almost never get the right match between moves I had trained and Brian’s recreations of them.
Adding a gun
Unfortunately, I didn’t have time to write software that would convert the infrared targeting on the WiiMote to aiming points for the Kuka, so we couldn’t put an airsoft gun on it. Oh well. I would like to play with the WiiMote some more some other day and learn about the infrared.
It was certainly a project worth half of our Saturday and a lot of fun. I hope you enjoyed it too. Questions or comments can be directed to me, Aaron Rasmussen, through my email at: ai.rasmussen@gmail.com
>> # top # | Q: US Mecha Tronics.com
sent by Mika77
Labels: new technology, video, videogame news
posted by Woodrow at 2/06/2007 03:05:00 AM
0 comments
0 Comments:
Post a Comment