Over the summer we installed hardwood flooring – which needs constant sweeping and cleaning . What to do… What to do… Well, most of us would just sweep it, right? Some of us might even go buy a Roomba. But, then again, some of us build something to do it for them. Why? Because we can…
Pulito (Italian for ‘clean’) is simply put, a sweeper robot. Much like a Swiffer and Roomba combined. The intent was to build a robot that could navigate around sweeping hard surface floors, stay away from carpeted areas, make its way under our couches and seek out a docking station when the battery runs low.
Sometimes I build robots that attempt to solve real world challenges. Other times, robots are built based on random ideas. This robot is a case of solving a LEGO challenge – specifically, with their Technic tracks/treads #575518. At no fault of theirs, these plastic tracks are slippery on many surfaces. Great for carpets, flat areas, dirt (if you dare) – and great for turning as well. However, when you try to climb with them, they are as slick as ice.
If you Google them, you will find some great ideas on making these treads more ‘sticky’. Some have used 1/2 Technic pins (which fit nicely into the supplied holes), others have used elastics wrapped around them – all great ideas that work fine. I attacked the challenge from a different angle. The result is DG – or Dual Grip (yes, the name is somewhat plain). DG went through numerous revisions as I worked out kinks related to weight, stability, traction, sensors, flex etc. At the bottom I have included some pictures on previous versions of DG – some changes significant, others subtle.
The idea was to have a treaded robot that could navigate varying terrain, turn quickly and of course, climb. Based on my experience with my other robots using the same tracks (eg UNV and DynaTrax), I found that they were not very good when it came to inclines. I figured that the LEGO rubber wheels have great traction on most surfaces, so why not slap a set of them along with the treads. However, this posed another challenge. I did not want both wheel systems in contact with the ground at all times as this would make turning tougher and be redundant.
What better way to test a colour sensor then to create a brick sorting robot! After getting my hands on a HiTechnic colour sensor, I first took a stab at creating a robot that could navigate a room and detect colour. There was only one problem, it could not really do what I was hoping for. I was nieve in thinking that I could build this robot and it could detect colours from a distance. After reading the fine print on the provided documentation, I quickly realized that the colour sensor is only capable of reading colours at very close range (~ 1 cm). My bad. Of course, you could still build a robot that uses the ultrasonic or other sensor to get it close to objects, then read the colour… but that’s for another time.
BrickSorter uses this colour sensor to detect the colour of bricks and sort them into a variety of cups. The program is quite simple, gravity and studless beams allow for each brick to slide down the track on its own. when a brick is next, the colour sensor takes a reading (more on this later), the sort motor turns the sort rails to the correct cup, the sort rail motor changes its angle depending if the cup is close or far and finally the kicker motor kicks the brick in motion.
After a lot of fooling around with the cup placement (which seemed to be the hardest part of this project!), I managed to get the sorting pretty much bang on. Of course, the video shows some goofs, but that is mostly due to the small sized cups (its all I had!)… Anyway, I found the sensor to be accurate most of the time, but ambient light still influenced the readings at times and caused for the odd random missorting of a brick. I had to shoot the video about 10 times to get cup placement and sorting goofs worked out.
Your first question is probably “what does UNV stand for?”. Well, its nothing special – I simply could not come up with a name for it, so what better way to tag it then simply unnamed vehicle. After receiving a bunch of the new tread links, I wanted to create something grand with them. Scouting the web, I came across these multi-purpose robots (see below) that can be outfitted for police / bomb squad use, or for scientific work. Thought they looked pretty cool, so they were the inspiration. UNV was sitting around for months before I finally got around to taking pictures and a video of it. Read on for details…
After I had success with my challenge to build a 1″x1″x1″ NanoBot, I wanted to try my luck at something a little larger. MicroBot measures approx 2″x2″x1.5″ and uses the same Atmel microcontroller and battery (see NanoBot details). The body was custom made from a larger piece of 4mm white PVC. MicroBot gets its’ senses from 3 front mounted ProxDots (IR units) and a bottom mounted IR unit (for line following). This gives MicroBot the ability to detect left, center and right objects and to react accordingly. The drive motors are self contained units pulled from some old LS120 laptop disk drives. The motors are used to eject the disk so they have a great amount of torque for their size.
While waiting for the NXT system to come out, I decided to try my luck at making tiny robots. While Googling, I stumbled across a Yahoo newsgroup for NanoBots based on the MegaBitty controller. I have always been interested in making compact Lego robots, but for obvious reasons, they can only be so small. So, I decided to try my luck and NanoBots. Although I am not sure of the exact definition of a NanoBot, I believe it has specific maximum size limits for competition which is approx. 1 inch cubed (1x1x1). This is my first venture into non-Lego robots. NanoBot uses a variety of pico-sized components including:
Atmel Mega 8 Microcontroller
2 GWS Micro Servos – hacked into the gearbox below.
A 3.5V IPOD Shuffle battery unit w/built-in charger.
CJH line and object sensing base and front circuit (uses SMT components)
None other than Lego minfig wheels
Some of the key electronic components used on NanoBot are:
AtMega8P main CPU (IC AVR MCU 8K 16MHZ COM 32-TQFP – ATMEGA8-16AC)
Photointerrupter Line sensor (x2) 424-1096-5-ND
All caps, resistors, LED’s are surface mount technology (SMT)
This page is dedicated to the further enhancements that I have done to DominoBotNXT. For more info on the original DominoBotNXT, have a look here.
One of the drawbacks of the original was that due to the 3 motor limit, it had to backup to properly place dominos. This was because the domino-placing component was tied directly to the drive wheels. So, as it drove forward, a domino would make its way to being placed in the holder mechanism. Doing this caused the robot to move forward approx. 4 inches. Since this is too far for domino’s to actually cause any chain reaction, the robot had to move each newly placed domino back to be within 1″ of the last placed one.
Climber – One day while browsing the LEGO Mindstorms site, I noticed some pictures about a show in Germany. LEGO had built 2 cool wall climbing robots to help market the product. I was amazed at the design and capabilities that they had and wanted to find out just how hard it would be to build something like this and have it actually work. It was quite a challenge. Building the components was the easy part. Getting it to climb was (and still is) a challenge. The Climber has gone through another iteration as the one shown here is too heavy. To test the unit, I used a holesaw to cut 2 inch offset holes up a piece of wood plank. The idea would be that the Climber would start with one arm, pull itself up, and the the bottom part would shift. This would offset the Climber to one site and make it easier for the other arm to find a hole and pull itself up. This was to be a big challenge. Read on…
Showing the back of Climber. Features – the cam mechanism that turns the head can be seen at the top. One of the problems that I discovered after building it was that its design was correct in that it had the geometry to climb my test wall. The problem is that it is too heavy for itself. I should have called it Big Mama, cause it ain’t going nowhere but the bottom rung…
DominoBot 2 was my take on re-creating my original DominoBot. After I had finished the original, I found ways to make it more efficient and better at what the original did. I also did not have the limitations of the parts supplied with the RIS and UBS sets.
One of the parts that needed re-designing was the mechanism used to force domino’s out of the chamber. The original tended to have difficulties at times. I devised a mechanism using rack plates (3 – 1×4′s). It is driven by the same motor that moves the loader arm, but the method does not allow slip-up or misalignment. A touch sensor at the full-out and -in positions ensure that Dbot2 knows exactly when a domino has been pushed out and when the rack has reset.
Wall Follower was one of those “proof-of-concepts” robots. The intent was to build something small and compact that was fast and versatile. Wall Follower can navigate around a room, on a table, in a maze, whatever. It is built from one of the basic robot platforms in the Mindstorms Contructopedia. Motion is done by 2 motors, each of which can steer by removing power to one. The main sensor is the DIRPD sensor (grey) mounted on the front. Through programming, the sensor can detect 3 distance ranges, near, far and too-close. The NQC program has a few main tasks. They are:
1) To follow the wall and avoid obstacles without hitting anything using the DIRPD sensor.
2) If it gets stuck, a routine will get it out of the situation
3) If it reaches an area where there is no wall and a drop-off is present. Detect an avoid.