LabVIEW implementation

[Louis L]

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.

[Louis L]

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.

[Louis L]

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.

[Louis L]

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

[Louis L]

Tuned many autonomous values but did not get to vision related parameters.
And beat up the robot intake in the process.

[Louis L]

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.

[Louis L]

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:

• Y button moves the intake up or down (float)
• B button does low shot while held
• Left Trigger button presses down the intake; to be used only to get a better grip on the ball. The low-shot does this automatically.
• Autonomous lowers the intake when needed

[Louis L]

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:

• it looks for the 1st entry in the vision processing output. If there are no targets found, it does nothing and simply waits until there's something.
• when a target is present, it rotates the robot until the center of the target bounding box is centered horizontally across the crosshairs.
• it then looks at the distance returned by the vision computation and moves the robot forwards or backwards until it is inside the distance range.
• lastly it engages the do-it-all sequence to fire the boulder.

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.