Feedback Thread: Robot Control System

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

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.

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.

That better not have been our cRIO :ahh:

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

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?

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

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

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 :slight_smile: 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.

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

Greg McKaskle

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.

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.

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!

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?

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. :slight_smile:

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)
      *]easily broken Ethernet cable retention
      -cRIO module connections came loose on robot impacts (50g clips are not enough sometimes).

Thanks! Other than looking prettier, are there any functional differences? I’m trying to setup some summer sessions and would like to utilize all of our assets!

I didn’t intend to derail the conversation, sorry!! If more discussion on this topic is required, could we please have a moderator pull it to its own thread?

The 2010 PD adds the blinky lights that Mark mentioned, a self-resetting fuse in the camera return path, and a tiny bit of extra power supply conditioning.

None of these improvements matter in the nominal “everything is happy” case. If you wire your robot correctly, a 2010 PD is identical to a 2009 PD. If you wire the robot incorrectly, a 2010 PD provides slightly more information and fails more gracefully* in a few specific fault cases.

You can tell a 2009 from a 2010 by the color of the PCB. Red for 2009, Blue for 2010.

The 2010FRC rules did specify a 2010PD, but a 2009PD works just fine. Please feel free to use them for whatever off-season uses you want to, secure in the knowledge that they are 99.something% functionally identical.

  • A few 2009 units blew out the return path of the camera supply when it was shorted to the battery input. A 2010 unit subjected to the same fault will protect itself and usually recover in 5-10 seconds. In an extreme situation, the third line of defense will kick in. This takes 20-40 minutes of resting unpowered to recover entirely, but I’ve never seen it happen in real life.

Eric, speaking of 2010 enhancements, what improvements were made to the Analog Breakout?

As for the cRio hardware itself, it was fairly good (although it does weigh alot). It would be nice to have a separate Tether and Radio connection to avoid unplugging the radio, but that could be fixed by using a radio with multiple ports (this would also make the tether easier to access, as the radio is generally in a more visible location than the cRio.

We have had some issues involving a broken Analog Bumper or Analog Module, we don’t know which but we replaced both and now it works. The voltage was oscillating considerable, as a graph of the analog inputs showed. We also had an issue where the analog module came out of the cRio and caused the arm to freak out and almost damage the robot (the e-stop helped here).

There are also many seperate points of failure here. There is the crio itself, its connections to the 3-6 modules, the connections of the 2-4 solenoid and analog modules to their bumpers, the connections on each end of 1-2 db37 cables, and up to 7 power connections not including the radio (4 bumpers, 2 sidecars, and the crio.)

Proposed solution: A crio backpack would attach to the top of all of the modules, providing a more robust connection with two screws to each module, and accept a single 12v unregulated input which would feed the 12v radio, 6v servos, 12v solenoids, 5v DIO and AI, and the 24v cRio. The camera could come off the 5v feed if it needed to, eliminating the PD board completely, some money savings for off-season projects. It could be designed for 2 analog modules, 1 digital module, and 1 solenoid module. the 32 DIO channels could have a fixed number of PWM’s, DIO’s, relays, SPI, and I2C. If you needed more than that, you could use modules like you have now in the remaining slots.

As for DSC’s shorting out, we have always fixed that by turning the robot upside-down and shaking it out. Works well.

Strictly to robot-end control system components, my biggest complaint is the radios. 18 seconds into a match at Kettering, we sailed over the bump after autonomous (not very roughly compared to other teams), hit the ground, and the radio stopped for some unknown reason. When we returned to the pits, we had a huge delay between matches (mostly because of field problems), got a new radio from spare parts, and had to wait for a really long time to have it reprogrammed. Once it was reprogrammed, we put it back on (in a different orientation this time), and used about 12-18 inches of duck tape on the connections, plus two zip ties to go with the velcro. No more problems at Kettering. Since then, we have carefully used a ton of duct tape on all radio connections and had no problems. However, the radios should be much more reliable then they are. The power connections are just friction locks - and that will never work for FIRST, especially a game as rough as Breakaway. To make things worse, that button on the top can press itself and cause problems, so disabling that in the firmware might be a good idea.

And, of course, I hate the Cypress comm. Totally sucks. But that is for a different thread.

I’m fairly certain we already used six separate access points. I’d imagine they’re on different channels as well. The 5GHz range provides 19 non-interfering channels in the United States.

If FIRST could pull this off, my entire team will videotape ourselves giving a round of applause and send it to the engineers responsible. :smiley: