Downloads for some of my 3-D printing files

One of the things that's been very encouraging with this new show is how many kids are genuinely interested in the robot and the idea of possibly building their own robot. After the show is over, kids from older teens all the way to very young pre-readers want to hang out and talk about how the robot works, and how I built him.

Of course, RD-3D is not as complicated as most real robots since he's really more of a robot "actor," pretending to hear and respond while actually just delivering his "lines" on cue.

But he was still an ambitious project and something that any builder would have fun with and be proud of. So, I'm including links to the files on Tinkercad that I used to create RD-3D.

It's important to note that I started with a frame work from a toy made by 4M Kidz Labs, as I mentioned in a previous post. I used a soup can because they are about the same size as a soda can (what the toy was designed for), but the soup can is sturdier and I knew it would be a better casing.

However I needed more room inside than a single can would provide, so I designed the can connector. Here's the link to that if you want to go in and download it, tweak it to something else if you want to try to improve it, or just print it as it is.
https://www.tinkercad.com/things/hUll6GNWbIR

I also incorporated some forks and redesigned them to be even better than before. Here's the link to the file for the improved forks:
https://www.tinkercad.com/things/3WdUuQZdYye

Improving the Battery Life of RD-3D

A week or two ago I blogged about how Making involves a lot of trial and error. Lots of problems come up, work out a solutions, maybe it works, maybe not, back to the drawing board, keep researching, keep trying, keep feeling forward progress and keep hitting new road blocks.

One of the things that was frustrating was that my robot's 9 v. battery would die after only 4 shows or so. I would turn the robot off after each show, and even disconnected the battery each time. If a switch is left on, then I can understand how a battery would die rather quickly, even if the motors and LEDs are not going, the Arduino is still "thinking" and waiting for new code or new inputs to affect the current code. By completely disconnecting the battery I was ensuring that there was nothing that could drain the battery other than his actual performances, and they were much too short to drain a battery after 4 shows.

CLUE #1: His LEDs are still bright even when he can't move. Not surprising since lighting an LED uses nearly no electricity at all while powering a motor uses LOTS of electricity.

CLUE #2: When he was supposed to move you could hear the motor struggling, just unable to actually make the robot move (this is an important clue because it indicated that the battery still had enough power to affect the motor, just not quite enough, it seemed).

CLUE #3: When he would get to the part of his skit where he was supposed to "shake" he always had enough power to do that (this is the most important clue and what finally made me realize the source of the problem).

So him shaking is actually the motor going full blast forward for 1/10th of a second, then going backwards full blast for 1/10th of a second, over and over 17 times (for the record, I recently changed it to 25 times because it gets a good laugh and I thought he might have quite to quickly since 17 shakes is barely 3 seconds).

When I programmed RD-3D to walk I have him move at a slow pace because if he moves too quickly it is easier for him to fall over. So he would move at about 35% of maximum power.

MY THEORY (don't read this part yet if you want to try to figure out what YOU think the problem might have been, because I can tell you that my theory has been tested and demonstrated to be the source of the problem).

I felt like since the robot motor would drive him at FULL power, but not at 35% power then it might be that the battery was getting weak after 4 shows, but not dead. I decided to rewrite the code to have RD-3D move at a higher speed than 35%. Also, I felt like the laws of inertia might be at work a bit, too. I felt if I could jostle RD-3D into moving (like the start of one of his twitches) then the momentum might make him able to move with a lower powered speed.

In other words, I had him start at 100% for 1/4th of a second, then drop to 85% for 1/4th of a second, then drop to 70% for 1/4th of a second, then drop to 55% for 1/4th of a second, then drop to 40% for the last 1.8 seconds. The initial "blast off" is full power, but it is so short in duration that he doesn't actually jerk and you really can't even notice that he's moving faster for the first part of his trip.

So I rewrote the code, uploaded it to his little Arduino brain, and tested it out. I've been testing it for the past week or two using one of my "dead" batteries and that battery has now powered my little "astromech droid" through no fewer than 19 shows! That's 19 AFTER I thought the battery was too dead to work for the show.

Updates on RD-3D now that he's done a few shows

The one thing I've learned as I've really gotten into the Maker Movement is that rarely does anything work right the first time. You have to keep researching, learning, testing, and trying new things.

For example: the rubber bands that I use for tires on his tiny wheels. I had the hardest time gluing the rubber bands to the wheels. I tried all different kinds of glue, even rubber cement which is nearly perfect for gluing rubber. Nothing would work. But it turns out rubber bands are coated with a special powder that keeps them from sticking to anything, even glue and rubber cement. A quick rinse under the sink and presto, the rubber band tires can now be glued to the wheel!

Another problem I had was with the front forks. I designed them in TinkerCad using measurements of the button wheel I made with my calipers. I added a little "shelf" perpendicular to the forks that fit under the lower lip of the can to keep the forks steady.

Unfortunately I measured the width of the button in the CENTER and failed to account for the outer lip of the button which is a little bit fatter. No big deal. The button-wheel I measured was actually 2 buttons glued together, so I could still use a button, I just had to use a single button rather than the double I had wanted.

But then another problem arose. RD-3D started turning while he was moving. It was as if he were steering off-course. It seems that the little "shelf" I made didn't to as good a job as stabilizing the forks as I had wanted. So, I decided to go back and redesign the forks, making them wider (to hold a double-button wheel) AND to also improve the shelf so that it would stabilize with the can better. So I greatly increased the size of the shelf and also contoured it to the curve of the can which makes it nearly impossible for it to pivot around the screw like it had been doing. So far, so good.


But there is one more issue I've been dealing with. The 9 v. batteries I've been using seem to go dead after just 4 shows. There is NO REASON for them to die that quickly. I mean, they aren't DEAD-dead, just low enough that RD-3D can't move. His lights still turn on and blink quite brightly, and he has enough power to do his "shaking" thing (which turned out to be one of the funnier jokes in the show).

When he's supposed to move across the table, I can hear his motor struggling, but he doesn't actually move. I think I know what the problem is, and I'll report back on it whether I'm right or wrong.