Last week Chris invited me to contribute to Tinkernology,
and here it is... your reading my first post.
Every year I build one large LEGO model. My last model
which wasn't a robot was a Startrek model. (if you're
interested you can find it here)
About four years ago I started looking for a new building
challenge. It had to be something technical, with lots
of electric components.
What could be considered almost impossible to build?
I decided to build a biped robot...
The first goal was to just try and see how far
I would come. After studying videos and images of Hondas
Asimo robot I started building.
I used the old 9v motors combined with the RCX
rotation sensors. After working on the robot for about six
months it was finished, it had 22 degrees of freedom.
When the robot was finished it was clear that my construction
would not be able to walk. The legs could move but the robot
was too heavy to stand on one leg.
Another problem was the complexity of controlling the robot.
Because of the large number of motors and sensors I needed
eight RCX bricks to control it. It was just not practical.
So... the robot was finished, was looking pretty good but
could not walk. What should I do now, look for something
else to build? Or would it be possible to improve my design?
Next time: Another year, another robot...
The masters showing how it's done:
Sunday, June 27, 2010
Saturday, June 26, 2010
New Blogger With Tinkernology
Monday, June 21, 2010
Love The Hackers.
I found this over at Make Magazine. A guy named Eric von Hippel explains how the Lego Company has embraced us (meaning unconventional users, or Hackers) and exceeded their expectations with sales of Mindstorms products.
Biped
Arno, A.K.A. “legoasimo” is working on a Biped that reminds me of the Bioloid. The monster MOC is controlled by three NXTs running NXC tethered out of sight. He has filled this bot with fourteen motors and ten sensors and done a spectacular job cramming it all into a small package.
The robot shifts his weight using its upper body weight along with its arms, which gives it a natural anthropomorphic look. Arno tells me that he is done building the robot, but plans to keep working on the software to make it walk. This video is basically a “proof of concept” and I think he has proven his concept will work quite nicely. He also tells me that there will be more videos, so stayed tuned.
You can see more pictures at his flickr site.
The robot shifts his weight using its upper body weight along with its arms, which gives it a natural anthropomorphic look. Arno tells me that he is done building the robot, but plans to keep working on the software to make it walk. This video is basically a “proof of concept” and I think he has proven his concept will work quite nicely. He also tells me that there will be more videos, so stayed tuned.
You can see more pictures at his flickr site.
Sunday, June 20, 2010
Cool High School Mechatronics Project
Here is a video of a long, complicated "assembly line-like" ball handling system built by some tenth graders at The Achva Gilboa High School which I believe is in Israel. Lots of cool moving parts. I could do without the "Love Story" music though, but that is my personal preference and it doesn't take from the video.
Saturday, June 19, 2010
Powerhouse
Does anyone else have this song running through their head while you are building? I do...all the time.
I guess that only some of my readers will understand the meaning of this song.
I guess that only some of my readers will understand the meaning of this song.
NXT Racing Game
If you like pure programming with no building, this game is for you. YouTube user Lumpiluk created a cool racing game with some decent graphics. It reminds me of the old Mattel Football game.
You can download the game (written in NXC) here.
Hey, I just realize that Lumpiluk did both the Radar and the Racing game. Nice work!
You can download the game (written in NXC) here.
Hey, I just realize that Lumpiluk did both the Radar and the Racing game. Nice work!
Ultrasonic Radar
Here’s a neat little “radar.” It uses the ultrasonic sensor to sweep about 360 degrees and then gives a few different ways to display the findings. I like this one because MARVIN has a similar radar mounted on him. I am surprised that this project hasn’t been attempted more times.
Thursday, June 17, 2010
Saturday, June 12, 2010
Freakin' Monster Chess
OK, if you don't say "holy crap" while watching these two videos, there is something wrong. Read more on on The NXTStep and at Team Hassenplug
Wednesday, June 9, 2010
Communicating With Light
I am really impressed how things are going since I decide to use light sensors to communicate. It turns out that once you get the programming and physical setup working, communicating with light is a very reliable way to talk. I am still using this basic setup.
The pros far outweigh the cons in my opinion.
Pro-
• No Bluetooth and all of those hassles, i.e. inconsistency, lockups, confusing code, etc.
• All NXTs can communicate equally as a master or a slave.
• As soon as the NXT is turned on and the program is initiated, the communications are ready to go. No handshaking is necessary.
• In theory, I can communicate with many NXTs, even more than the six that I am currently using.
• It makes a cool light show in the bowels of my robot.
• If NXT #1 is talking to NXT #2, all the other NXTs can “monitor” what is going on if needed.
• It is very easy to synchronize all the NXTs. Timing is no longer an issue. When the message is sent, automatically all the NXTs are synchronized by the initiating signal.
Con-
• It uses up a sensor port (I have 30 available, so who cares???)
• It’s slow compared to Bluetooth, taking up about 1/3 of second to send a message. But really, is 1/3 of a second really that slow?
• I am not sure, but it might be hard on the sensor light. There’s a heck of a lot of flashing going on and it might shorten the life of the sensor. But I haven’t had a problem yet.
I have even set it up so that there are two “mailboxes.” I can send “Jobs” or “Messages.” I differentiate them by the time that the initial blink of the light stays on. If the initial blink is about 50ms long, it’s a “job.” If the initial blink is about 100 ms long, it is a “message.” Each of these types of messages is handled differently in the programs. Technically, there is a third type of mailbox too. If the sensor light stays on for 250ms, it is an emergency stop, and all the bricks interrupt what they are doing and immediate halt in place. Any brick can stop the entire process if there is a problem.
The type of data that is sent is binary numbers. I can send number from 1 to 63 for each Job or Message. For example, the master NXT sends out a job number 39, and each of the other five NXTs along with the master do the respective task assigned to the number 39, in this case play some music.
I have set the programming up so there is a universal header file (a driver) that is used by all six bricks. That is extremely handy, change the code once, and it carries through all the programs.
I am certainly going to use this technique more in the future.
UPDATE:
Got picked up on MAKE! Sweet!
The pros far outweigh the cons in my opinion.
Pro-
• No Bluetooth and all of those hassles, i.e. inconsistency, lockups, confusing code, etc.
• All NXTs can communicate equally as a master or a slave.
• As soon as the NXT is turned on and the program is initiated, the communications are ready to go. No handshaking is necessary.
• In theory, I can communicate with many NXTs, even more than the six that I am currently using.
• It makes a cool light show in the bowels of my robot.
• If NXT #1 is talking to NXT #2, all the other NXTs can “monitor” what is going on if needed.
• It is very easy to synchronize all the NXTs. Timing is no longer an issue. When the message is sent, automatically all the NXTs are synchronized by the initiating signal.
Con-
• It uses up a sensor port (I have 30 available, so who cares???)
• It’s slow compared to Bluetooth, taking up about 1/3 of second to send a message. But really, is 1/3 of a second really that slow?
• I am not sure, but it might be hard on the sensor light. There’s a heck of a lot of flashing going on and it might shorten the life of the sensor. But I haven’t had a problem yet.
I have even set it up so that there are two “mailboxes.” I can send “Jobs” or “Messages.” I differentiate them by the time that the initial blink of the light stays on. If the initial blink is about 50ms long, it’s a “job.” If the initial blink is about 100 ms long, it is a “message.” Each of these types of messages is handled differently in the programs. Technically, there is a third type of mailbox too. If the sensor light stays on for 250ms, it is an emergency stop, and all the bricks interrupt what they are doing and immediate halt in place. Any brick can stop the entire process if there is a problem.
The type of data that is sent is binary numbers. I can send number from 1 to 63 for each Job or Message. For example, the master NXT sends out a job number 39, and each of the other five NXTs along with the master do the respective task assigned to the number 39, in this case play some music.
I have set the programming up so there is a universal header file (a driver) that is used by all six bricks. That is extremely handy, change the code once, and it carries through all the programs.
I am certainly going to use this technique more in the future.
UPDATE:
Got picked up on MAKE! Sweet!
Monday, June 7, 2010
Lego Traffic Light
Here's a simple little project done by a forth grader. It's not complicated or flashy, but it made me smile. I also think that is funny that a fourth grader truly understands the frustration of traffic lights (probably got some of that from his dad!)
Saturday, June 5, 2010
MARVIN Update.
The topic of this update is “Know When You Are Beaten.”
Don’t worry; construction on MARVIN is still moving along. But I have hit some snags and those snags are just taking up way too much time and causing too much complication, so I am “downsizing.” but only slightly.
You see, I had planned (and built) an air compressor and nearly the entire system to run one of the pranks. But there were a few elements that I could get to work just right. I was considering doing two things that would simply compromise my beliefs. I would be adding non-Lego parts, and I would have to modify standard Lego parts. That was just not setting right with me. The system was getting really complicated and space is getting really tight. Plus the robot is already too heavy. I considered what the final product was going to be and how much work I was putting into it and it just wasn’t worth it. In short, the robot was going to shoot a stream of water on command. I was going to use a small bottle (non-Lego) to store the water and to get a tight stream I would have needed to modify a tube. Too much work for a teaspoon of water.
Another problem has been RobotC. If you use RobotC, you know that it can be buggy and when an upgrade happens, often times some of the features that were previously working just fine can go bad. Well, that happened to me, so I have been fighting with that for a couple of weeks now. I think it is sorted out now.
And you know what else is a pain in the butt? It’s a pain when you have 20+ motors and 30+ sensors and all of their wires cross. It turns into a pile of black spaghetti. Mind you, I took the time to plan each and every wire, port, sensor, battery box, all of it. When I hooked it all up a couple of weeks ago, it made sense. Today I have to look at my plans and follow each wire to its source when I do anything. Color coding the wires would be great, but it’s a little too late for that now.
And I am also finding out that the caster wheels the I “thought” were going to be rugged enough aren’t at all strong enough. The can handle the weight for a decent amount of time, but as the robot sits, the axles will bend over time. So I have built a stand that keeps all the wheels off the ground while I am working on it. I hope that works.
Alright, it’s time for me to stop talking and start programming. I think (and hope) I am ready. I hope to get some good pictures up soon, and even possibly some preliminary video too.
Don’t worry; construction on MARVIN is still moving along. But I have hit some snags and those snags are just taking up way too much time and causing too much complication, so I am “downsizing.” but only slightly.
You see, I had planned (and built) an air compressor and nearly the entire system to run one of the pranks. But there were a few elements that I could get to work just right. I was considering doing two things that would simply compromise my beliefs. I would be adding non-Lego parts, and I would have to modify standard Lego parts. That was just not setting right with me. The system was getting really complicated and space is getting really tight. Plus the robot is already too heavy. I considered what the final product was going to be and how much work I was putting into it and it just wasn’t worth it. In short, the robot was going to shoot a stream of water on command. I was going to use a small bottle (non-Lego) to store the water and to get a tight stream I would have needed to modify a tube. Too much work for a teaspoon of water.
Another problem has been RobotC. If you use RobotC, you know that it can be buggy and when an upgrade happens, often times some of the features that were previously working just fine can go bad. Well, that happened to me, so I have been fighting with that for a couple of weeks now. I think it is sorted out now.
And you know what else is a pain in the butt? It’s a pain when you have 20+ motors and 30+ sensors and all of their wires cross. It turns into a pile of black spaghetti. Mind you, I took the time to plan each and every wire, port, sensor, battery box, all of it. When I hooked it all up a couple of weeks ago, it made sense. Today I have to look at my plans and follow each wire to its source when I do anything. Color coding the wires would be great, but it’s a little too late for that now.
And I am also finding out that the caster wheels the I “thought” were going to be rugged enough aren’t at all strong enough. The can handle the weight for a decent amount of time, but as the robot sits, the axles will bend over time. So I have built a stand that keeps all the wheels off the ground while I am working on it. I hope that works.
Alright, it’s time for me to stop talking and start programming. I think (and hope) I am ready. I hope to get some good pictures up soon, and even possibly some preliminary video too.
Hackerspace Documentary
I found this over at Make Magazine. It's a six minute mini-documentary on "Hackerspace." It's a concept where like-minded people gather frequently to work on their personal projects, share knowledge and, of course, to socialize. In this case, those people are electronics geeks.
I like the idea, but change it to "Lego Robotics Space."
I like the idea, but change it to "Lego Robotics Space."
A Different Cube Solver
I know that I said I wouldn’t post anymore Cube solver robots, but this one is different enough to bend the rules. It’s not the fastest, and I am pretty sure that all the hardware (motors, sensors, even the processor) is not Lego, but the structure is clearly Lego. This solver doesn’t rotate the cube itself, just the sides, top and bottom. It’s a unique solution so I like it.
Thursday, June 3, 2010
Excavator Stunt
Here's a stunt done with an excavtor that if you haven't seen, you won't believe. It's from a 1997 German TV show called Wetten dass. The machine actually climbs a metal tower and does a showy dance at the top. Wow.
I wonder if our excavator will be able to do that.
By the way, great music on both videos.
I wonder if our excavator will be able to do that.
By the way, great music on both videos.
Steampunk Robots
From one of the greatest series of all times, Modern Marvels. Check this stuff out. Talk about being creative with your power source.
So who out there is willing to throw a 250 degree F. boiler on top of their Lego Robot?
So who out there is willing to throw a 250 degree F. boiler on top of their Lego Robot?
Wednesday, June 2, 2010
Lego Printer
This printer has lots of non-Lego electronic parts, but I can appreciate the mechanical aspects. Plus the output copy is really good, by far the best I have seen.
Subscribe to:
Posts (Atom)