Autonomous Independent

[sparks-1784]

We tested the Autonomous independent tonight. At first, we had a FOR loop with drive commands and delays (similar to the tutorial example) and a WHILE loop with a watchdog with 20mS delay. What happened was that the motor commands and delay was being executed and the solenoid logic (in the WHILE loop) was only executed (briefly) after each delay was executed. This seems to make sense that the delay processing was 'hogging' all the processing resources and the solenoid logic would only be executed where each delay had finished.
We removed the FOR loop and brought a single motor command into the WHILE loop with the rest of the solenoid logic. What happened next was interesting, but first an explanation of the attached. The attached does not show all the cases for the solenoid logic, but I didn't think that was important for this discussion. If you need to look at all of the case states, let me know and I will send some screen shots of those.

We copied the solenoid logic from our Teleop program and used it in the autonomous. The way it works in Teleop is with 3 different button depressions - 1 fires the 'B' side of all solenoids for max kick, another fires 2 solenoids for a lesser kick and the third is the smallest kick. Each button depress fires the solenoid for 1 second and then fires the 'A' side of the solenoid for returning the kicker to 'cocked' mode. There is a 2 second timer to prevent the kicker from being fired again (within 2 seconds).
For the autonomous version, we replaced the 'buttons' with the optical sensor DIO and fire all the solenoid 'B' sides for the max kick in autonomous.

All of this was done with what I will call 'classical' logic and does not employ state machines of the type in the labview tutorial. I am sure that using the 'tutorial' type state machine would result in more 'readable' code, but all I can say is that I am still learning labview. Converting this to be more readable will be left as and exercise for the student (and mentor!).

Ok - so, we ran the autonomous and the autonomous mode was picking up the sensor and causing the solenoid logic to transition. However, the solenoid logic 1 second timing loops were quite a bit less than 1 second and the result was a flash change of state and back to 'cocked mode' for the kicker. The interesting thing was that the 2 second timer seemed to work...when we interrupted the optical beam constantly, the 2 second timer would count and then the solenoid logic would 'flash' and then the 2 second timer would repeat. We could not understand why one timer in the WHILE loop worked while the others did not.
Anyway...sorry for the long explanation. Hope you can help.

[Alan Anderson]

I think you attached the wrong file. What showed up was a blank Word document, not the Autonomous Independent.vi that I expected.

[Joe Ross]

Originally Posted by Alan Anderson

I think you attached the wrong file. What showed up was a blank Word document, not the Autonomous Independent.vi that I expected.

There are pictures of the code in the word document. However, it's very hard to follow pictures. It would be much better to attach the actual vi.

[sparks-1784]

Originally Posted by Alan Anderson

I think you attached the wrong file. What showed up was a blank Word document, not the Autonomous Independent.vi that I expected.

I believe I put everything in the word doc. The 'new' microsoft word (docx) would not upload, so I saved it as a Word 2003 file. It opened fine for me (both my work computer and home computer).

Anyway - yes, I know I can do this differently to get things to work. I was esssentially trying to make autonomous independent run periodically by using the watchdog (at least that is how I understand it - maybe I am all wet). It seems to 'sort of' work, but I have a hunch that some of the processing could be using the majority of the processing resources. I would venture that a way to get this to work would be to schedule each of the 'tasks' (timers, solenoid control, etc), but I am not sure how to do that. Just stringing the error cluster through each of the sub vi's would provide some 'order', but after watching the tutorial several times (on auto independent), I still don't understand how the error cluster 'stringing' works. The tutorial just makes a statement without a full explanation of the mechanism. I understand that a full explanation might be beyond the scope of the tutorials which provide what I would call a 'first level of understanding'.

We were debating just putting everything into the autonomous iterative (which I am pretty sure should work), but we wanted to understand why this didn't work.
There are many ways to do things.
All - thanks for your time. I'd rather not burden anyone with this, especially if I am trying to do something 'inane' with the auto independent programming.

[Mark McLeod]

Stringing the error clusters together to force an order works because LabVIEW is data driven. That means a vi or case statement or loop will hold up execution until all data inputs have arrived.
The error cluster as an input isn't necessary for any of the vi's, but the vi will wait for the data in the error cluster to arrive from the last vi before it will start execution. The error cluster output also isn't "released" until the vi producing it completes all internal tasks, so strung together like that one vi has to completely finish before the next one will begin.
If they stand alone they will execute in no specific order, essentially simultaneously.

You have what seem to be two independent operations:

• Driving
• Kicking

I'd probably keep these two separate as you originally had them, but give each their own While loop or sequence structure. There's no particular reason to have the Arcade Drive inside the kicking While loop, since it just keeps repeating the same identical action over and over. Separated, the drive code can be stopped after a fixed amount of time has elapsed, rather than continuing forever. You can also add a time limit to the whole structure as it currently stands and stop everything at once.
It appears that your motors will start at full speed, but will never stop (until Teleop takes over presumably). You'd go from the rear zone to the front zone until you ran into something to kick if a ball was missed or the sensor broke. I imagine your partners would be upset if you launched off a bump and came down on them at full speed.

It's not shown from your attachment how the outputs of "auto kick and solenoid logic.vi" line up, so we know what's going to which case statement in Autonomous Independent.vi.
It looks like your timing delays don't delay, because for the places where you use feedback to pass times back through case statements for comparison to the current time, no initial time is ever set. I'd guess that the unset time is actually always zero, so the False cases will always be executed.

I'll take your word for it that all those "auto kick and solenoid logic.vi" feedback and feedforward nodes work the way you want them to. It appears you have a paradox where you are checking the output of a case statement before it ever gets executed. It'll always have an indeterminate value at the time you go through those AND checks.

[sparks-1784]

Thanks for the feedback. A couple of things to note:
The motor control was put into the WHILE loop for testing purposes only. We have no intention to drive full speed for the entire period - we have a test setup and setting the motor control to 1 ensures that we can see the lights on the Jaguars for the end-to-end verification (no motors are attached).
Prior to that, we had a separate FOR loop with motor control (big commands to see feedback) and delays and a separate WHILE loop for the solenoid/kicker logic with watchdog 20mS delay (same as what was in the default code - the camera/tracking autonomous). As I may have previously mentioned, in that setup, the solenoid logic was not updating properly (reactions only seen when delays in the FOR loop were done).
The screenshots were from the last test we did.
The other thing to mention - if you notice, we monitor the DIO output and set a solenoid output (Solenoid 7). This would indicate to us that the optical sensor was being monitored (and how fast) in the WHILE loop by seeing the solenoid LED indicator on the cRIO solenoid module (solenoids are not connected and no pneumatic bumper - test purposes only). The test run with the separate FOR loop for the motor control and WHILE loop for the solenoids showed that the solenoid 7 was not updating except when the watchdog delays in the FOR loop transitioned to motor control (we could do this by constantly interrupting the optical beam until the transition).
Using the program attached, we did see solenoid 7 always updating when the optical beam was interrupted - however, as I stated, the solenoid 1 second timers were not working as designed.

I did not include all the cases in the attached file with respect to your comment on the timers. When the outer case statement is true, a one second timer is started.
As far as the feedback nodes and indeterminate cases, I suppose there could be indeterminate values. However, the feedback node on the last AND gate (before the case statement input) is a one-shot so I would imagine that the output of the one-shot is deterministic at startup (false) and hence the case statements are producing deterministic feedback, but that is my assumption.
The outputs for the autokick and solenoid logic line up with the solenoids they are controlling (123A is solenoids 1A, 2A and 3A, 1B, 2B and 3B go to solenoids 1B, 2B and 3B respectively). Just FYI - the logic that is feeding the solenoids is button decoding. Button 1 fires 3 'B' solenoids, button 2 fires 2 'B' solenoids and button 3 fires 1 'B' solenoid. The 123A output ensures that the 'A' side of the solenoids are on or off at the proper times in opposition to the 'B' solenoids since the solenoids are the double action pneumatic solenoid valves and energizing both 'A' and 'B' side at the same time will result in indeterminate operation of the valve.

[sparks-1784]

Thanks for the feedback. A couple of things to note:
The motor control was put into the WHILE loop for testing purposes only. We have no intention to drive full speed for the entire period - we have a test setup and setting the motor control to 1 ensures that we can see the lights change on the Jaguars for the end-to-end verification (no motors are attached).
Prior to that, we had a separate FOR loop with motor control (big commands to see feedback) and delays and a separate WHILE loop for the solenoid/kicker logic with watchdog 20mS delay (same as what was in the default code - the camera/tracking autonomous). As I may have previously mentioned, in that setup, the solenoid logic was not updating properly (reactions only seen when delays in the FOR loop were done).
The screenshots were from the last program we tested.
The other thing to mention - if you notice, we monitor the DIO output and set a solenoid output (Solenoid 7). This would indicate to us that the optical sensor was being monitored (and how fast) in the WHILE loop by seeing the solenoid LED indicator on the cRIO solenoid module (solenoids are not connected and no pneumatic bumper - test purposes only). The test run with the separate FOR loop for the motor control and WHILE loop for the solenoids showed that the solenoid 7 was not updating except when the watchdog delays in the FOR loop transitioned to motor control (we could do this by constantly interrupting the optical beam until the transition).
Using the program attached, we did see solenoid 7 always updating when the optical beam was interrupted - however, as I stated, the solenoid 1 second timers were not working as designed.

I did not include all the cases in the attached file with respect to your comment on the timers. When the outer case statement is true, a one second timer is started.
As far as the feedback nodes and indeterminate cases, I suppose there could be indeterminate values. However, the feedback node on the last AND gate (before the case statement input) is a one-shot so I would imagine that the output of the one-shot is deterministic at startup (false) and hence the case statements are producing deterministic feedback, but that is my assumption.
The outputs for the autokick and solenoid logic line up with the solenoids they are controlling (123A is solenoids 1A, 2A and 3A, 1B, 2B and 3B go to solenoids 1B, 2B and 3B respectively). Just FYI - the logic that is feeding the solenoids is button decoding. Button 1 fires 3 'B' solenoids, button 2 fires 2 'B' solenoids and button 3 fires 1 'B' solenoid. The 123A output ensures that the 'A' side of the solenoids are on or off at the proper times in opposition to the 'B' solenoids since the solenoids are the double action pneumatic solenoid valves and energizing both 'A' and 'B' side at the same time will result in indeterminate operation of the valve.

[sparks-1784]

After typing all the previous stuff, I feel like an idiot.
A picture is worth 1000 words.
The actual vi is worth more.
Here it is.

[Mark McLeod]

Much better to look at.
Unfortunately, I don't see anything wrong with how you're handling the timers in Autonomous Independent.vi unless it's a problem in "auto kick and solenoid logic.vi" which I don't have.

Running through that selection logic every time, even after the initial selection due to DIO has been made, may not be working right and could be the cause of the problem. It'd be easier to trace the logic if that vi was posted too.

It seems like you should just be able to just test for the rising edge of the Ball sensor DIO to trigger everything.
a la the attached. Note I increased the rest timer on you too.

[sparks-1784]

I believe these are the files for both the Teleop mode joystick read and solenoid logic and the autonomous mode autokick and solenoid logic - at least I am pretty sure these are the files.
I have to apologize...I am sending this from my home computer (without labview) and I cannot inspect the files to make sure. We backed them up tonight on a jump drive and I am just uploading from those backups.

We were able to view both files tonight in a review with the students when I spotted something in the auto indep vi that might be the cause. I copied the teleop joystick read and solenoid logic and renamed the file in the auto indep and I re-wired the feedback. I was impressed that labview put in the feedback nodes and interested that when I drew it differently, it put nodes in differently. When you connect feedback loops in labview, it automatically puts in the feedback node. Depending on what connections will be made last will determine where the feedback nodes go. In the case of auto indep vi, it looks like instead of a single feedback node wired to the output of the case structure, there are 3 feedback nodes right before the 2-two input OR gates. I figured that if Labview allowed you to wire it both ways and automatically put in the feedback nodes, they must be the same.
It could be a difference - maybe the nodes in those locations start as indeterminate?

We'll be at Hartford tomorrow and will try to do some more debug there.
Thanks again for the feedback.

[Mark McLeod]

A big difference in feedback nodes from what you first posted.
I'll walk through it and see if I spot anything.

FYI
Each of the feedback nodes can be given an initial value.
right-click and choose Create -> Constant

Good luck in Hartford!

[Ether]

Originally Posted by sparks-1784

Hope you can help.

I don't know if this would help you, but when our team was struggling with autonomous independent, the following thread was helpful to us:

http://www.chiefdelphi.com/forums/sh...ad.php?t=82564

especially the following two posts:

http://www.chiefdelphi.com/forums/sh...94&postcount=2

http://www.chiefdelphi.com/forums/sh...19&postcount=8

The above posts describe how to code autonomous independent as a state machine. We didn't wind up doing it that way though.

Eventually what we wound up doing is the following, based on various recommendations from knowledgeable folks here in the forum, and it has worked flawlessly:

- we moved our "kicker" and "mecanum drive" code to separate periodic tasks (kicker running at 50ms and mecanum drive running at 20ms), and communicate with them via global variables. The code in the "kicker" periodic task is implemented as a state machine which looks for limit switches to change states. A global boolean initiates the kicker, and the kicker changes the boolean back to "false" when it has cycled through all its states and is done. The drive task reads numerics which tell it what the joystick commands are.

- now the kicker and the drive code can each be "called" (or should I say "controlled", because they are not "called"... they are constantly running in parallel and receiving marching orders via the global variables) by both the TeleOP AND the Autonomous Indendent VIs.

- the autonomous independent VI is implemented as a flat sequence, with "watchdog delay and feed" used to introduce delays where desired.



~