TRIppy The Tri Wheeler

Here is my latest little time killer, TRIppy the Tri Wheeler.

Trippy is based on a tri wheel design, with the point of this build being speed. As a matter of fact, i accomplished that almost too well. He's faster than his sensors it seems to me, although I am still playing with the code. Right now, when he takes off on the roaming code, he almost slams into things, even with the safe distance set at about 30 inches or so.

Here are a couple of pictures of him:

This is not a finished design by any means, as I plan on building on him for a little while to come. The body is actually a foam board material that I used just for getting the basic shapes i wanted. The "tape" is not really tape, but a velcro type material, I am constantly in and out of the inside, and this makes it much easier to get in and out.

The small cutout is a sharp distance sensor that gives great readings for obstacles that are within about 5 inches or so. Not very usefull on a bot that is this fast, and will probably be swapped for some longer range sensors on the next build.

The head, well, that seems to find its way into just about every project that I build.. I have a ping ultrasonic unit, a ir detector, and 6 leds already mounted, and i just seem to reuse it as often as I can. I do actually have drawings for a head that looks a little better, but i haven't had the time to work on actually cutting and putting together.

Here's a view from the top. You can't really tell it, but both of the "front" wheels have a little motion in them to allow them to sweep backwards just a little when in forward motion, that helps get a little better traction.

Here's a view of the electronics.. pretty simple, two l293d hbridges, running three motors, two sharp ir distance sensors, servo connection, ping connection. Custom Lego sensor brackets.. :)

I had actually used my own motor controller that I designed in the first attempts at this robot, but i managed to fry the hbridge in that board, and I haven't built another yet. Will order parts for that soon, and build at least two next time.

I am attaching three files here, one is the sketch to roam and ping, the other two are an xbee wireless remote code, and also the wireless receiver code to make an xbee remote controlled robot. (you can see one of the xbee shields above, but it's not used in the roaming code, and there is no xbee in the shield at that time)

Hope you enjoy my little three wheeler. Hopefully i will find access to a video recorder that works, and can post some video of this thing scooting around my house.

 

two modes, roaming with ping, and xbee remote control

  • Actuators / output devices: 3 dc motors scounged from a junk box
  • Control method: Autonomous and optional wireless xbee control
  • CPU: Arduino
  • Power source: 9.6 volt RC battery
  • Programming language: Arduino ide
  • Sensors / input devices: Ping ultrasonic, Sharp Ir detectors, Xbee wireless
  • Target environment: indoor

This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/trippy-the-tri-wheeler

3 wheels good - 4 wheels bad…

I really like the omni-directional three-wheel concept, and I’m trying to develop my own too - all in good time.

Is this guy omni-directional? it looks like it could be (if it’s not, my entire following question is utterly moot…)

One matter I’m trying to figure out is the best way to avoid things - my present solution is just to have all-round bumpers that activate one of switches - depending on which has been activated… etc. etc.

It would be pricy to add three ping sensors to your robot, so how do you accomplish obstacle detection when it’s moving sideways, or backwards?

 

I haven’t tackled the

I haven’t tackled the omnidirection yet, although it is coming. Right now it drives just as any other two wheeler would except that when it turns, it has all three motors turn. I do plan on making it a true omnidirectional, just haven’t sorted out the speeds, etc. I saw that there is an ongoing thread here about just that.

As for obstacle avoidance, i am using two sharp GP2Y0D810Z0F from pololu =http://www.pololu.com/catalog/product/1134 that work really well. These aren’t the normal sharp detectors, these ones give a simple high or low. If it’s low, then there is an obstacle detected, if it’s high then all is good.

As for video, I really really wish I could get some up here. I have two bots that i really really want to get in your “video” contest. My camcorder got knocked off a table, and went into several pieces, needless to say, none of the pieces work. I could really use some of your “robot junk” to continue my own junky adventures in robotics.

If i can steal, borrow, rent, or otherwise come up on a camcorder in the next day or two, i will get some video posted.

Omni platform
If you search info about the steering you can go to http://www.societyofrobots.com . the admin there made a platform just like you robot. You may find a solution for the steering problem there.

hmmm

I didn’t search through that link very well, but did not find a link that seemed to be of much value to me.

I did however find a conversation here about three wheels and "real"holomonic motion here.

My biggest issue is that I am not a Mathmatics major, nor even an engineer. I am a simple web designer. Although I understand some of the basic concepts that were brought up in that thread, I am afraid that the math is above my head. I understand the principal, but in actually translating that to physical speeds and motions, I got lost.

I understood one thing that I took away from that conversation, and that was the 4:7 ratio in speed of rotation.

I don’t have encoders on the wheels on this bot, so this may have become a moot point anyway. Without encoders, I don’t say how i can positively say that any kind of ratio on speed is happening.

I will attempt to continue this little expirement to see what i can do without having the encoders.

As a bonus, I did get access to a camcorder, and will attempt to post some videos of the bot in his roam mode, xbee control, and also a couple of other bots i have been working on.

 

nothing beats real life.

One of the problem with too much mathematics is that if you make an error (or somone else has, and you’ve not spotted it), is that it gets really frustrating, real fast.

In this case, I see no reason why you can’t simply dispense with the labourious mathematics completely, and go ahead with your own experimentation and use trial and error to find out what is best. Aside from the obvious movements; spinning clockwise and a/clockwise, then moving each in the six directions that each permutation of different wheel rotation patterns gives you.

for example, for three motors arranged clockwise, 1 - 2 - 3, having them all full on in (for example) +ve direction will cause clockwise rotation, and having them full on in -ve direction will cause a/clockwise rotation… and so on, depending on the permutations of motor directions;

motor

1 2 3 direction
+ + + cw rotation
- - - a/cw rotation
0 + - direction away from motor 1
0 - + direction towards motor 1
+ 0 - direction away from motor 2
- 0 + direction towards motor 2

and so on…

 

Forget the maths, it’s not important here for now, six directions is ample!

 

 

 

Now see that makes a lot

Now see that makes a lot more sense to me than all the mathmatics. I can understand if i was actually plotting navigation around a set course. But, for my own personal use, roaming around without bumping into things, i agree with you totally.

Thanks for the insite. That makes so much more sense.