JennToo Radar Options

[Krystman]

Hello everybody!

It's been a ling time since my last post but I've got something new. Well, a bit at least. It's a radar program, similar to my previous Tribot Radar
http://forums.nxtasy.org/index.php?showtopic=458

This time, it's made for Brian Davis' JennToo robot which I found quite cute when compared to the clunky Tribot. I optimized the code a bit and came up with a different way to perform the 360° sweep. The scanning goes now twice as fast while the resolution is the same. The program is also easier to mess around with becaue I packaged everything into custom blocks.



Check out my mini-website here:
http://kisd.de/~krystian/nxt/

Or download the source code (NXT-G) directly:
http://kisd.de/~krystian/nxt/radar_jenntoo.zip

Also, you might want to check out the YouTube video. I did some tests to test the limits of the US sensor... plus I used some fancy visualisation techniques ;-)
http://www.youtube.com/watch?v=XLXOrxLfNFo

And one more thing: I have this very strange error. Maybe someone can help me with this one. I save the scan results in a file. Every result is just a number. I found out that sometimes random zeores are being inserted in-between the real results. When I download the file on my computer, I can see a column of numbers and somtimes, there is a space behind one of those numbers which presumably is being interpreted as a zero when the file is processed in my NXT program. Where do these zeroes come from?! Did anybody have a similar problem?

[Mick]

Hello everybody!

It's been a ling time since my last post but I've got something new. Well, a bit at least. It's a radar program, similar to my previous Tribot Radar
http://forums.nxtasy.org/index.php?showtopic=458

This time, it's made for Brian Davis' JennToo robot which I found quite cute when compared to the clunky Tribot. I optimized the code a bit and came up with a different way to perform the 360° sweep. The scanning goes now twice as fast while the resolution is the same. The program is also easier to mess around with becaue I packaged everything into custom blocks.



Check out my mini-website here:
http://kisd.de/~krystian/nxt/

Or download the source code (NXT-G) directly:
http://kisd.de/~krystian/nxt/radar_jenntoo.zip

Also, you might want to check out the YouTube video. I did some tests to test the limits of the US sensor... plus I used some fancy visualisation techniques ;-)
http://www.youtube.com/watch?v=XLXOrxLfNFo

And one more thing: I have this very strange error. Maybe someone can help me with this one. I save the scan results in a file. Every result is just a number. I found out that sometimes random zeores are being inserted in-between the real results. When I download the file on my computer, I can see a column of numbers and somtimes, there is a space behind one of those numbers which presumably is being interpreted as a zero when the file is processed in my NXT program. Where do these zeroes come from?! Did anybody have a similar problem?

I'm a horrible programer so I can't help you. Well, good project even though I think you should do some harder building projects more than programming projects.

Mick

[Rob Torok]

That's a great demonstration of a very neat project.

A couple of questions about the video...

1. Did you somehow get a screen dump from the NXT screen, or did you recreate the radar sweep image on a computer using the data the had been collected?

2. How the heck did you get overlay of the radar sweep in synch with the video?!? Wow!!

Rob

[Krystman]

Thanks for the Feedback!

The camera tracking I did with a program called PFHoe by The Pixel Farm. You can download a demo version here:
http://www.pfhoe.com

I have also uploaded a short video showing how such an effect is achieved here:
http://www.youtube.com/watch?v=fDlTd5pWtvU

I got a screen grab of the NXT screen by simpy taking a photo of it.

[Brian Davis]

This time, it's made for Brian Davis' JennToo robot which I found quite cute when compared to the clunky Tribot.

I'm glad you liked it... even better, since I have one built right next to me . Seriously, this was a great project the first time around, and I look forward to digging in and seeing how you increased the resolution/speed.

you might want to check out the YouTube video.

Great! Except I almost died when you decided to "microwave" poor little JennToo! I've got to play around with this some more. And I really like the visualization overlay. I would have no idea how to do that, but it's a fantastic way to show exactly what's going on. There's a lot of "eye candy" that ends up in videos (I try not to be guilty of that, but I'm not sure I always succeed) - this is not, it's using the media effect exatly the way it was intended.

I have this very strange error... sometimes random zeores are being inserted in-between the real results (when writing files)

Rats. I was kind of hoping that this was just a quirk I'd not resolved in my own code. Yes, I've seen this, and haven't resolved it as yet. It seems that when writing to large files, occassionally an extra carriage return or its equivilent seems to be injected into the stream being written. I *think* this is due to the pause associated with writing a block of FLASH, but I'm not sure (it's tough to track down from NXT-G... John Hansen, have you seen anything similar under NXC or NBC?). For most of my purposes, it's not a big problem, as I'm spooling data to a file as fast as possible (datalogging), in order to pull it off the NXT later for analysis by hand: I can just snip out the offending "zeros". But for your application, that's not so easy. You could still detect these glitches by using your own "start record" code, so that the program reading the files could determine of a particular record was corrupted... but I agree this is a far less then optimal solution.

Upshot? I fear this is a low-level problem with the way the FW writes to FLASH, but I'm not sure; anyone?

--
Brian Davis

[Rob Torok]

Now, THAT is going the extra mile! Gratitude and respect to you!

I got a screen grab of the NXT screen by simpy taking a photo of it.

Ha! That just goes to show that the simplest things are often the best!

Rob

[Krystman]

Thank you for the positive feedback!

There's a lot of "eye candy" that ends up in videos (I try not to be guilty of that, but I'm not sure I always succeed) - this is not, it's using the media effect exatly the way it was intended.

This is one of the best compliments I have recieved. In fact, it was my intension to use that kind of technology in a scenario where it has a reasonable purpose. It is very rewarding when the thoughts you put into a project are being recieved at the other end. Thank you

Rats. I was kind of hoping that this was just a quirk I'd not resolved in my own code. Yes, I've seen this, and haven't resolved it as yet.

Haha, funny. I thought the same when I stubled across it. I was worried that my NXT Brickt might be broken or something.
But seriously, I have noticed that you can set the size of a file when you open it. There is no text field for that value but there is a data input socket on the brick. I haven't touched that yet, did you? I thought that maybe it could solve the problem. But I have no idea what value to put into that socket. What unit would that be anyway? Bytes? How many bytes are required for a number?

[Brian Davis]

I have noticed that you can set the size of a file when you open it.

Yes. I've not played around with that as yet, but I suspect that can be used to set the inital size (in bytes) of the file to be written. This may make some things go quicker at some points in the file writing process, but i'm not sure if it can help with the mysterious carriage return charecters that seem to be stuck in there on rare occassions.

What unit would that be anyway? Bytes? How many bytes are required for a number?

Actually, everything that NXT-G stores in a file (numbers or text) is, in fact, text - a series of charecters. You can even mix and match within a file, and by being careful with how you read things out, you can use this to your advantage (comments in "number" files, for instance).

--
Brian Davis

[Einar]

I wanted to try your program and built the JennyToo radar bot. I have some problems compiling the program. It seems to be something wrong with the "rotate BC" block. The sub block in this file seems to be missing. I can't figure out what kind of block the sub block is, and where I can find it.

I'm somewhat of a newbie to the NXT software.


Appreciate any help you can give me!

Thanks
Einar Meland,
Norway

[Krystman]

I wanted to try your program and built the JennyToo radar bot. I have some problems compiling the program. It seems to be something wrong with the "rotate BC" block. The sub block in this file seems to be missing. I can't figure out what kind of block the sub block is, and where I can find it.

I'm somewhat of a newbie to the NXT software.
Appreciate any help you can give me!

The "rotate BC" custom Brick is in the "Custom Bricks" sub-folder. You need to copy it in your local custom Bricks Folder. Read "readme.txt" for more Details.

Oh, and you also need the most recent NXT Software updates, especially the Dynamic Block Update:
http://mindstorms.lego.com/support/updates...04&nxtswid=

[monkian]

Great work, Krystman. It works well for me. The obvious next step to me is to have it do the radar scan and then move through a gap that's big enough. Have you tried this? It should be able to explore very effectively.

I'll try it myself when I can find the time. I imagine this to be fairly simple to build on top of your program. Ultimately perhaps it can create a map of the environment by combining scans from different places.

[Andy]

I'll try it myself when I can find the time. I imagine this to be fairly simple to build on top of your program. Ultimately perhaps it can create a map of the environment by combining scans from different places.

If you make a program that makes a map from different scans in different places, upload it at NXTLOG or here at NXTasy (either at the Repository or in a post/topic in the forums) or simply just send it to me in a e-mail (just check my profile to find my e-mail adress).

Andy

[Krystman]

Great work, Krystman. It works well for me. The obvious next step to me is to have it do the radar scan and then move through a gap that's big enough. Have you tried this? It should be able to explore very effectively.

I'll try it myself when I can find the time. I imagine this to be fairly simple to build on top of your program. Ultimately perhaps it can create a map of the environment by combining scans from different places.

Exactly my thinking! However, I think it would be wise to bild a special Robot for this kind of task. It is impossible to translate robot orientation reliably into motor commands with this kind of Robot. With both, JennToo and Tribot I still end up with about 1° of error after every 360° sweep. It sounds like not much but you when let the robot go in that direction on for a few meters, that 1° makes a big difference.

[Golem]

Do you have a compass sensor? I would've used a compass to get reliable orientation starting point at each scan.

[Krystman]

Do you have a compass sensor? I would've used a compass to get reliable orientation starting point at each scan.

That's a good idea. However, I have no such sensor..
Besides, where would be the challenge in that ;-)

[Andy]

That's a good idea. However, I have no such sensor..
Besides, where would be the challenge in that ;-)

Good point!! I am thinking to buy a HiTechnic compass sensor (and a tilt sensor when avilable) when I get enough money.

Andy

[Brian Davis]

With both, JennToo and Tribot I still end up with about 1° of error after every 360° sweep.

I agree that 1° can add up, but you are now entering the land of diminishing returns. There are two problems with JennToo (for instance) on this. First, even though I tried to minimize "caster steer" in the design, there will always be some... unless you eliminate the caster offset altogether. This is a great advantage of the ball casters (I've got a couple examples in the Repository, CADed up by Guy Ziv, but the original idea rests with Philo and Steve Hassenplug). they are essentially zero-offset casters, so can completely eliminate caster steer. Note you can minimize it a little better in JennToo by making the platform over the caster smoother (using a 1x3 studless beam coupled with a 3L perpendicular axle joiner work very well).

The other problem (if you are looking for that last degree of accuracy) is you are right down near the limits of the encoders - remember, they can only report the motor position to 1 degree, no matter what else you do (and honestly the SW sometimes fudges that a little more), and in additon there is some slope in the geartrain. In order to translate that that encoder accuracy to the best possible pointing accuracy for the platform, you could have those wheels geared slower (so that 1° on the encoder is just a fraction of a degree in wheel angle), but then there's possible more slop in the extended geartrain you've created. Another solution is to simple move the wheels further apart. Now one degree of rotation on a wheel will lead to a certain distance of wheel travel, and with those wheels further apart that corresponds to a smaller angular change in the platform (to put it another way, make the wheelbase larger, you also make the turning radius of a wheel larger, so you have a higher resolution for the body angle of the platform).

Note that this is exactly what I tried not to do with JennToo - I wanted it to have as little mechanical slope as possible (and it succeeds, I think), but I also wanted a very small robot (for portability, simplicity, and stability), resulting in a very small wheelbase (almost as small as it can get; you could move the motors one stud closer). So while JennToo is great in some respects, it is actually not ideal for maximum pointing accuracy of the platform, which it seems is the next thing you're aimming at. Honestly, while you may see it as "cheating", the compass sensor might be a reasonable way to go, although again this will only get you to about the level you're at now: 1° or thereabouts. This is why "dead reckoning" is often known as "DEAD reckoning" - errors accumulate, until if you are not extremely careful, they overwhelm you.

--
Brian Davis

[Krystman]

...Another solution is to simple move the wheels further apart...

An even simpler solution would be to use only one motor to turn JennToo. Instead of rotating both wheels in opposite directions, you rotate just one wheel. That should double the wheelbase. The problem is that the center of the robot is moving when you change directions but I think you could use smart programming to solve that.

The whole setup has another source of inaccuracies: the wheels don't stick perfectly to the ground. If you look closely you will see that there is a cosiderable ammount of slip. This causes the robot to even drift away from its initial position a bit.

Here is a different approach to a robot: instead of using the rubber wheels to change direction add extendable legs which are attached to a turntable. Every time the robot needs to change heading, it extends the legs and lifts the whole robot with the wheels off the ground. Then use the turntable to change the heading and retract the legs. The robot will end up facing exactly in the direction you need..at least as exact as a turntable can be.

I cannot use the compass sensor since I live in Germany and credit cards are not a common means of payment here. Hence, I have to credit card and cannot pay for the compass sensor.

[Golem]

I cannot use the compass sensor since I live in Germany and credit cards are not a common means of payment here. Hence, I have to credit card and cannot pay for the compass sensor.

HiTechnic accepts payments via PayPal. I bought 2 compass sensors via PayPal.

[Einar]

Oh, and you also need the most recent NXT Software updates, especially the Dynamic Block Update:
http://mindstorms.lego.com/support/updates...04&nxtswid=

The problem was the mini blocks that I had not downloaded. Thanks! Looks great!

Einar