LabVIEW implementation

[Louis L]

This is what we did in the LabVIEW code

[Louis L]

The Labview team is
- Rakesh (lead)
- Alec
- Sarthak

[Louis L]

Interesting twist this year. There are two ways to write LabVIEW robot code now. The first is just like previous years. The second is a new "command and control" model that takes the same approach as that used in C++/Java.

Under Command and Control, the main loops no longer perform the actual functions. Instead they issue commands into subsystem queues for worker threads to perform. There can be any number of subsystems and each operates in its own thread. The main thread is essentially a dispatch thread. The subsystem worker threads no longer interfere with each other (ex: if one takes too much time).

The C&C model is clearly the future and a better way to do things. However, it adds a lot of complexity to the code. Each subsystem now carries with it a significant amount of code just to make things tick. And the more code we have to write the more likely we'll make mistakes. Having commands also means more architectural work needs to be done up-front.

We need to decide which project type we want to pursue for Stronghold.

[Louis L]

(1) We decided to use the old way of writing LabVIEW code - no command and control. We'll port to the new way in the off-season

(2) I looked over the drivetrain code. Things I think may be causing the problem we saw (it didn't work right!)
- In Begin.vi - Only 2 of the 4 booleans for direction were set. The other 2 defaulted (didn't check to see what it defaulted to). Of the two that were set, one was set to True and one to False. I think they should all be False so that's what I made them.
- In Teleop.vi - the X axis was selected for both joysticks. But it's the Y axis that's used when the joysticks are pushed or pulled.

I'm not sure how this explains the one motor that wasn't turning; will check this tomorrow.

[Louis L]

Rakesh started coding the climber. We defined some button and button combinations to initiate and cancel the climbing.
Each new subsystem requires touching a number of files - Begin.vi (to define and open I/O devices), Finish.vi (to close I/O device). Teleop.vi (to handle user input) and Periodic Tasks.vi (to perform state machine functions). We chose to put our state machine in PeriodicTasks and connect with user inputs in Teleop using global variables. States will be numbered in increments of 10 so that we can easily insert states in the future as needed (numbers are easy for humans to read).

The Climber is among the more difficult of the functions to code so once done, the others (with the exception of vision) will be relatively easy. The others include the Intake, Shooter, autonomous and vision.

[Rakesh V]

Today we worked more on the climber code. We also were able to change the 4 motor drivetrain we had previously to a 2 motor drivetrain. We were able to finish the code to line the robot up to initiate climbing, and started working on using the encoders to find out how far the scissor lift can extend.

[Louis L]

Begin.vi and Finish.vi have been updated to account for all known devices - motors, encoders, digital I/O, etc.

[Louis L]

Updated Teleop.vi and Global1.vi to handle 4 button intake button presses. Perform priority handling of button - in case there's more than one intake button held at a time.

[Louis L]

Added ADI IMU to code tree.
Added autonomous functions (1) drive to Outer Works, (2) go under low bar (3) go through defenses

[Rakesh V]

Today we worked on testing the climber code. Both the intake and shooter code are finished, but there are still some bugs to fix within the climber code. Also, vision targeting and autonomous are two other goals we have to get done fairly soon. The auto-climb function we have coded starts, but does not seem to time out after 5 seconds, or turn off after holding buttons 1+6 for cancel climb. Objectives for tomorrow are to get climber code all done on the test bed, and continue on vision targeting.

[Louis L]

Updated the labview code yet again to add a timeout to the ball launch (command 6 and 7). The issue here is that every time a limit switch is used to start or stop a motor, there should be a timeout to prevent it from going forever. The global cancel is also there to help get out something unexpected but the timeout serves to prevent damage before the driver/operator realizes something bad happened.

[Louis L]

Was looking at autonomous and decided there are still a few things we need to test on the real robot before we can implement autonomous. In particular we need to know if the distance calculation works. Also need to know how the ball will be carried at time=0; and what needs to be done to deploy the intake and secure the ball for going over the defenses.

Implemented auto-shot. While there is no button for this any more, its placement in periodic tasks makes it an ideal way to act as a worker thread. Even though there are some severe limitations due to the lack of mecanum wheels, auto-shot now looks at the target, rotates to center the target, then moves forwards or backwards before calling all-in-one.

[Louis L]

When lowering the shooter, check the cradle sensor to make sure there's nothing there. If there is, don't lower shooter. This prevents crushing the electronics!

On autonomous start, go forwards then stop. Wait for intake to fall down. Then pinch boulder a little bit more.

[Louis L]

Last night we ran some tests prior to bagging the robot.
- the distance calculator based on the accelerometer did not work. Will debug this further on the testbench.
- removed a timeout in the intake.
- I think Hold-to-Cradle still has a problem whereby the roller stays on longer than it should. Does it properly check for the Cradle sensor?
- autonomous did not work. The initial shake-down-intake code failed. Not sure why; will have to check code. Also not working was the various timing flat-sequences which failed to do things in sequential order.
- the winch polarity was reversed to make it work. Use -V to drive the winch up.

[Louis L]

Found a bug in the vision camera code last night that hopefully will let us use the second camera. The bug is interesting in that it's the direct cause of using an existing framework instead of writing one from scratch. But on top of that, the existing framework is inconsistent.

The framework assumes that one camera is used so when we added a second, we could not get the second camera to show up properly. That's because there's a boolean enabler that's constantly being set to "true" in the scheduling loop. Any attempt to change this boolean elsewhere gets overriden on the next pass of the scheduler. But what makes this really interesting is that global variables defined in the framework (such as the image size) are placed on the front panel.  In other words there's a conflict of data coming from both the front panel and the global vars. One would think that the front panel values would go to the globals and then be used but that's not how it works. My guess is that this code got changed a few times and no one cleaned it up once it was working for the single camera case. The changes I made were minor but it does highlight the pitfalls of relying on existing code.