Autonomous Independent

[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!