Robot Calibration
Not connected
The code holds the numbers for every robot. Each step below measures one of them; Tune this robot tries a number live and saves it on this robot, so it keeps its own corrections without flashing.
Flash calibration.ino and turn the robot on. Tap Bluetooth and pick your robot.
Change a number, tap Try: the robot uses it at once. Happy? Tap Save to the robot: it keeps it, even switched off, over the code's number. Works with the driving program too.
Every number the robot drives with, as it has them right now. Try sends one to the robot's memory; Save writes them all to the robot's EEPROM, which survives power-off and uploads; the robot reads them at power-on instead of the code's numbers.
Robots differ, batteries differ, floors differ. The code holds the numbers that fit the fleet; each robot keeps its own corrections here, set from the steps below or by hand.
The steps below (5 to 10) each measure one number and show the value to put in; type it here, Try, check, Save. Back to the code's numbers forgets the saved set and the robot runs on the code again. The header of this panel says which the robot is using.
Put the robot on the floor, battery charged. Stick a piece of tape on the floor at one front corner.
Tap Find it. The robot spins for a moment, then asks you a question. Answer it. It spins again, a bit stronger, until it turns the robot 3 times out of 3.
The start power: the smallest power (0 to 255) that turns the whole robot. Below it the motors only hum.
Every move starts with a jump straight to this power, so all four wheels turn from the first moment (a wheel that does not turn makes the robot twist as it starts). Turning in place needs the most push of all moves, so its start power works for every move.
Each test spins all four wheels at one power for 0.6 seconds. "Yes" means the whole robot turned at least 2 cm away from the tape: humming does not count, one wheel creeping does not count. It goes up 5 at a time; a power counts once it turns the robot 3 times out of 3 (near the edge a power works only sometimes, and the robot needs one that always works). Tired batteries need more: put a few more in the code than it found.
The number goes into the code as CURVE_LOW_PWM, and one less as PWM_DEADBAND (anything below that is "off").
After the new number is in the code and flashed: it spins 3 times at the code's start power, and each must turn the robot. Then 2 times at 5 lower, just to show how close to the edge the number is.
You need about 2 metres clear in front, and a tape measure. Put a mark on the floor at the robot's back edge.
Tap Run 2 seconds. Measure from the mark to the back edge, in mm. Put the robot back on the mark, tap Run 4 seconds, measure again.
How fast the robot really goes at its start power (step 2): its slowest speed, in mm per second.
Slow moves run at exactly this speed, and the robot works out how long to drive from it. If it believes it is faster than it is, every move falls short; slower, every move goes too far.
Both runs are the start power on all four wheels (no ramps, no corrections). Getting going and rolling on after the motors stop add the same bit to both runs, so the difference between them is pure speed: speed = (4 seconds distance - 2 seconds distance) / 2 seconds. That bit itself is the next step.
Work it out compares the result with the number in the code: within 5 % it is VERIFIED; otherwise it shows the line to put in the code (SPEED_AT_LOW_PWM, in both sketches). After flashing, run both again and Work it out: it should say VERIFIED.
You need about 2 metres clear in front. Mark the floor at the robot's back edge. For each power, tap 1 second, measure, put the robot back on the mark, tap 2 seconds, measure.
How fast the robot really goes at half power (128), three-quarter power (192) and full power (255). With the slowest speed from step 3 that is the whole speed curve.
Motors are not straight lines: half power is a lot more than half speed. The robot picks a power for every speed it needs from this curve, so every move and every turn depends on it. It also lets programs drive at a steady power instead of the stall edge, where speed wanders 10 % or more from run to run.
As in step 3: speed = (2 seconds distance - 1 second distance) / 1 second, so getting going and rolling on cancel. Work it out compares the three speeds with the code: all within 5 % is VERIFIED; otherwise it shows the three lines for the code (both sketches).
Do step 4 first: this one only holds still once moves run at a steady power.
Mark the floor at the robot's back edge. Tap Drive 1 metre: the robot drives the way a program does. Measure from the mark to the back edge, in mm.
How many milliseconds early (or late) a move cuts its motors so that it lands on the target, allowing for the motors taking a moment to get going and the robot rolling on after they stop.
Those two add the same few centimetres to every move, long or short. Step 3 measured pure speed; this makes the ends right too.
This is a real move (m0,1000,0: 1 metre at the program speed, with the robot's own timing). Went 930 for 1000? It is 70 mm short: at the slowest speed (step 3), which a move ends on, that is 70 / 249 = 0.28 s, so the number goes down by 281 ms (negative means the motors run late). Work it out shows the line for the code (SPIN_COAST_MS, both sketches). After flashing, drive again: within 2 cm of 1000 is VERIFIED.
Put a strip of tape on the floor along the robot's nose, pointing the way it faces. Tap Turn: the robot turns right a quarter turn, 4 times, and should face the tape again.
Where does its nose point now? Write how many degrees past the tape (+) or short of it (-). One clock minute is 6 degrees.
How far the robot really turns for the turn it is asked: the spin factor. Mecanum wheels slip sideways while the robot turns, so it turns less (or more) than the wheels alone would say.
Every turn in a program uses this number. Off by 10 % and a square is not a square.
Four quarter turns (the robot's own turn, as a program does it) should come back to the tape: 360 degrees. Ended 42 degrees past? It turned 402 for 360, so the spin factor goes up by 402 / 360 and the robot asks for less next time. Work it out shows the line for the code (SPIN_EFFICIENCY, both sketches). After flashing, Turn again: within 5 degrees is VERIFIED.
You need about 1.5 metres clear to the robot's right. Mark the floor at the robot's right edge. Tap Slide right 1 metre. Measure from the mark to the right edge, in mm (straight sideways, even if it also crept forward or back).
How far the robot really slides sideways for the slide it is asked: the strafe factor. The rollers slip sideways, so the wheels have to travel a lot further than the robot moves.
Every sideways move in a program uses this number, and so does every diagonal.
A real 1 metre slide to the right (m90,1000,0, the program's move). Went 850? The factor goes down by 850 / 1000, so the wheels travel further next time. Work it out shows the line for the code (STRAFE_EFFICIENCY, both sketches). After flashing, slide again: within 3 cm of 1000 is VERIFIED. The robot may creep forward or back or twist a little while sliding; that is a later step, not this number.
Put a strip of tape on the floor, about 1.2 metres long. Put the robot on the tape, facing along it, its middle over the tape. Tap Drive 1 metre.
Where is the middle of the robot now? Write how far it is from the tape, in mm. Right is +, left is -.
How much stronger one side of the robot is than the other. Each wheel gets a gain: 1.00 is normal, 0.97 is a bit less power.
If the left wheels are stronger the robot curves to the right, and the longer it drives the further off it gets.
A real 1 metre drive. Ended 45 mm to the right? The left side is stronger: a steady curve that far over 1 metre means the sides differ by a few per cent (worked out from the spin factor and the wheelbase), so the left wheels get a little less power and the right wheels a little more. Work it out shows the line for the code (WHEEL_GAIN, both sketches). After flashing, drive again: within 2 cm of the tape is VERIFIED. Still off? Work it out again: each round gets closer.
A twist in the very first moment (the wheels breaking away unevenly) also shows up here. It is small at this speed; if the robot ends up off the tape by the same amount whether it drives 20 cm or 1 metre, say so.
Put a strip of tape on the floor going across the robot, under its middle, about 1.2 metres long to the right. Tap Slide right 1 metre.
Now two things. Which way does the nose point: how many degrees it twisted, + if it turned to the right (clockwise), - to the left. And where is the middle of the robot: how far from the tape, in mm, ahead +, behind -.
How much more of the sideways push the front wheels need than the back ones. Sliding sideways, if the back wheels grip better (they carry the battery), the back pushes harder than the front and the robot twists.
Sideways and diagonal moves in a program all depend on it. It only touches sliding: forward drives and turns stay as verified.
Sliding right, the front wheels and the back wheels push sideways; if they push unevenly the robot twists (that is the only thing that twists it: a stronger diagonal pair makes it creep forward or back instead, which is the next step). So this step reads the twist. Sliding right, a front that pushes harder turns the nose to the right (clockwise), a back that pushes harder turns it to the left. Twisted to the left? The back pushes harder: the front wheels get a bigger share of the sideways speed and the back a smaller one (STRAFE_FRONT_BIAS: 0.064 means front 1.064 x, back 0.936 x). It takes half the step the twist suggests, because a big twist is not twice a small one. Work it out shows the line for the code (both sketches). After flashing, slide again: a twist within 5 degrees is VERIFIED, whatever the creep (the creep is step 10).
Tape across the robot under its middle, with room to slide 1 metre both ways. Tap Slide right 1 metre: how far is the middle from the tape? Ahead +, behind -. Put it back over the tape and do Slide left 1 metre.
Sliding, the robot creeps forward or back while holding its heading. That is one diagonal pair of wheels pushing harder than the other (a stronger front or back would twist it instead: step 9).
Sideways and diagonal moves end up off their line by it, whatever the heading does.
Sliding right, FL and RR roll forward and FR and RL backwards; sliding left it is the other way round. So two slides tell the two causes apart: creeping forward both ways means the motors are weaker rolling backwards (the pair rolling forward wins, whichever pair that is); creeping forward one way and back the other means one particular pair (FL + RR, or FR + RL) is stronger. Both can be there at once, and the two slides give both numbers: the share of the sideways speed taken from the stronger pair and given to the weaker. Work it out shows the lines for the code (both sketches). After flashing, slide both ways again: within 3 cm both ways is VERIFIED.