Reference thread: https://vexforum.com/t/file-upload/38548/1
by mman454:
I mentored a student recently for a similar “timed driving” program: do a double figure-8 around colored floor-tiles, using code very much like yours.
Has your teacher done this exercize successfully?
If you succeed, it will require a large component of random luck in tweaking!
The class room battery set is not fully charged, and the response of the robot to the battery voltage will change every timing needed, every time.
“No sensors” means open-loop, so there is no feedback to the program to show how the robot has moved. On the next run, the battery will be less, so the distance will be less.
One of the problems is “instant on/off” of the motors: if the driving surface slickness varies, the wheels may skid some of the time when starting and stopping, which will divert the robot from your intended path
++ One brainstorm for helping this is to ramp up and ramp down the motor speed more slowly. Speed updates more often than 20ms or so won’t take effect. May not be necessary if you have a clean & uniform driving surface.
If you can rebuild your robot (don’t have to use a specific classroom design),
++ you could try using the differential advanced gearset. This makes one motor drive both wheels at the same speed. The other motor will make the wheels turn opposite directions, so you can drive straight and turn more precisely. Thats the theory, I’ve not tried it.
To deal with battery weardown, these programming ideas might help:
- you could update your program to use named constants instead of numeric constants for all time values. That lets you update all times for “drive straight 2 feet” with one program change.
- You could also include a floating point multiplier to represent battery power effects. "scale all times by this value 1.01 to make 1% longer, or by 0.99 to make 1% shorter.
- Operationally, you can make all your times a little too long, (drive too far, turn too much angle), and then keep retrying until the battery wears down to the right value that makes your program work.
I can only hope that the lesson to be learned in your class is:
“Open-loop is bad due to variation beyond my control, Closed loop is better”
In the Era of cheap powerful electronics, closed loop is cheap and provides robust yet cheap solutions: Class D audio amplifiers are an example; one bit resolution output, but get 24bit feedback to correct the output. Or in Cody’s words: “Throw a ton of programming at it, rather than build higher quality joystick mechanics”
This same topic also applies to competition robot autonomous modes: Closed loop feedback with line-sensors, shaft-encoders, ultrasound, (college: 9 dof movement trackers, optical mice tracking the floor, Beagle-board cameras) should allow much higher repeatability. Even with all that, it seems like it will be hard to deal with open-loop crash-bots.