autonomous tin can collector with LabView12

[jenny86eng]

Hello everybody,

some of my friends and me are working on a Lego Mindstorms NXT project for an autonomous tin can collector at a German university.
The construction is fine so far, but we struggle a bit with the software (VIs). So it would be awesome if some here can share their experiences with us!
First I wanna give you some short details about what we need to do and did so far:

The project target is that the robot we constructed can drive autonomously within a 2x2m field and find empty 0,33l tin cans of coke painted in 3 different colors (yellow, red, green) and bring them to 3 different unloading areas which are outside/bordering the field.
We need to collect 6 cans in total.....they are just placed randomly in the field at the beginning.

As you can see enclosed, the NXT construction has a grabber and some sensors....maybe we change the transport system to real wheels, because we have some basic ideas about odometry for wheels, which we plan to integrate these days.
The real problem is the VI construction. So far we just built a logical construction on paper and designed it using the NXT modules + odometry basics in other file....but it seems not yet very agile, sure without any error messages in LV, however not yet running as we wish to...there must be some loop problem as the robot is not really doing what it should do.

What do you think of the programme? Can someone here make some quick improvement/suggestions. I am sure the loops are not yet perfect like that....

If you need further updates, please tell me. Thank you so much for helping

Greetings from Germany, Jenny

[hassenplug]

Well, I don't have LV12 installed. Can you post a picture of the program?

What do you think the program is doing right/wrong?

Steve

[jenny86eng]

Hello Steve,

thanks for your support.
Well as you can see on the pictures, I already tried to built up some logic, according to the actions we would like the sensors to take. E.g. the tin scan process with the ultrasonic sensor and afterwards grabbing the can when detected.
Also the unloading process when arriving in the unloading area.
We tried many different ways already but somehow there seems to be a logical mistake in the loops as the robot is always doing sth else than expected. sometimes its grabbing to early, sometimes not at all and just moving, or even not moving at all...
also we tried to work with sequence loops but it seems like the nxt 2.0 cannot accept this kind of loop, as lv12 does not allow to upload it on the nxt.

can you please have a look at the programme? it looks to simple i think, maybe we need to put the elements together differently.
also you can see that there is still another start button somewhere in the middle which is just a placeholder as the odometry and the pattern is not yet integrated. we are measuring the field at the moment. we have a odometry calculation which should work parallel to the other processes...

thanks for helping and greetings from germany

jenny

[hassenplug]

Looks like there are a few little issues with your program. The biggest problem is that there are several places that you're trying to tell the motors what to do, and there's not anything to indicate which of them can happen first.

Some suggestions & comments:
1) The "NXT btns" block at the start doesn't do anything. The software is reading the value, but it does nothing with the result. I forgot, is there a "wait for" block? That's what you should use there. Or, wire the result (green T/F wire) to something.

2) If you connect all blocks together using the pink wires, there will be a clearly defined sequence. There's a wire that goes into your first case frame; that wire should come out and connect to the next block in the line (the sonar block) You'll need to make sure it goes through both the true and false cases

3) The biggest problem may be the items you have connected to the Left Button block. That thread could execute at any time. (see #1) I think the whole thing can be removed.

4) You should make sure the Sonar sensor CAN return a value < 1, or that part may not execute.

5) I think with the NXT, you can only use one "Sequence loop (frame)" at a time. With that, everything that feeds in, must be complete before it can start, and everything inside must be complete before it can exit. I'm not sure that you really need one, here.

I hope that helps.
Steve

[jenny86eng]

Hello Steve, and all other interested people,

thanks for your advices and your fast reply. We tried your ideas and experimented a few other things as well.
So first I want to explain what the NXT is doing right now with the updated programme which you can find enclosed.
As you can see we eliminated the start button and now it’s starting directly scanning for tin cans, when the sensor detects cans the engines slow down as we wish to (loop1). When we remove the can again and place it somewhere in front of the route, the NXT accelerates again and slows down again. We found out that our sonar cannot scan values below 4cm, that’s why we placed the value of 5cm as indicator. However, the programme executed does not move from one loop to another as we thought, as the robot continues to drive slow and does not grab or scan as we designed in the 2nd loop (grabbing tin cans). Also the unloading process implemented in loop 3 is influencing the whole loop 1 and 2 (when we eliminate the loop 3 the programme runs as described above, but WITH loop 3, its just doing this loop all the time).
In addition the programme reacts to our stop button in the biggest loop which is good. We tested all 3 loops independently and they are working. But not combined in one programme.
It would be awesome if you can support us in your opinion on the following questions:

1) As you can see we connected all elements with the pink wire as you said. I am not sure if there is a contradiction in the first loop regarding the abort condition (green cable “true” Boolean) and the pink wire from the false condition of the case structure to the 2nd loop. What’s your idea?
2) In addition to that problem: as you can see, there are 2 loops with the same abort condition. Is this a contradiction which might influence the running programme. And what would you suggest as abort conditions for the loops?
3) As explained above, I have a suspicion that the 2 sonar sensor conditions of loop 1 and 2 contradict each other (the <5 is included in <10). How can I improve that?
4) Do the wait for time elements make sense where they are placed right now or are there a better place to put them? E.g. within the first case structure I am not sure if the acceleration motors in the true case are running continuously in the current programme version or if it is necessary to place an wait for time or sth like that…

Hope you can understand what I mean and looking forward to your reply. Have a great weekend

Jenny 

[hassenplug]

Well, I typed this up once, and it lost my reply. So, this one will be shorter.

The very short answer is that you need to look into what the Loop Exit Condition does. In your first two loops, when it checks to see if it should exit, you have it set to true, so it will exit right away.

I think you want it to loop and adjust the speed based on how close it is to the can. When it gets close enough to pick it up, you want it to exit the first loop, and do the other two things (pick it up, and drop it off), then return to your searching loop.

Attached are a couple images that show an example of how to exit the loop, the way you want to. (It doesn't have the correct motor constants, but I'm sure you can figure that out)

Steve