Multiple Autonomous Actions

[2386programming]

My team is working on some autonomous code for an off season event we are attending, and we have a simple drive backwards autonomous. But we were hoping to at least pick up a tote and drive back. This is the code that we currently have...

[Alpha Beta]

It sounds like you want to lift the tote before you start moving backwards. You can link while loops together in sequence and put the code for lifting the tote in the first loop, and your drive backwards code in the 2nd loop. The first loop will not send information outside of its loop until it finishes, and the 2nd loop will not start until its inputs are filled. You could end the first loop on timing, number of loop iterations, or based on some robot feedback that lets you know the tote has been lifted.

[Bpk9p4]

Originally Posted by Alpha Beta

It sounds like you want to lift the tote before you start moving backwards. You can link while loops together in sequence and put the code for lifting the tote in the first loop, and your drive backwards code in the 2nd loop. The first loop will not send information outside of its loop until it finishes, and the 2nd loop will not start until its inputs are filled. You could end the first loop on timing, number of loop iterations, or based on some robot feedback that lets you know the tote has been lifted.

I really like this method. We used it this last year with great results. The only problem i have with it and am not sure how to solve is if you stop the Auto in the middle the only way to reset the while loops is to reboot the code. Do you have a solution on how to fix this

[Alpha Beta]

Originally Posted by Bpk9p4

I really like this method. We used it this last year with great results. The only problem i have with it and am not sure how to solve is if you stop the Auto in the middle the only way to reset the while loops is to reboot the code. Do you have a solution on how to fix this

Try briefly enabling in teleop and then going back to auto. We often did this naturally during our tuning sessions to make sure our pneumatics were fully charged, or to reconfigure the robot back to it's starting position.

[Bpk9p4]

hum ok i will give this a try. Do you still place all your blocks in the Auto area?

[aeastet]

You can use a state machine. We posted our code on line. Take a look at what we did. It will help you a lot for next year if you do. Our autonomous code look very simple and is very easy to edit. You can stop and start it with out having to reboot.

Look up team 107 code post

http://www.chiefdelphi.com/forums/sh...d.php?t=137046

If you have any questions let me know.

[Bpk9p4]

cool i will take a look at it. We have used state machine in the past however i do not like not being able to see everything at once. Also it is hard to move states around. Do you have any ways around these problems

[aeastet]

I our code everything is handled using enumerated value arrays. The enumerated values is a strict type def. It is very east to move things around. We had nine different auto modes this year and it only took minutes to make a new one.

[wt200999]

Originally Posted by Bpk9p4

... i do not like not being able to see everything at once...

Along this line, as you get more complex you will end up having code running off the screen (bad practice), so you really limit yourself in that regard. If you give meaningful names to your states it should actually be far easier to navigate and becomes self commenting.

Originally Posted by Bpk9p4

Also it is hard to move states around. Do you have any ways around these problems

I am not sure what you mean by not being able to move states around, do you mean physically move on the block diagram, or changing the sequence?

If you limit each state to small functions you can make it more modular and keep each state smaller. This may force you to pass more data however.

This is the structure I like to use to pass data between states:

[Bpk9p4]

Originally Posted by wt200999

Along this line, as you get more complex you will end up having code running off the screen (bad practice), so you really limit yourself in that regard. If you give meaningful names to your states it should actually be far easier to navigate and becomes self commenting.



I am not sure what you mean by not being able to move states around, do you mean physically move on the block diagram, or changing the sequence?

If you limit each state to small functions you can make it more modular and keep each state smaller. This may force you to pass more data however.

This is the structure I like to use to pass data between states:
Attachment 19396

i was meaning more moving the sequence. i really liked just being able to copy and paste and move things around. Are code is posted here if you want to see how we did it. http://www.chiefdelphi.com/media/papers/3152

Also i really like your type def idea that make it much easier to move things around. I will give that a try.

[Bpk9p4]

if you guys are interested are team with PlayingWithFusion help just released are new mini Labview robot for software development. We have been using it the past year to teach students Labview and test new software

Here is the link for the release video https://www.youtube.com/watch?v=EFmnmp_VHHU

http://playingwithfusion.com/product...=65&catid=1009

[2386programming]

Connecting while loops is working well. Is there anyway to make one action go before the other? Because currently, both actions are running at the same time.

[Alpha Beta]

Originally Posted by 2386programming

Connecting while loops is working well. Is there anyway to make one action go before the other? Because currently, both actions are running at the same time.

It doesn't sound like they are connected then. Make sure something (anything) in the first loop creates an output tunnel on the right side of that loop and is then wired to an input tunnel on the left and side of the 2nd loop.

If you think you've already done that, then post a picture of your code and we'll see if we notice anything else.

PS. It's also possible that your first loop triggers the lifting of a tote, but doesn't actually wait until it's lifted before the loop finishes. If the first loop time is short enough it may be difficult to tell visually that it starts before the second loop.