TriBot Radar, Radar program for the TriBot Options

[Krystman]

Hello everybody,

this is my first post and my first NXT project. I got my NXT just recently and I think it is excellent. I have built the TriBot and I'm stuck with it writing various programs for it. This is the first bigger thing that came out. I have rewritten the program from this thread:
http://forums.nxtasy.org/index.php?showtop...04&hl=radar

So now it is custom made for a mundane TriBot. It works pretty well, look at the pictures:



Here is a YouTube video:
http://www.youtube.com/watch?v=w-PNsW7b3CY

You can see the larger pictures and dowload the software on my mini-website:
http://kisd.de/~krystian/nxt/

There are still minor errors. With every sensor sweep, my TriBot rotates a tiny bit more then 360° (see video). I have no Idea how to solve it without changing the hardware. Also, I have the impression that the software exhibits some juicy rounding errors but I'm not sure. It might be also, the unprecise sensor.
I would like to find out if the sotware works with other TriBots as well. It is possible that minor variations in the structure of the robot might have some impact on the turning rate.

So now we have a TriBot that can see the environment. What now? Does anybody have any cool ideas how to develop this thing further?

[Brian Davis]

This is the first bigger thing that came out.

Nicely done! This was the second trig-based program I wrote for JennToo, and it's a favorite (I'm told) with a lot of educational folks (althought I never thought to having zooming; I'll have to see how you did that). I'll have to get my program out there sometime soon (with my trig blocks - I've got a set including sin, cos, tan, as well as asin, acos, and atan... those arc functions were really a pain).

--
Brian Davis

[Wander]

There are still minor errors. With every sensor sweep, my TriBot rotates a tiny bit more then 360° (see video). I have no Idea how to solve it without changing the hardware. Also, I have the impression that the software exhibits some juicy rounding errors but I'm not sure. It might be also, the unprecise sensor.
I would like to find out if the sotware works with other TriBots as well. It is possible that minor variations in the structure of the robot might have some impact on the turning rate.

In my experience, the rotation sensors are pretty accurate, there are a few possible reasons for not turning an exact 360:
- Programming errors, like starting from 0 and stopping at 36 with 10 degree steps, giving a total of a 370 degree turn
- overshoot/slippage, to reduce this, lower the motor power level, so that it turns slower and thus slips/overshoots less.
- Wheels spaced wider/close apart. Is your wheels are further apart, you bot will turn less for each rotation of the wheel.
- Firmware errors: The NXT-G firmware has (supposedly) less accurate firmware than RobotC has. See posts from Dick Swan for demonstrations of this.

So now we have a TriBot that can see the environment. What now? Does anybody have any cool ideas how to develop this thing further?

- Make a robot that goes through the smallest opening (making for a robot that probably goes to hide in the closet or some other confined spaces)
- Make a robot that searches for small, round objects like balls or table legs. You would have to make several measurements to be sure that it is a small, round object and not a rectangular object. That would make a great demo if it would be able to find a ball (or bottle of beer for bonus points) in a room and transport it somewhere else (like "The brightest spot in the room" using the light sensor)

[Krystman]

In my experience, the rotation sensors are pretty accurate, there are a few possible reasons for not turning an exact 360:
- Programming errors, like starting from 0 and stopping at 36 with 10 degree steps, giving a total of a 370 degree turn

Well that's a problem. If the rotation sensors would mesure how much the ROBOT turns, I would have no problems. But inestead, they mesure how much the WHEELS turn. Translating that into robot rotation is a very fuzzy thing.
By trial and error, I found out that if I rotate the Wheels by 11° on each step, I need 69 steps to do a full circle but it is a tiny bit more then 360°. If I use 10° instead I have to do a lot more then 69 steps and then it still wouldn't be exactly 360°. There is no wheel rotation that translates neatly into robot rotation, so right now I rotate the Robot 11°x69 Times and I simply assumae that each step is 5,217° for the robot.

I guess I could try to rotate in the in last step a bit less then 11° to conter this effect. Hm...

- Wheels spaced wider/close apart. Is your wheels are further apart, you bot will turn less for each rotation of the wheel.

Oh, yes of course! Ill try that, thanks. I wonder how big the impact will be.

- Make a robot that goes through the smallest opening (making for a robot that probably goes to hide in the closet or some other confined spaces)
- Make a robot that searches for small, round objects like balls or table legs. You would have to make several measurements to be sure that it is a small, round object and not a rectangular object. That would make a great demo if it would be able to find a ball (or bottle of beer for bonus points) in a room and transport it somewhere else (like "The brightest spot in the room" using the light sensor)

Hmm, I found out that the UV Sensor is not good at detecting shapes. There are two reasons for that. First, it seem like the sound coming out of the sensor isn't like a tight beam, more like wide and fuzzy wave. I tried scanning a few drawing markers staning upright about 7 cm next to each other. Instead of getting single points on the radar for each marker, the radar registered a wall because there was always something nearby that would reflect the soundwave.
The second reason is that the soundwave is deflected if the surface of the scanned object is facing too much away from the scanner. The same Effect is used in the stealth plane F-117A ( http://en.wikipedia.org/wiki/F-117A ). So the edges of the round object are invisible for the sensor. You can see that effect if you look closely at the result from the corner scan in the video. If you follow the left wall, at some point, the line breaks away to the lower left corner because the sensor looses the echo signal.

I might post some example of those findings...

[Brian Davis]

Firmware errors: The NXT-G firmware has (supposedly) less accurate firmware than RobotC has. See posts from Dick Swan for demonstrations of this.

I'm not sure what you mean here. RobotC has a lot of advantages, but I don't know of any inaccuracies on the encoders under the standard firmware. PID synchronization is rougher under the standard firmware than under the RobotC firmware, but for this you can again correct by spreading the wheels out, increasing the wheelbase to both slow the turn and reduce and angular pointing errors at the same time.

If the rotation sensors would mesure how much the ROBOT turns, I would have no problems. But inestead, they mesure how much the WHEELS turn. Translating that into robot rotation is a very fuzzy thing.

Two possible solutions. First, but the whole thing on a driven turntable on top of the robot. Of course, to be able to point the chassis in the direction indicated by the turntable-mounted US sensor you still need to convert wheel rotations into a heading change. So going back to converting between the heading change and the encoder readings, you might need to use higher precision numbers... the same way you can make trig blocks that put out "fractional" values by scaling them up.

I found out that the UV Sensor is not good at detecting shapes.

Remember, all the US sensor does is detect an echo, and times that echo. That's it. That's a significant limitation, and one to keep in mind on everything you attempt with it. For instance, you can't "beam" sound, so the outgoing pulse will spread... and likewise the returning sound pulse will spread. And for curved objects, very little sound energy is reflected back to the receiver.

If you want an object that is easy to detect, google "corner cube reflector". I made one of these out of 1x8 LEGO bricks, and even through small (beer can sized), it was easily detectable at 1 meter.

--
Brian Davis

[Jaguar]

First, but the whole thing on a driven turntable on top of the robot.

This would require some sort of fancy connector for the US sensor to allow it to continualy rotate without twisting up the cable, or it would require it to rotate a few times in one direction, and then change and rotate in the other direction.

[Wander]

I'm not sure what you mean here. [.....]

PID synchronization is rougher under the standard firmware than under the RobotC firmware,

That's what I meant.

...put the whole thing on a driven turntable on top of the robot.

I'd say, if you want to have accurate 360 turns, get yourself a compass sensor
http://hitechnic.com/index.html?lang=en-us...target=d17.html

[synapticbackfire]

With the truning issue...could this be the caster issue again?
I build my tribot and truned it in to a spirograph maker. I encounterd a lot of slight slips and sticks. I was able to remedy some of it by putting tires on the 2 pullys we use as a the caster, my second breakthough was already recomended, lower power when doing your sweeps, I use about 65% power on the spirobot.

[Brian Davis]

or it would require it to rotate a few times in one direction, and then change and rotate in the other direction.

Exactly. Rotate 360° CW, taking measurements all along the way, and then rotate back 360°, again taking readings all the way. By staggering the places where the measurements are made, you can produce a "superresolution" image since you have twice the number of measurements.

There's several other tricks this would allow. For instance by using the "radar" style measurements, you can not only sense the presence of a wall, but what angle the robot is to it. Now, turn the US sensor to the side and perform a parallel drvie to the wall, using the US sensor to keep the "standoff distance" exactly what you want it to be. You could use this trick to accurately determine the edge of the wall as well (since you know you are moving parallel to it... :-).

More? There's lots more...

--
Brian Davis

[Ian]

For instance, you can't "beam" sound, so the outgoing pulse will spread...

Hypersonic Sound.

[Krystman]

With the truning issue...could this be the caster issue again?
I build my tribot and truned it in to a spirograph maker. I encounterd a lot of slight slips and sticks. I was able to remedy some of it by putting tires on the 2 pullys we use as a the caster, my second breakthough was already recomended, lower power when doing your sweeps, I use about 65% power on the spirobot.

I use 50% for the sensor sweep and I don't think the caster is the problem here. What kind of problems did you have with the spriograph maker exactly and why did the tire help? Spirograph maker sounds exciting anyway, do you have pictures?

Two possible solutions. First, but the whole thing on a driven turntable on top of the robot. Of course, to be able to point the chassis in the direction indicated by the turntable-mounted US sensor you still need to convert wheel rotations into a heading change. So going back to converting between the heading change and the encoder readings, you might need to use higher precision numbers... the same way you can make trig blocks that put out "fractional" values by scaling them up.

Well, I plan on building a turet-mounted sensor somtime in the future but I will buld the other robots from the set first to learn how all those new, bizzare bricks work. Lego has changed since I was a kid.
The idea with "friactional" values is great! I didn't think of it first because you can't feed that into the motors but of course - I could use a "fractional" variable to calculate how much the motor is supposed to have turned since the beginning of the sweep and substract from that the actual rotation sensor redout to determine the number of degrees for the next step! Great!

So I did some tests and it turns out that my TriBot does a 360° when the motors do 725° both. I'm a bit concerned because I looked closesly now and it seems like the robots drifts away from its starting position during the sweep. Also, the motors are not in-sync. One motor finishes turning noticeably sooner then the other. I tried putting the two motor commands paralell but that didn't help. I don't think it has a big impact on the readout but still...

But that got me thinking: I could get a better robot° / motor° ratio by using just one wheel for the turn. The other wheel could just stand still. Of course, then the sensor would move during the turn but I could fix that by some programming...

[Krystman]

Hypersonic Sound.

I heard about that (no pun intended). Here some technical explenantion
http://en.wikipedia.org/wiki/Directional_Sound

[Brian Davis]

Hypersonic Sound.

Well, actually... no. "Hypersonic sound" is absolutely normal sound, it's just a system that puts out a pattern of ultrasonics waves that through interferance effects produce an audible sound at a specific location. The ultrasound (high-frequency sound) spread just like any other sound does, and the only reason the audible frequencies don't seem to is that they are being produced at a location in space. It's a neat system: you can stand between the speaker array and the volume that the sound is set to produced in, and it seems really counterintuitive. But it's no more surprising in some ways than a hologram, or phased array radar systems.

Using a phased array system (multiple sound sources with their phases very carefuly synchronized) you could get a beam that doesn't seem to spread, much. But to do that, you need an array that approximates a single emmitter much larger than a wavelength. It's that diffraction limit that you have trouble getting around, and while using ultrasonic frequencies makes the situation better, the problem exists unless you want to go up to bigger emitters and/or arrays (with, of course, bigger sensors).

Even lasers spread. That old "parallel light beams" stuff is something that's very hard to remove from a students head once it's in there.

--
Brian Davis

[Tony Buser]

This would require some sort of fancy connector for the US sensor to allow it to continualy rotate without twisting up the cable, or it would require it to rotate a few times in one direction, and then change and rotate in the other direction.

I wanted to mount the US sensor on a turntable and was thinking about this problem... then I found this website talking about a rotating electrical connection using a telephone cord untangler:

http://www.visi.com/~dc/slipring/index.htm

[synapticbackfire]

I use 50% for the sensor sweep and I don't think the caster is the problem here. What kind of problems did you have with the spriograph maker exactly and why did the tire help? Spirograph maker sounds exciting anyway, do you have pictures?
...

My issues started with the fact that i was using 100% power, and almsot constantly truning. My Caster issue is that when i go in to reverse(To offset my circles) the bot did not end up exactaly where i wanted it(the angle of the caster was not consistantly the same everytime i wanted to move for my next circle). Then the issue of no tires in the NXT kit and using pullys as a wheel. when I added a set of rubber "Tires" the caster griped better to the paper the bot travled over.

As for Pictures, none on me, but I may put it back to gater to take some, it was just a tribot, more of a exorsise in programing than in buildnig, but I may have to get some vids and pics of it in action. Not nearly as cool as your radar project, Kudos to you!

[synapticbackfire]

I use 50% for the sensor sweep and I don't think the caster is the problem here. What kind of problems did you have with the spriograph maker exactly and why did the tire help? Spirograph maker sounds exciting anyway, do you have pictures?
...

My issues started with the fact that i was using 100% power, and almsot constantly truning. My Caster issue is that when i go in to reverse(To offset my circles) the bot did not end up exactaly where i wanted it(the angle of the caster was not consistantly the same everytime i wanted to move for my next circle). Then the issue of no tires in the NXT kit and using pullys as a wheel. when I added a set of rubber "Tires" the caster griped better to the paper the bot travled over.

As for Pictures, none on me, but I may put it back to gater to take some, it was just a tribot, more of a exorsise in programing than in buildnig, but I may have to get some vids and pics of it in action. Not nearly as cool as your radar project, Kudos to you!

[Mick]

There's only one thing I can say... GOOD JOB!!!

Mick

[yahoo.com]

about the tribot radar:

1) is it possible to make it such that the tribot can be used to scan for changes in the proxmity of objects?

[Ian]

about the tribot radar:

1) is it possible to make it such that the tribot can be used to scan for changes in the proxmity of objects?

Aren't you a spider?

[Equilibrium]

Spiders can ask questions too... Maybe it wanted more info about the radar to add to its search. hehe