I’m drafting some code and was wondering if my formula for converting inches to ticks is correct. This is for a PID method that converts an input (in inches) to ticks that the motor can read.
The formula I have is in the picture:
By the way, if you’re using 4 inch omniwheels, the actual diameter is 4.125 inches.
3 Likes
As @1320D_Programmer said the wheels are not exactly 4" . Also, the rollers could move back and forth and their shape could deform depending on the weight of the robot and relative firmness of the foam tiles.
I would suggest to determine experimentally a conversion constant for your finished robot by driving it autonomously from one side of the field to the other and then measuring number of encoder ticks vs traveled distance.
Similarly you could program it to turn several times and then derive another conversion constant between encoder ticks and heading degrees.
3 Likes
All I do is have a variable called magic number that I tweak until it is correct
6 Likes
I like your magic logic 
Essentially, the same thing that I said in the post above, but short and without boring details.
2 Likes
Yeah, although the magic number can confuse judges because it appears allot in the code and you can’t easily tell what it does
1 Like
The magic words to replace the word “magic” would be “heuristic” or “experimental”. This will tell judges that you are using feedback from the real world with tests-based design process.
Although, if you list suspect causes for the experimental constants being different from the theoretical predictions, that would be impressive too.
Science is about building models of the actual world. Sometimes it is easier to experimentally determine mathematical relations first and that will point to the casual relationships. And sometimes it is the other way around: you figure out processes based on experience and reasoning, and then it suggests the math that could be applied for practical purposes.
For example, there could be a multiple physical factors influencing how something moves making it very hard to model and control, but if you just looking at the small linear region PID coefficients would be those magical constants that will let you to eh “magik” if tuned correctly.
On the other hand if your robot moves too fast and its kinetic energy no longer could be approximated by the linear Kd coefficient, you could struggle a lot to get it working. Then knowing what stands behind the magic numbers will help. You could either model robot’s kinetic energy as mv^2 or tune two magic Kd coefficients - one for fast path segments and another one for when you need to move slow.
1 Like
Is there not a way to convert it mathematically similar to how I have it set up, whereas the target is the inches being the converted and the new target is the amount of ticks. Ticks are a rotational measurement and inches are linear. I know how to convert rotational displacement to linear displacement (from rotational kinematics unit in physics), so I’m sure there must be a way to do inches to ticks mathematically. I’m not sure if what I did is entirely correct, and I also haven’t tested it on a robot. I would like a verification or another strategy of doing this however. Trial and error and finding a constant could work, but its also less effective.
@mvas you math is essentially correct, assuming that left hand side “target” is really “target_ticks”. I don’t remember if quad encoders return 360 or 3600 ticks per revolution, but that is easy to test.
What @224x was saying is for the specific robot of the specific weight and with specific possibly worn out omnis the conversion constant from ticks to traveled distance will be slightly different from theoretically expected 360/(4*M_PI).
One of our teams did it and it was like 3.something percent different from the expected value, I don’t remember exactly.
And another of our teams always measures everything in encoder ticks, which works just as well, given that they don’t change their robot. And if they change it then they retune all their autonomous routines anyways.
1 Like
I checked your conversion with mine. It is correct! Good job!
1 Like
Ahhh, I understand. We don’t live in a perfect world, therefore you must compensate for variability. I’m assuming the constant would be relatively close to 1, you would just multiply the output of ticks by that value to adjust for variability in the robot.
2 Likes