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.

[feverittm]

Originally Posted by Jared341

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.

I would totally agree with this point. Our team (997) has a recurring electrical issue during the seeding rounds at Atlanta that would manifest as the robot completely dying for upwards of 30 seconds after being/receiving a bump. This was traced to a bad ground connection on the cRIO! There has to be a more secure method to connect wires to this critical piece of hardware.