Redshift Project Depot

FRC 2016 (Stronghold) => Robot Software => Topic started by: Louis L on January 01, 2016, 07:07:13 PM

Title: LabVIEW implementation
Post by: Louis L on January 01, 2016, 07:07:13 PM
This is what we did in the LabVIEW code
Title: Re: LabVIEW implementation
Post by: Louis L on January 16, 2016, 10:43:18 PM
The Labview team is
- Rakesh (lead)
- Alec
- Sarthak
Title: Re: LabVIEW implementation
Post by: Louis L on January 25, 2016, 03:46:48 PM
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.
Title: Re: LabVIEW implementation
Post by: Louis L on January 26, 2016, 11:55:42 PM
(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.
Title: Re: LabVIEW implementation
Post by: Louis L on January 29, 2016, 11:10:22 AM
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.
Title: Re: LabVIEW implementation
Post by: Rakesh V on January 30, 2016, 10:07:56 PM
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.
Title: Re: LabVIEW implementation
Post by: Louis L on January 31, 2016, 04:46:28 PM
Begin.vi and Finish.vi have been updated to account for all known devices - motors, encoders, digital I/O, etc.
Title: Re: LabVIEW implementation
Post by: Louis L on January 31, 2016, 08:09:44 PM
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.
Title: Re: LabVIEW implementation
Post by: Louis L on February 06, 2016, 07:43:34 PM
Added ADI IMU to code tree.
Added autonomous functions (1) drive to Outer Works, (2) go under low bar (3) go through defenses
Title: Re: LabVIEW implementation
Post by: Rakesh V on February 17, 2016, 11:37:22 PM
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.
Title: Re: LabVIEW implementation
Post by: Louis L on February 20, 2016, 07:47:07 PM
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.
Title: Re: LabVIEW implementation
Post by: Louis L on February 20, 2016, 10:29:43 PM
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.
Title: Re: LabVIEW implementation
Post by: Louis L on February 23, 2016, 12:37:46 AM
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.
Title: Re: LabVIEW implementation
Post by: Louis L on February 24, 2016, 09:44:16 AM
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.
Title: Re: LabVIEW implementation
Post by: Louis L on February 26, 2016, 10:00:13 AM
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.
Title: Re: LabVIEW implementation
Post by: Louis L on February 28, 2016, 11:11:53 AM
This falls in the category of the unexplained.

There's a boolean control on the dashboard that tells the robot whether to override the hardware autonomous settings with the dashboard settings. When everything is run for the first time, this boolean is false and works as expected. If then set to true, it also works. From there on, setting to false or back to true yields inconsistent results. The boolean it is sending to the robot code is very often wrong.

Seeing that numbers seem to be always correct, I changed the boolean value in the network table for this value to a numeric. The boolean is converted to a 0 or 1, the converted back on the robot side. Now everything works reliably. So somehow setting a boolean from the dashboard to the robot is not reliable. But numbers are fine. Go figure.
Title: Re: LabVIEW implementation
Post by: Louis L on February 28, 2016, 06:09:07 PM
Tested autonomous as best as I could without actual hardware. The vision portion (for auto-shot) has not been tested.

Speaking of vision, I still can't get both cameras to work at the same time. There's something about how the driver station is streaming from the robot that is not meshing with the robot's attempt to get image frames from the camera.
Title: Re: LabVIEW implementation
Post by: Louis L on February 29, 2016, 09:34:28 PM
I think I finally have it figured out.
Right now both cameras are working on the robot, and when using the front camera, the vision system is working. The part that's a little flacky is that when switching front/back, the image doesn't always switch on the dashboard. I've changed the dashboard once already, but it looks like I have to do it again.
Title: Re: LabVIEW implementation
Post by: Louis L on March 02, 2016, 10:49:47 PM
Rakesh finished off the dashboard and robot code to switch the images. Works well.

Also added timeout in hold-to-cradle part of command-7
Title: Re: LabVIEW implementation
Post by: Louis L on March 06, 2016, 12:16:58 AM
Tuned many autonomous values but did not get to vision related parameters.
And beat up the robot intake in the process.
Title: Re: LabVIEW implementation
Post by: Louis L on March 09, 2016, 11:50:51 PM
Updated climber with speed and direction information from Saty. More than likely we won't be using the climber at WPI. Also the code did not check the limit switch that said we're latched! Fixed that. Added code to run the drive wheels at fractional speed to keep it from sliding down the Battle.

Simplified the auto-rotate code to use the gyro. It now uses the +/- values returned by the gyro - much easier than the code that was there which assumed a 0-360 positive value.

Add a motor to CAN3 for the intake retract motor. Also patched in button 4 to toggle a state for this but it does nothing right now.
Title: Re: LabVIEW implementation
Post by: Louis L on March 24, 2016, 10:51:23 AM
Weird late night debug session for the raising and lowering the intake arm. The main takeaway is that motor protection / shutoff applies to all motors, not just the drivetrain! I did not know this! This explains why the ball pinch code did not work, it's fixed now. But in testing the motor config where the timeout and feature can be enabled/disabled, I concluded that it VI and/or the underlying code simply does not work. In other words if you want to disable the protection or change the timeout, forget it. Or I did something else wrong.

I think the arm is working well enough to be useful. The only catch is that it will stutter in some modes of operation and I don't know why. In actual use (instead of a testbed) we may never see it.

So the summary:
Title: Re: LabVIEW implementation
Post by: Louis L on April 04, 2016, 10:38:01 AM
Spent several hours on Sunday working on auto-shot. This is code that's been in for a while but never tested. It still has never been officially tested on a live robot but now it's gotten a run on the testbed. Here's what auto-shot does.

Auto-shot runs in the periodic-task VI. Setting the boolean Auto-Shot starts the process. I've added button 11 from the right joystick to engage auto-shot during teleop. The cancel sequence will also cancel auto-shot. It is also called from autonomous in auto mode 4 (cross defense and shoot).

Auto-shot does the following in sequence:
Step 3 was placed after step 2 intentionally. However if the robot does not track in a straight line, the targeting can be thrown off. We can fix this by swapping steps 2 and 3, or by adding another rotation adjustment after the linear movement to fine tune things.
The last thing to add (still debugging) is to add a dashboard value that offers a horizontal compensation. The current software tries to center the target in the camera's field of view. But may not be accurate if the camera mounting and shooter are not lined up right. There's a problem reading numbers from the dashboard- may be similar to the problem I had reading booleans - still working on this.
Finally we need to see if the ball pinch is needed or if there's another way to make it ball secure on the robot as it crosses the defenses.
Oh - added support for the hardstop motor. We should be debugging this really soon.