Things never work out exactly as you plan…
Navigating the robot field mat quickly and accurately is key to finding and solving as many missions as possible in our 2-1/2min rounds. Unfortunately, these two things (speed vs traveling accuracy) are at odds. Our motors and sensors as physical devices never behave exactly like their corresponding theoretical models we mirror in math and software. These devices become less accurate the more we stress them with increased distance, turning radius and power/speed demands.
On Tuesday we ran a few trials with our experimental robot rig to quantify the error between our theoretical expectations and experimental measurements for:
1) Linear Travel vs Power Levels (25, 50, 75 and 100%)
2) Angular Turns vs Power Levels (25, 50, 75 and 100%)
Solvi and David recorded the results in our notebook. The short of it is that, we cannot afford to go 100% or even 75% power without introducing measurable error. The greater the distance or turning angle, the larger the error that accumulates.
Even more shockingly, the Ultrasonic Sensor (US) was almost useless at medium to high power. The robot consistently rammed head on into a bare wall at full power despite settings to stop 5 or 6 inches (motor and sensor both at fault). Solvi did record some success as we lowered the motor power level to 15-20%, but it was surprising how ineffective the US sensor was.
We’ll have to look for ways to compensate and correct for these errors by using field landmarks like (1) walls for re-squaring, (2) line ends/intersections to recalibrate our robot’s internal map of the field and (3) software to programmatically compensate for errors with a consistent drift. For example:
– if our best matched drive motors introduce a slight pull to the right we might want to give the right motor a little more power or a few extra degrees turn at the end of a long straight run
– if our angular turns are consistently short for common turns we might want program a higher theoretical turn to achieve the correct physical turn (eg. program 51 degree turn to achieve a physical 45 degree turn). We may have to do this for all common angles we’ll need to turn (multiples of 10 and 15 degrees up thru 360). We may also have different values depending on if we turn Left or Right (eg we may need to program a 51 degree left turn to get an actual 45 degree left turn but program a 47 degree right turn to get an actual 45 degree right turn).
Once we get our final robot design, we’ll have to revisit this and optimize our accuracy vs speed (power) tradeoff. This will be a lot of experimentation, data collection and adjustments in our software model.