As we head into a new season, I see there is already discussion on which sensors to use and some thoughts on whether to use IMEs or not.
It is a fact that the IMEs have caused problems over that last 18 months. Most, if not all, of these problems are now well understood and considerable time and effort went into improving the firmware (for ROBOTC) to address the intermittent boundary conditions. Some of the improvements are detailed in the change log for ROBOTC version 3.60. I also posted thoughts on how to best work around other situations in this thread.
Don’t give up on the IMEs, upgrade to ROBOTC V3.60, understand their limitations and plan accordingly. They do allow encoding in areas where it is hard to use the alternatives, they really are a good sensor.
The one paragraph summary is that if the IMEs are disconnected or have communication problems, the count will either freeze or be reset back to zero. If the cables to the IMEs are installed with some thought so they are not disturbed during normal robot operation, potential connection problems can be minimized.
Is it true that having the motors far away from the field tiles reduces the risk of ESD issues? 24C observed this and I wonder whether anyone else came to the same conclusion.
With elevated drives to get over the bump (in addition to the new firmware, which we will definitely try out) I think this will be less of a problem this year.
Since all the patches and workarounds, I have grown rather fond of the IME’s (But I still leave space in my designs for quadratics just in case things go south…) so I’m not going to give them up unless they become an apparent problem again.
As iAndr0idOS said, that was a bit obvious, but I do agree. I’m hoping we’ll get an official firmware fix before the season starts, but I’ll still plan on including Quadrature Encoders (take the average for 2x accuracy! woo! :p)
Neither the IMEs or user processor need a firmware update (well, perhaps the IMEs could use one but that’s not easily done), the master processor needs a firmware update to be able to handle any situation where the user processor crashes so the motors do not run without being able to be disabled. I realize that the IMEs tend to make the user processor more prone to ESD, and therefore more likely to crash it, but it’s not really an IME specific problem, many things can crash the user processor. The watchdog timer that was implemented in ROBOTC V3.60 is a reasonable workaround for not having new master firmware.
Sure, it probably is (although they are all busy with Vex IQ for now so who knows when it will emerge) but it will not improve IME operation, it will only fix the bug where the cortex becomes unresponsive to field control when the user processor crashes.
Now that summer is upon us, I can try a few things I meant to with the IME’s. The humidity is higher so I wonder if we will see all the electrostatic discharges we saw in the nice dry, cold rooms of winter.
81M had a dickens of a time with resets and could almost cause them upon command. The motors were right above the ground and used the small omni wheels so it was close to the tile. You scrape the floor with sacks using a big polycard plate, then hit the metal side of the wall was the easiest method. Path to ground established! Other teams that used them on the lift motors did not have problems. So maybe the proximity to the tile is a factor.
I have upgraded to 3.61 of Robot C and will try and we’ll see if that effects things with the fixes in software but given the tap to the side wall, it seems like a voltage thing to me.
Next up is to try some ferrite cores around the wire for signal noise reduction and assembling something with TVS diodes to fast clamp the heck out of the signal. I bet a little board at every junction would help but I bet one at the Cortex end would be the minimum. If it works, then we can talk about getting these legal for competion if we can show a reduction is static discharges.
If all that is still not helping, then we give up…