Motor commands and motor consistency
Ok...
Our school is new to Botball this year, with 5 elementary teams heading to the SO Cal competition tomorrow at USC.
I have been pulling out hair trying to reconcile the random reliability of the KIPR motors.
We have tried motor, mav, mrp, mtp commands, all with similar results.
Each run the motors have random responses. Sometimes one will rapidly jolt on initial run, causing the robot to take off tangent to straight. Sometimes one will run slower or faster than the other, again drifting away from straight.
Trying to compensate by simply adjusting values isn't working, because the next run the motors do something completely different.
I have tried using the clear_motor_position_counter command when using mrp, but still doesn't help.
I have tried adjusting motor PID values, first setting them to the "default setting" (listed as 30,0,-30,70,1,51) as found in the KIPR manual, but those values are WAY off.
Going into the LINK PID tuner the PID values show set at .4,.4,.05. Varying those values does not seem to help. I was able to induce jerky motors by increasing P to 2, but minor adjustments to the original values did not correct the initial jolt or discrepancy between actual motor velocities.
Any suggestions?
I did Botball for seven years and the motor problems you mention were always something we struggled with. I have not worked with the newest version of the Link, so I don't know how PID values would or would not change things, but I do know a few things about the way the motors work and how you might fix some of these problems.
The rapid jolt is by far the hardest problem you mentioned to compensate for due to the size of the jump and its inconsistency. The safest way to deal with this is to perform several sensor alignments (for example, using touch sensors to align with walls or top hats to align on tape) as soon as possible in the run to correct for anything that went wrong. Another potential solution is to run the motors at the beginning of the program during set up. I don't know why, but from my experiences, motor jumps seem to be most common at the first call to a motor during a program. By spinning the wheels a bit before setting the robot down, you will get that first call out of the way before hands off.
The varying motor speeds are easier because they happen every time. Each motor is slightly unique in how fast it can turn. If your robot is not perfectly symmetrical, the weight distribution will also impact your wheel speeds. This is correctable. My teams found that the differences between each motor are fairly constant at different speeds. In other words, the proportion of one wheel speed to the other is the same whether the wheels are moving at 50% power or 75% power. Let's say that your robot has its wheels in ports 1 and 3 and it drives straight when you call:
motor(1,50);
motor(3,45);
msleep(5000);
ao();
it should also drive straight when you call:
motor(1,100);
motor(3,90);
msleep(2500);
because motor 3 is 90% as strong as motor 1.
It is also worth noting that motors become less reliable at higher speeds. Better to take longer to get where you are going than to move quickly and miss your target. Additionally, each function has a maximum value for speed. If you go over it, the function just works with that max value. So:
motor(1,100000000000);
motor(3,6000);
would drive both motors at max capacity. Any turning would result from the differences in you motors rather than your code.
There is also battery power to consider. Motor works with a percentage. 100 says "spin as fast as you can" while 50 says "spin half as fast as you can". So if your battery is really low all of your distances will be wrong. For this reason I would recommend that you never use motor. Mav (move at velocity) works in "ticks per second" where a "tick" is the smallest distance a motor can spin. So long as there is enough charge to spin the motors as fast as requested, this will be much more reliable than motor. Extremely low battery levels can still affect it, but this is a fantastic function. Each motor is still different though, so
mav(1,500);
mav(3,500);
msleep(5000);
ao();
will still probably not drive completely straight.
mrp and mtp work very similarly to mav in that they also move using a "ticks per second" value that counteracts some of the battery problems. Any time my team wanted to drive a certain distance we would use mrp.
I hope that this is helpful. It has been a while since I have programed a bot and this forum doesn't have a compiler so there may be bugs in this. If someone finds this and sees one, don't hesitate to correct me. Well, hesitate just long enough to be sure you are right I guess! I loved my time in Botball and hope that your students stick with it all the way through high school. Technical problems like this can be infuriating, but there is nothing like the satisfaction that comes from a robot you are proud of. It was always worth it (even when we never got the bot where we wanted it). I wish you all the best of luck at this tournament and in the rest of your Botball careers.
-Daniel Goree
Former...
Senior Project Manager
President
Norman Advanced Robotics (13-0113)
You may wan to read this thread. Has a lot of useful information http://community.botball.org/forum/technical/programming/using-motor-tic...
wow. that's troubling.
sorry, i'm late, but there might be a problem with the software.
Have you updated your link firmware/kiss ide ware?
I have been looking around for any kind of web link to download or view kiss link documentation. I'm talking about the giant .HTML documents. This is normally accessible from inside the kiss ide (via the help button), however I do not believe I can open that on my phone. If there is no copy of the documentation online, then is there anything wrong with me putting it online?
ahsan
A debt of gratitude is in order for setting aside an ideal opportunity to talk about this, I feel firmly about it and love adapting more on this subject. techsmarthere.com