Coding mentor, trying to help my students with some rudimentary auto code.
We have 4 falcons in our drivetrain, just trying to do some simple drive-to-distance stuff.
Have tried a couple variations of code to get position values, but not seeing results I can explain.
We’ve reset the factory default config in Phoenix Tuner and when we self test the Integrated sensors return no faults, say they’re returning 2048 ticks per rev and the position values seem reasonable if we move the drivetrain and test again to update.
In code, we’re instantiating the WPI_TalonFX controllers, and calling the getSelectedSensorPosition() method to get the current encoder position.
Our gear ratio is 15:1 and our wheels are 6 inch wheels (18.85" circumference). So to get how many ticks per inch, my math (based on the 2048 number in Phoenix tuner) was:
(2048 * 15) / 18.85 = ~1630 ticks per inch traveled.
Testing is showing as measured is more like 800 ticks per inch.
Does anyone have a guess at what we’re doing wrong or see the failure in my math? Is there a configuration setting I need to change to get either 2048 or 4096 tick per rev?
HELP! The students are looking to me for answers and I am struggling to provide an explanation.
Thanks in advance. Hopefully there is a simple explanation.
What exact testing have you done? A test you could try is to lay out a tape measure 100" out, starting at a reference point on your bot (ie. back of chassis), then push the robot straight 100". Divide the # of ticks by 100 to get ticks per inch. Your 1630 number checks out for me.
For the testing we’ve done, we’re using the “Low Gear” - so the 15:1 ratio is accurate (and I did double-check that with lead mechanical mentor). Drivetrain is 8-wheel west-coast style. 2-speed transmission with 2 falcons in a master/follower config on each transmission.
The 3-CIM version of this - WCP DS Gearbox - VEX Robotics - in a 2 motor config.
The testing we’ve done:
Marking off known distances (20", 50") and measuring the values we get when moving the bot manually.
Setting drive-to goals based on the math and measuring how far we actually go, then adjusting the math as needed.
I think we can make it work by putting in a fudge-factor, but it bugs me that it is necessary.
You’re correct in assuming it’s a 2048 unit per rotation sensor, make sure you’re not calling configSelectedFeedbackCoefficient to change it.
Also, since you’re off by a factor of 2, I’d suspect there’s something very odd going on.
Typically in situations where the unit conversions don’t make sense, I try to find ways of verifying each step.
My first guess is the 15:1 ratio. I would verify by marking the wheel with a sharpie, and rotating it exactly 1 rotation, measuring position before and after the rotation. It should be 2048*15=30720.
My second guess is wheel diameter, I would drive it manually slowly about a foot or so, maybe limit the output to only 10% to ensure no wheel slippage. Again measure before and after and verify.
Third guess is slippage, I would autonomously run it or manually drive it faster to test against it.
If the first causes issues, we know it’s not really 15:1, if the second causes issues, the wheel might not be 6", if only the third causes issues, it’s probably slippage.
At our next practice I will try to do some of the testing you have suggested. I measured the wheels tonight and it should be within tiny fractions, but I was measuring diameter and there could be error (measurements showed diameter within 1/16"). I don’t believe there is enough slippage to account based on observation (we’re moving pretty slowly so should be minimal - less than an inch) but will test.
For what it’s worth – I’m willing to question everything and appreciate all of your responses. We will double check that our configSelectedFeedbackCoefficient hasn’t been altered.
Thanks to all who have commented for trying to help. I appreciate the coopertition.
When we first start characterizing our drivetrain each year (and in the off season to teach) I always have the students put the robot up on blocks so the robot doesn’t actually move, and that any mechanical characteristics (like center of gravity, wheel alignment, etc) aren’t affecting my testing.
The first test I have them run on the blocks is to manually rotate the wheel as close to 1 rotation as possibly to see if our tick count matches our expected tick count.
Once we have everything done correctly and have gone through the Bring Up process in the CTRE documentation.
If you want to mess around with a different test, you can use our Simulator Base project. It’s a 4 falcon WCD, you can just change around the constants calculations from the kit of parts chassis (10.71:1 ratio) to your own and see if you get expected results in the simulator as well.
And for sanity check, here’s our quick set of calculations on our robot. We have 6.5" diameter wheels (including the tread) so you’ll see 6.5" in the numbering, and we’re using the KOP toughbox mini gearbox with a 10.71:1.
And therein lied the problem – all of you saying it sure sounds like gear ratio is off, you were correct.
We did the bench tests suggested and the math kept coming out making sense and I couldn’t figure out what the problem was. Then I reversed the gear in auton and everything started working correctly.
The code to shift the gears had been implemented without testing which direction on the solenoid matched up with low/high. When we were bench testing everything came out correct because the buttons on the controller to change gears were also opposite of definition, tricking me into thinking the ratios lined up.
I knew it had to be something dumb.
So, thank you all for your helpful suggestions. This is what can happen with inexperienced coders, but that’s why I’m here to help them. This slice of humble pie doesn’t taste great, but I will sleep easier knowing that determinism does exist in mathematics and coding.
Kind people helping internet strangers epitomizes Gracious Professionalism. May you all have a fantastic season.
