Feedback Thread: Robot Control System

[Greg McKaskle]

Spurred on by feedback scattered in other threads, I'd like to request detailed feedback on the control system. To help organize things, I've created three feedback threads, one for the HW elements that are used on the robot, one for the Dashboard and Driver Station, and one for WPILib.


Feedback Topic:
-----------------
HW control system elements on the robot


Tips on giving feedback:
---------------------------
Please be specific as to which elements are being commented on.

Not all teams use elements in the same way, so there is no need to argue that your value judgement for a component is the right one. Explain or justify your judgement so the expectations and context of use is clear.

While comparisons are a fine way to provide feedback, be sure to capture the context that is in your head. What did you expect it to do? Where did it fail and succeed? And then, tell how that compared to the other experience.

Please include tips on best-practices -- a good tool used poorly doesn't lead to a good experience, and the knowledge you can share may make a huge difference to someone else.

Once you've given the context please give your thoughts on improvements.

Greg McKaskle

[Tom Bottiglieri]

I'll probably end up leaving a couple responses in these threads, with each response as a separate issue.

The ethernet connector on the cRIO was a failure point for us this year.

There were a ton of cycles put on it switching from a tethered connection to the radio connection.

But, I think our issue originated when we were practicing while tethered on the practice field in Atlanta. The robot took a quick turn, and the cable got caught up and probably yanked on the connector. We eventually had to swap our cRIO during a timeout in eliminations as our comms died every match. We felt a noticeable difference in the connection between the two cRIOs.

This was probably more of an issue on our side, but it may be nice to have and out of the box strain relief feature.

[AdamHeard]

I am not a fan of the radio itself. It's made to sit still.

We triggered the security reset button in 3 matches at our 2nd regional, sitting there the entire match.

For the first time in my FIRST career, we cheated. We opened the radio and removed the mechanical portion of that button.

we NEED new radios; they simply are horrible for the task, especially the power connector.

Originally Posted by Tom Bottiglieri

I'll probably end up leaving a couple responses in these threads, with each response as a separate issue.

The ethernet connector on the cRIO was a failure point for us this year.

There were a ton of cycles put on it switching from a tethered connection to the radio connection.

But, I think our issue originated when we were practicing while tethered on the practice field in Atlanta. The robot took a quick turn, and the cable got caught up and probably yanked on the connector. We eventually had to swap our cRIO during a timeout in eliminations as our comms died every match. We felt a noticeable difference in the connection between the two cRIOs.

This was probably more of an issue on our side, but it may be nice to have and out of the box strain relief feature.

That better not have been our cRIO

[Radical Pi]

Please don't make the WET radios standard. Getting those stupid things to boot on the practice fields took up nearly half our time. Plus all the field problems that occured with them. At the least, do some major testing with the combinations of radios to eliminate any problems

[taichichuan]

The Ethernet connection on the Classmate was troublesome in that we found quite a few teams where the Ethernet connector had physically broken. The Ethernet cable just wouldn't stay inserted. This is only tangentially related to the robot control system, but without the Ethernet on the ClassMate, we don't have field communications. Since it's a weak point, maybe we should have a recommended solution for how to attach a pigtail of some sort that ensures positive cable retention?

[taichichuan]

In the case of the Video camera and its Ethernet connection to the cRIO, the routing in the cRIO is bolluxed. A routing table modification in the cRIO will allow the camera output to be directly routed to the Classmate. First, we need to enable IP forwarding across the Ethernets. To do this just set the internal variable ipforwarding=1 on the cRIO.

Next, we need to add a route on the ClassMate via a DOS cmd box:

route add 192.168.0.0 mask 255.255.255.0 10.xx.yy.2 metric 3 -p

The xx.yy is your team number e.g., Team 116 would be 10.1.16.2. The metric of 3 allows it to go through 3 hops to get to the camera. It's one more than you need, but this allows you to attach a secondary laptop to the Classmate via a USB Ethernet and display the output on the secondary PC. Since the Classmate appears to be having trouble keeping up with the video, this is a good option that is still within the rules.

The final "-p" makes this route persistent across reboots. I.e., you won't have to enter this route again on the Classmate.

HTH,

Mike

[taichichuan]

Does anyone know if the radios were all set to the same wifi channel for the FMS? I'm assuming so because then each of the robot radios would then associate with a single access point. With 6 robots on the field, even one of the 20MHz wide 802.11n channels would start to get pretty congested.

That being said, there are several dual-band access points that permit simultaneous 2.4 GHz and 5 GHz access. Is there a way to partition the robots such at we try to split up the use of the frequencies? Or at a minimum, use multiple access points on 6 different channels going into a switch such that the odds of having 6 robots on the field that all had the same channels would be minimized? Just trying to reduce congestion in the frequency bands so we're not stepping on ourselves during a match.

HTH,

Mike

[Jared Russell]

PD board - great; no complaints.

cRIO - power connector is TERRIBLE. Are there any other options here?

Breakouts/Bumpers - great; no complaints.

Sensors - great; no complaints. Love that the gyro and accelerometer come on the same board, but can be easily separated.

Digital sidecar - we had a couple of issues where the 5V rail on the DSC got shorted by debris near the connectors. If the plastic housing were a bit larger, this probably wouldn't have happened.

Radio - clearly not designed for use on a robot We had to carefully mount it to stop the reset button from pressing itself.

OVERALL:

My biggest complaints are things that can't be easily changed as far as I can tell. Boot time is way, way too long. The cRIO is big and heavy.

[Greg McKaskle]

Which end of the cRIO connection, and can you expand on what the issue is?

Greg McKaskle

[Jared Russell]

I'm talking about the 4 pin screw terminal on the cRIO. I've yet to be able to get the connection secure enough for my satisfaction.

[vhcook]

Power Distribution board does not seem to provide adequate overcurrent protection for the connections for the cRIO, camera, and robot radio (ports J24, J25, and J26). I didn't really think about this until team 1764 showed me the melted mass of wire and plastic that used to be their camera power cable at the KC regional this year. They appeared to have been using an appropriately sized cable wired to the correct terminal. I don't have all the details as to what went wrong, but it left an impression.

[EricVanWyk]

Originally Posted by vhcook

Power Distribution board does not seem to provide adequate overcurrent protection for the connections for the cRIO, camera, and robot radio (ports J24, J25, and J26). I didn't really think about this until team 1764 showed me the melted mass of wire and plastic that used to be their camera power cable at the KC regional this year. They appeared to have been using an appropriately sized cable wired to the correct terminal. I don't have all the details as to what went wrong, but it left an impression.

I can comment directly to this; I received the tech support request.

Without going into too many details, the molten-wire-soup response was the result of several chained faults, one of which was using a 2009 PD instead of a 2010 (which was technically against the rules...). The most likely explanation is that there was also a double chassis fault.

So, the problem is rare to begin with and was fixed for the 2010 KoP. No changes are currently planned for the protection on that port for 2011.

[Jon236]

Is there is a difference between the '09 and '10 PD boards? We've been swapping ours back and forth for prototyping and I'm not even sure which landed up on the final robot!

[vhcook]

Originally Posted by EricVanWyk

Without going into too many details, the molten-wire-soup response was the result of several chained faults, one of which was using a 2009 PD instead of a 2010 (which was technically against the rules...). The most likely explanation is that there was also a double chassis fault.

So, the problem is rare to begin with and was fixed for the 2010 KoP. No changes are currently planned for the protection on that port for 2011.

Thanks for the explanation, Eric. I was unaware there were any functional differences between the 2009 and 2010 PD boards. Since they look identical and carry the same part number (having just checked the 2009 and 2010 KOP checklists), how can I tell which one is which?

[Mark McLeod]

Originally Posted by Jon236

Is there is a difference between the '09 and '10 PD boards? We've been swapping ours back and forth for prototyping and I'm not even sure which landed up on the final robot!

The '10 PD will have red LEDs under any wired Wago connections that also have pulled breakers. It's pretty easy to identify when it glows in the dark.


P.S. Just to keep thread clutter all in one place:
- the new robot bridges (WET610N) are too slow in connecting, but the reason Kate (FRC KOP Engineer) gave for picking them included improved streaming video performance.

- the Digital sidecars had some debris induced, shock induced, etc. damage that was sometimes difficult to diagnose on the field. From the returned units Eric has been able to examine, are there any common failures that could be readily identified via additional status LEDs?

- Several issues with the Classmate driver station. All-in-all it worked well. The obvious problems:

1. depending on battery power on the playing field
2. random failed USB power re-negotiations (game controllers, Cypress)
3. failed services upon waking from Sleep mode (Cypress)
4. failing to connect to FMS (rare cases)
5. easily broken Ethernet cable retention

-cRIO module connections came loose on robot impacts (50g clips are not enough sometimes).