[BrianSilverman]

A couple corrections/clarifications. Sorry for taking so long; I didn't realize more stuff got posted (still learning how to use CD)...

Originally Posted by AustinSchuh

It does nothing other than listen to the BBB for motor control packets and run the compressor.

It also takes joystick data and forwards it to the BBB. We had to go through the cRIO there both because of the rules and because the DS sends the packets there.

Originally Posted by AustinSchuh

UDP packet with all the motor values. If I remember right, the protocol is pretty flexible and essentially says 'talon on port 1 -> 50%, spike on port 5 -> fwd, solenoid 3 -> on' in a list. UDP is the right answer here since we don't want stale values to arrive, and would rather drop packets than get them too late.

That was the old version back when we had still ran some stuff on the cRIO, so it had to be flexible. The current version just sends an array of bytes across (the bytes that the cRIO writes out to the FPGA) for the motor controllers and 1 byte (8 bits) for the solenoids. We decided to minimize the amount of processing on the cRIO because of all the problems we've had there.

Also, despite using UDP, we still have issues with stale values because the bridge queues packets going between wired ports when it has trouble with the wireless communications (sounds weird, but it does).

Originally Posted by AustinSchuh

Nope. We are running it at like 80% CPU utilization right now without vision.

More like 60% recently, but still too much to comfortably fit vision.

Originally Posted by AustinSchuh

We have at least 2 partitions on the BBB. We put all our logs on one partition, and the root filesystem on another. We try to not write to the root partition so there is little to no risk of corruption. I'd recommend putting /var/ and where ever you put your logs on a separate partition from your executables. Brian can chime in on a bit more of the particulars of our current setup.

Everything except logs (including /var/, although on second thought that's probably a bad idea) is on the internal eMMC in one partition, and the logs are on the uSD card (which means they have their own partition).

Originally Posted by AustinSchuh

We have had a bit of trouble getting the BBB to come up reliably. It seems like the NIC doesn't always boot reliably, and sometimes the processor doesn't boot either. Every match when I boot the robot up on the field, I watch all the light sequences and make sure that the NIC lights are flashing and the CPU lights are flashing correctly. I've had to do a robot reboot once or twice on the field to fix it.

To be pedantic, the chip that doesn't like coming up is just a PHY.

Originally Posted by James Kuszmaul

I am not personally that familiar with the use of index signals on absolute encoders, but several potential issues could arise:
-The majority (or all?) of indexed encoders will give you one or more index signal(s) per rotation. Most of our encoders move more than a single rotation through their full range of motion. This means that we would only know for sure that we were in one of a few possible places.
-With the hall effect sensors, it is easy to put sensors near or at the limits of the appendage or device. This means that, when zeroing, we are guaranteed not to run into a hard stop.
-If, for whatever reason, the encoder were to slip, then we would have to re-do the zeroing calibration. If we did not notice this before a match, we could easily spend a whole match missing shots by slight amounts or dropping the ball or the such.

Using an index pin doesn't get you much, because you still have to have some kind of interrupt for counting it, you still have to position something that'll be different between robots (and can't move at all), and you still need some way to know which index pulse you've hit.

Hitting hard stops isn't as big of a deal because we always make sure to zero at low enough power that it can stall for several seconds without breaking anything (until somebody disables it). However, it is still nice to not have to worry about what position things start in.

Originally Posted by James Kuszmaul

Once our website comes back up, you can find our released code from just before this season started (it should come up just by searching "released code" or the such). We will probably be releasing more documentation regarding our controls at some point, but that is contingent on someone going to the trouble of writing it all up and then editing it to make sure that it is well enough written for release. Hopefully we get something out by the end of the summer, but don't hold your breath.

The code itself is actually on a different server (that still works) here.

Originally Posted by James Kuszmaul

I'm not really the person to talk to about this (Austin or Brian can tell you more). I never recall corruption of the SD card causing us issues when driving the robot (and certainly never in any matches), but at one point at Worlds, we noticed some of our logs had gotten corrupted so we replaced the BeagleBone (and SD card) in the robot anyways, just to be safe.

I think there is a good chance this was due to wearing out the uSD card. That corruption didn't happen after a hard shutdown; it corrupted the file while I was looking at it. The only other explanations I can think of are that the card was falling out or there was something else wrong electrically on that BBB. It didn't matter too much in the end, but it did make us nervous.