So I want to try and develop some code that would constantly check the motors and sensors on our robot, and make sure we’re getting a signal from them, and in the event that something goes wrong (unplugged wire, ripped wire, busted motor controller) the robot would display a message on the LCD Display (something like “No signal on motor port 1”) and flash an LED indicator/play an alarm tone on the VEX speaker. I can probably figure out the last two parts, but how would I be able to poll the motors and sensors to check for a signal? Would it be too resource-intensive of the cortex?
I know nothing about PROS (sorry) so I don’t know if there is some way to poll a motor, especially if it does not have a sensor connected to it for feedback or can not be moved because it is in a stowed configuration, but I’m just curious: is this a capability you envision being in use up to and including while you are setting up your robot on the playing field? or is this more like something you want to have in your pit for a quick full system check-out?
By the way, most tournaments I’ve been to are so noisy, I’ve rarely been able to hear the beeping of a robot on the field. I would stick with visual indicators if I were you.
I’ve been to a lot of tournaments and played plenty of matches where we ended up losing because either something got unplugged between matches and/or we forgot to hook something back up after we made repairs, so the goal of this is to reduce human error as much as possible. I’d probably end up using it for both, while in our pit area and once we place our robot down on the field before we plug in. It might be a function that takes place before the robot switches into Teleop, so that it doesn’t do it the entire match. Call it the “Checklist” phase.
I hear you about the noise, but still, it’s nice to have more than one type of red flag going off (LED intensely flashing, LCD displaying that something’s wrong, and ear-piercing alarm that won’t go away until you fix it!)
It would not be too resource intensive for the cortex if the hardware had that capability, however, it does not. There is no way to detect if any of the motors are actually connected, the closest you can get is to monitor IMEs (or I guess other sensors) and assume that lack of feedback from them means the motor is not moving.
It is possible to check for presence of some of the sensors but not all.
Aw…I guess we gotta stick with manual checklists then. What about the sensors, though? could I have something that checks if a potentiometer is plugged in or not? (Bad pseudocode inbound)
Potentiometer
Gyro
Accelerometer
Line sensor
light sensor
These are all analog sensors and (surprise) plug into the analog ports. When any of these sensors is unplugged the analog input will “float”, that is, the internal resistor network will set a default analog level. In ROBOTC (which uses 12 bit A-D conversion, max value 4095) they will all read as about 250 so if you read that value in that general area you can assume the sensor is unplugged (unless the pot is set for this value in its starting position).
Bumper switch
Limit switch
These are normally open sensors, you cannot tell if they are unplugged. I would have set these to be normally closed and then it would have been possible to check for them being unplugged.
Quad encoder
tough to test for this as well without moving it.
Ultrasonic.
You will get maximum distance if either input or output is disconnected.
IMEs
You can detect an unplugged IME cable in ROBOTC and ConVEX, not sure about PROS, I don’t think so.
So perhaps I could have the cortex check and see if the sensors are within acceptable bounds (if we have our lift, and the potentiometer is reading 4095 when we’d usually have it at 300 or so) and then for the encoders, I could have a drive team member pick up the robot while the cortex runs the motors for a second to see if the encoders count anything at all (one could probably apply the same thing for IMEs, even though we don’t plan on using IMEs in our design)
For the push buttons and limit switches, we could have the robot ask us to check them, and if they get a low signal, they move on to the next part of the checklist.
It’d sorta be like the robot guiding itself through a checklist, but we’d still have to check the motors. Not what I originally had in mind, but it’s still great for helping to reduce human error and making sure we don’t lose the match because of carelessness.
Thanks for the help! I’ll be sure to play around with this when I get a chance.
One other thing that has caught me out in the past.
consider the following scenario,
A sub-system is driver from the power expander, say an arm.
The backup battery is used.
A potentiometer is used on the arm.
The main cortex power is turned off.
What can happen is as follows.
The cortex processor is still running due to the backup battery.
The arm motors can be driven due to the power expander.
The potentiometer returns an invalid value (250) due to the fact that the main cortex power is removed and the 5V output is now disabled.
An arm control loop can move the arm into a position where it can damage itself due to the “bad” pot reading.
I don’t know if you can set motors to do stuff in pre autonomous in PROS, but if you can, you could make a simple test sequence where when you activate it, it would lift for 1 second, intake for 1 second, and drive for 1 second and then return to the original position.
My team usually just looks at the connections before every match and makes sure they are all connected firmly with tape and usually zip ties. We also just quickly move the robot forward, lift the lift up and down, try the intake, and test the pneumatics if we have any (though we do this manually and not with code).
As for the sensors, I believe our programmer would connect the robot and go to debug mode before we went.
These methods are manual and not programmed, though, so if you want code that will check for you I probably would not know :(.