Tubs1

Let's Make Robots Robots
1

My first robot is done (for now!) :)

It's based on the 'start here' robot, but I kept the darlington driver, did not use a servo, added speaker and led and wrote the code from scratch.

For the body I ended up using a small tupperware container from the dollar store. I needed something that would offer at least minimal protection from my two year old son. He's generally not violent with objects, but he is very curious.

The plastic was a bit of a pain to deal with. Cracks very easily (it did when I poked the hole for the LED). However, I'm not terribly concerned. The goal wasn't for Tubs to look perfect, but rather it was for him to be assembled and functional.

All the connections are done using leader pins and the construction is done with double sided tape. Since this is the first robot I fully expect to change it, reconfigure and reuse parts as I go along. For the next bot I'll probably do something a bit more permanent for rubustness' sake.

Tubs roams around occasionally making little beeps and chirps and avoids obstacles. When he's close to something he turns until the IR field is clear and when he's much too close to something he backs up and beeps like a truck. Most of the 'features' were added keeping my son in mind, who is currently obsessed by trucks. Flashing lights are huge too, so of course Tubs had to have his own little flashing LED. Thankfully it was an instant hit. My son loved it and did not want me to turn it off. Ever.

I wrote the code without using the 'pause' command. Tracking states takes up more variables and debugging time, but I think it opens up the possibility for more interesting behavior. It also seems more 'natural' when sound, lights and movement can happen independently and simultanously.

I don't think Tubs is awesome, but I had a lot of fun learning while making him. I think thanks to him I am forever hooked to robotics.

I'm hoping to add pictures and videos tomorrow :)

 

 

 

Navigates around using IR, beeps, plays noises, flashes the led

  • Actuators / output devices: 2 geared motors
  • Control method: autonomous
  • CPU: Picaxe 28X
  • Power source: 4.5V (3AA)
  • Programming language: Basic
  • Sensors / input devices: Sharp IR
  • Target environment: smooth surfaces
This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/tubs1
2

Looks great!

Looks great! Will be waiting on video! :slight_smile:

I often have problems with making holes in plastic too. What I do is: Heat up a screwdriver on fire and melt my way through plastic with it. Or use a drill :slight_smile:

3

Those motors and wheels look

Those motors and wheels look awfully familiar =3

It’s a nice little bot you’ve got there, seems like you’re picking this all up quickly. If you wanted to salvage the PICAXE board but leave Tubs’ basic functions intact you could replace the board with a simple analog controller for only a few dollars. With an inverter IC and an H-bridge motor driver you can accomplish quite a lot for a roaming and obstacle avoiding bot.

4

no pause?

Okay, well I’ll bite:

how did you write the code with no pause command? It all sounds a bit impausible to me.

(no, seriously, I just wanted to make a bad pun)

So how do you time (for e.g.) the backup time.

Is there anything wrong with using the pause command that I don’t know about??

5

Before Slimy gets a chance

Before Slimy gets a chance to answer I wanna take a stab:

• The entire program is one big loop.
• When a condition such as reverse is set, a counter is set equal to a preset value.
• Each iteration of the program loop causes the counter to decrement; every other action the μC performs takes up a little bit of time, so the rest of the loop contents are effectively a delay.
• When the counter is decreased to zero, the condition flag is reset to the default.

There’s nothing really wrong with the pause/delay command, or NOP, or wait() or any equivalent, except for the fact that the processor is just wasting time whenever it executes this. Some parts of the μC keep running during a pause anyway, and there are times when it really doesn’t matter if you waste processor cycles or not. However, if you’re running a very intensive routine you might not be able to afford wasted cycles, in which case a pause is a deadly sin.

6

Yes that’s correct. You

Yes that’s correct. You basically use variables to track the state (ie what is it doing now) and a counter to track time or repetitions. Nothing wrong with ‘pause’ per se, but I wasn’t concerned with wasting processing power. What I really dislike about it is that when you pause, nothing else can happen. It’s a complete stall.

For example, if you are setting motor pins and pausing to turn or backup for 1 second, you can’t flash your led’s or read IR or do anything else during the pause period. It’s fine for very short pauses, but otherwise not being able to do things concurrently seems too limiting to me.

 

7

Nice that I am not the only
Nice that I am not the only person with robot made of lunchbox (smart lunchbox, isn’t it?)… Good work :slight_smile:

8

Heheh yep I like lunchboxes.
Heheh yep I like lunchboxes. I think small toy robots should look funny. Next I’d like to do a moving trashcan 8)