New team new coder. Very basic non-PID code to limit arm travel using a V5 rotation sensor. VS Code; V5 extension; Python. The strange 94 to 184 degrees range is on purpose, because we hid the 0 degree point outside our travel range to not deal with the flip of the values. On the way down, there is very primitive “slew rate” control so arm slows down and does not slam. Code works in testing 100%. You hold L1 arm goes up, stops at limit. You hold L2 arm goes down, motor stops at limit. This code is part of the driver control and is inside of the while True: loop. There are no waits to ease processor as the way we understand this works in Python is that the scheduler takes care of the threads getting their time shares.
In tournaments, rarely (probably once every 3 matches) but with meaningful consequences things break in a weird way: L1 does nothing and L2 wants to ram the arm into the ground. One time team even came out of a match with a destroyed red motor cartridge. This is the first time we saw something like this. We took it apart and the entire inside plastic inverted gear (the wall of the case) was completely mangled. Checked logs and no sensor disconnects were recorded. Would not even make sense as a value of zero or NULL should not have this effect and with a transient parasitic values error things should come back and work again.
@jpearman : While the logic for buttonL2 was indeed incomplete, it never explained why during matches all of a sudden buttonL1 stops reacting completely. We printed bigger numbers on the screen for telemetry tracking and noticed that when this happens, the rotation sensor value jumps to a large number outside the programmed range. Sometimes an orange screen also appears saying there are multiple disconnections. But it’s never the rotation sensor that’s disconnected (mostly the IMU and we have an optical sensor - with that one, both constantly disconnect even after replacing cables, changing dead blinking ports and ziptie-ing cables). There are times when the disconnects do not generate an orange screen but they are present in the logs. It mostly happens in intense battles and when jumping hard over the barrier so it’s definitely electrical connections related. Question is why is the rotation sensor not reliable? After an unplug and replug it seems to remember the original position. Super frustrating.
obviously if the rotation sensor is reporting a number > 184 then that code will never trigger.
what was the large number reported ?
It is reliable.
but that assumes your physical connection to the sensor is stable.
An electrical disconnect of < 1 second will not be reported as a disconnect in the vexos log. A disconnect of < 250mS will not be detected by the user code device manager, if that happens we will not understand that internal variables perhaps need to be reinitialized and you may well get unexpected values.
code has to be written with the expectation of input data not conforming to bounded values. All sorts of errors can happen if you don’t do that, think of exploits using buffer overflow or SQL injection.
yes, that’s exactly what you would see if the rotation sensor lost power for a short amount of time. vexos decides a device is lost if not available for > 1 second, but a device that is reset due to power loss will still cause vexos to log that a device was connected.
100%. Best real life example I can think of is the Boeing 737 Max where engineers tried to “fix” a mechanical balance problem they introduced when they moved the engines and messed with the plane’s ability to glide, by correcting with airfoils controlled by IMU sensors and some software. It worked until it did not and many lives were lost.
My team thinks they found the potential cause of the micro-disconnects. They believe when the arm was at rest a piece of metal was touching smart cables by the brain area. The more brutal aspect of this year’s game really jolts those wires and connections constantly. They rewired everything and used the ports on the other side of the brain. Also they took your words at heart and rewrote the code to account for possible disconnections or sensor malfunctions. They basically have a “limp mode” which allows total manual control without soft limiters when values stay 0 or are outside the “nominal” range but at lower speeds so to not slam the arm by accident.
This is the part that I’m a bit bitter about. I understand we are trying to prepare these kids for real life stuff (see my 737 Max example) but the disconnects take the fun of exploration away and make students less confident in using sensors on their VRC robots. Yes, the V5 sensors are pretty fantastic. Everyone moans about how bad the IMU is and how their robot spins out of control etc. Coming from the old school RC world, i think it’s one of the coolest and reliable MEMS sensors.
However, I still think the weakest point of the entire V5 system has been and still is the 4P4C connector and most of our problems come from that. Triports with their silly ancient but proven connectors don’t fail. The “smart ports” constantly do. I’m sure extensive testing was done at the time of developing this but you have not met my driver.
I tried to reproduce this and failed. quickly disconnecting and reconnecting the sensor shows the log entry as expected, but the “angle” value always came back the same with the sensor configured in either normal or reversed configurations, so I have no idea what was happening there.
Will try to pay close attention and document better next time it happens. It’s usually in matches and everyone runs around there is no time to sit and analyze. One crazy thought I just had. Is any kind of RF or EM interference with the signals absolutely not a factor? Only asking because the arm in question has 4 air cylinders mounted and when the alleged contact with the smart cables was (is?) happening, it is the base of those cylinders (ferrous alloy?) making contact and it is also really close to the physical brain ports themselves.
