Let's Make Robots!

Thin-Bot (Unlike any other robot I have built).

Roam the floor in a funky sort of way...

This robot abandons the previous (all very similar designs) robots I have and tries something different, and it works well!!! The motivating influence is a ZBasic ZX24su running compiled, multitasking Basic. It is quite a change from the C/C++ used with the Arduino and a nice change of pace. (Please. I know some of you hate Basic, but I grew up on it, and for me it is like an old, comfortable set of shoes.) The two front wheels are actually gears with clear (oxygen machine) tubing epoxied to them. Works great! This bot has a unique "fish tail" motion when it turns that really attracts attention. And it still manages to turn nicely. I have plastic "junk parts" laying around and a bunch of them went into the structure of this bot. Waste not, want not! Five AA rechargeable cells hung underneath the robot provide nice long run times with the low power the processor and the L293 motor controller use. Forward, reverse, speed its all there. I uses switches on both main power and the motors so I can work with the bot with the motors disabled.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

I now have a 3 color LED that indicates the "emotional level" of my bot. The level system is in decreasing number of points, the most points turns the green LED section on indicating it is "happy" and has not had to reverse. The next level down is blue indicating some displeasure with having to do some reversals. The last level is red or "angry" where the bot has done a LOT of reversing and isn't happy at all. Of course it can't remain angry and finally pops back up to the "happy" green level and the whole cycle starts again.

I really need to give mtriplett credit for getting me to think about this area of robotic science and while it doesn't help the bots ability to make decisions, it does somehow seem to make the bot act a little more "human" (that being a good thing or not...)

I tried something similar this in the past, but this versions implementation is greatly improved and works as planned.

 

Medicine cups work great for faces! I try to add a bit of "personality" to all my bots. After all, it is only human...

Great videos guys! Lots of really fascinating information. Now to just make use of some of it.

Sorry about the stopping of the "fishtailing". It was caused by slick wheels and the good old wheels work just fine (and the turning is now more "boring", but it sure works well.) Slick wheels do not a good robot make... I will NOT be putting those plastic tube wheels back on again!

Subsumption, neural-nets and so much else to try. Nobody ever said a really good autonomous robot was going to be easy to program...

Recomendations on a inexpensive, easy to program and use GPS unit???

Nice bot. I am curious to see the fishtailing. 

As for the tweaking; there is a nice (but long) video about closed loops, PID and other subjects, that explains many concepts that might help you to have te robot self-tweak the basic parameters. The more complex the behavior is harder to make the robot learn. You could read up  about neural nets. 

 

She is here at: http://letsmakerobots.com/node/29591

Quite a brillant girl I would say. MANY brilliant people hang out at LMR. It makes this one of the best "bot" sites on the web!

Notice the "standard" wheels and now there is an up-front microswitch that also triggers the "find a new route" routine.

Maxhirez, I will check that video out, thanks! I also agree with what you said and am wondering if a little, iexpensive GPS unit might go a long way in helping the robot out. Have to see if I can do that in ZBasic and then determine what to do with that data. Sounds like a LOT of fun to me! This version of ZBasic has been improved to include some OOP featurs so class structures are possible.

(I still love looking into neural-net design and if I am not right, a girl here did a really nice blog on that. I just can't remember who are where to find it.)  Of all the things I have lost, it is my memory I miss the most...

BTW: I also use PWM to control my bots motor speed using a L293 chip. That works well in ZBasic.

The "fishtailing" during turning was because those "special" wheels weren't worth crap! (Live and learn.) Rubber beats plastic any day for turning and substituting a set of real wheels. Some "sacrificed" from another robot. I only have two sets of real wheels. Now it turns much more "boring" like any other bot turns.

I have a friend that has better ability to film a bot in motion (mine blurs so bad it is hard to make out the bot!). Someday...

Question: (anyone please respond!) Programming one of my bots involves a LOT of "tweeking" run times, turn times, delay times and so on. Is there any way to set up code (psudocode would be great) so the robot can "adjust" these paramaters itself (maybe this is an area for neural nets?) My bots have HUGE memory spaces available (128k to 512k depending on the controller used). Once these parameters are optimal my bots "navigate" nicely.

I can "imagine" a bot you place on the floor (or ground/grass) and it gets "stuck" a few times at first, but quickly learns and soon can "pilot" itself out of almost any situation. NASA bots can do it but I am no NASA scientist.

 

 

You could set up your robots to "learn" after a fashion.  I don't know that you'd save any time in the end over tweaking though.  

This is one of those situations where Basic might not be the way to go.  In just imagining the process, I think having the ability to work with classes is going to be indispensable to a task like that.

In flowcharting for "machine learning" on the level that most of us work at I guess the question is "how do you reinforce the desired state without using a sensor of some kind that could more easily be used directly instead of as an input to the neural network?" For example, lets say you want to program a network to recognize when two motors in a differential drive are maximally synced.  One approach is to put encoders on the wheels the motors are attached to and to use those encoders to generate the "hidden" data set over the range of motor velocities through variations on the method of speed control (like PWM for most of our robots here.)  However, wouldn't it be easier/make more sense just to use the encoders as direct inputs to an alogorithm for "live" speed control?  I guess this assumes that the encoders can stay in the system full time, but still-you see what I'm saying.

Here's an interesting video on the subject.  It doesn't get into anything technical, but it's fun to watch:

 

 

I don't know what the resistance to Basic is. AxePad basic is as clean and beautiful as Python IMHO and the purists love that. I'd love to see some video of this in motion, Oldie-any chance of that? The fishtailing sounds neat!