Team 624 CRyptonite 2014 LabVIEW Code Release

[randantor]

Team 624, CRyptonite, would like to release the code for our 2014 robot, Sidewinder.

http://team624.org/files/624 2014 Code Release.zip

Our code was written entirely by the students in our programming subteam. Some features:

- A scripted autonomous with multiple modes, using an editor that "compiles" scripts into CSV files that we can eaily read as a 2-dimensional array in LabVIEW code

- Hot goal detection with vision processing on the dashboard using an adapted version of the LabVIEW examples to work with two Axis network cams on the robot

- Automatic gear shifting based on information from this thread

- An automated ball pickup sequence using Banner IR sensors to detect the presence of the ball

- Automated shooting of our pneumatic catapult, with a solenoid to select between two pressure regulators, as well as a variable "soft shot" that releases a bit of air before firing

- A fancy custom dashboard featuring 117 tunable robot parameters that can be saved to a text file
(we actually had to stop using NetworkTables midway through competition season because it was overloading our cRIO CPU at random times, likely related to the massive amount of dashboard controls and indicators)

- I2C communication with an Arduino to control Adafruit NeoPixel LED strips to display status information such as shooter status, robot gear, and drivetrain mode for the driver.

- Detection of the white line on the field with Banner IR sensors to automatically make running shots
(we ended up not using this after week 1 because of the amount of defense and our large shooter "sweet spot")

- Gyro stabilization of strafing with the H-drive to keep the robot yaw steady

- An automated "roll maneuver" to rapidly turn the robot 180 degrees while driving down the field (this was an experiment during the offseason that ended up not having much use on the field)

We used git with LabViewGitEnv for source control (more info on that here).

Because git merging is a horrible experience with LabVIEW code, we broke our code down into many small
subVIs. We used a general rule of thumb that if a VI block diagram doesn't fit on a (1366 x 768) laptop screen,
it should be broken up into smaller subVIs. This led to a very different architecture than we have had in the past,
and in my opinion it made our code much more readable and maintainable, avoiding the typical "LabVIEW Spaghetti Syndrome"

That said, the code is still very messy because it evolved in parallel with the features on the robot. We did a lot of programming
and modifications before mechanisms on the robot were entirely worked out, so there is a lot of dead code that hasn't been
cleaned up.

[Richard100]

Like the modularity of your LV code. Do you plan on releasing the Arduino code?

[randantor]

Originally Posted by Richard100

Like the modularity of your LV code. Do you plan on releasing the Arduino code?

The Arduino code is in the folder named "Light Code". It's pretty messy thanks to our lack of Arduino experience and a rush at the end of build season to get the lights functional.

[Richard100]

Thanks. In 'Begin', you use a value of '4' as the Device Address for the I2C Open VI, and a value of '6' as the I2C Register for the I2C Write used in your I2C Comms VI ... can you explain those values?

Do you have a wiring diagram for the Arduino I2C connection?

[randantor]

Originally Posted by Richard100

Thanks. In 'Begin', you use a value of '4' as the Device Address for the I2C Open VI, and a value of '6' as the I2C Register for the I2C Write used in your I2C Comms VI ... can you explain those values?

Do you have a wiring diagram for the Arduino I2C connection?

The 6 is arbitrary, it's sent as the first byte of the packet and the Arduino code just discards that byte.

The 4 is the I2C slave address for the Arduino. In the Arduino side the address is actually set to 2, there's some sort of difference in the addressing scheme between the two devices which means that the cRIO needs to use an address that is the Arduino address shifted one bit to the left. It's something to do with 7 vs 8 bit I2C addressing but I don't know exactly how it works.

As for wiring it, we just used a male-female PWM cable between the I2C port SCL, SDA, and ground pins on the sidecar running to the SCL, SDA, and (unused) pin 19 of an arduino mega 2560 clone.

[Richard100]

Great, thank you.