Thanks Jared, that is insightful.
Then maybe all that is needed is a button for move forward slowly (so that hand jitter doesn't affect careful driving). Then when the bridge starts tipping, drivers could release this button and the robot would stop driving. The whole task might be simple enough for the drivers to control.
However, the brake function could be automated. I can see where the robot would need to be held in place. It might coast and roll if you just didn't drive the motors.
So, maybe a button as described immediately above, then another button enables a brake mode. This would likely need to be done with PID (and don't forget encoders). It would have to be very quick, responsive, and effective (read: not spike and move the robot too much as it tries to keep it still
) Could some effective code be done without PID? Maybe an extremely simple P function related to encoder displacement (still kind of PID related)? Maybe a relay-style go forward/backward at a very low constant speed based on slight encoder offset, just to hold the robot in place (like while the bridge is tipping but still angled). This could be an electrical issue by stalling the motors, if you know that driving the motors at 0.01 speed will hold, but not move the robot.
The button for brake could be pressed independently of the first, that is, it overwrites whatever the first button is doing. This way the drivers don't need to think about letting go of the first button during that critical moment when the bridge starts tipping. They just need to focus on mashing the brake button.
Oh, and a slow reverse button, similar to the first, would be handy too if the robot went to far and tipped the bridge forward. Wouldn't want to turn the robot around just to use the same "drive forward slowly" code.
Thanks everyone, this is an interesting and helpful discussion. What other ideas are there? Do people still think it's worth using a sensor?