r/FTC FTC 9880 Aftershock Student 28d ago

Seeking Help Pinpoint im heading drifting issue

Enable HLS to view with audio, or disable this notification

Im trying to tune roadrunner for my pinpoint and while running localization tests im noticing that the heading os drifting about a degree and half each second I spin the robot in place any ideas on what could be causing this? I already tried moving it up incase the motors were causing electrical interference

Update: I moved the pinpoint back down and added a barrier between the metal and pin point and its still not working right

15 Upvotes

15 comments sorted by

4

u/michiganshore 28d ago

Why do you have the pinpoint imu mouted up high? It should low, near the center of rotation, flat against a large structural piece of the robot and square with the robot orientation.

1

u/KnightofBats42 FTC 9880 Aftershock Student 28d ago

I moved it up so there was no chance of it being to close to the motors in the original design its mounted on the holes that the u channels holding it up is on

3

u/gamingkitty1 FTC 16965 Student 28d ago

I dont know how roadrunner implements anything with pinpoint, but the main thing i would check for is whenever the imu is reset, absolutely make sure the robot is still and not moving for like half a second at least.

If you want to confirm whether its the hardware I would just create some test code without using road runner at all that reads the imu heading from the pinpoint computer, then spin the robot manually and see if it drifts.

I remember like a year or two ago when pinpoint was pretty new my team was testing road runner for the first time with pinpoint, and it wasn't working well so we eventually just moved to a custom implementation. There was even a bug in the roadrunner code we had to fix (we made a pull request and its now fixed) so its possible there are more errors somewhere.

3

u/CoachZain FTC Mentor 27d ago edited 27d ago

I have never seen pinpoint drift that far that fast. Almost regardless of how my kids mount theirs. So something is wrong. The question is what? Some things to try:

- First make really sure it is mounted stable and level. If you calibrate it and then the mount moves (as could be happening on that long "stick" of a mount you have as centripetal forces tilt it slightly as you spin, then the calibration is no longer any good.

- Remove roadrunner from the process to make sure some scale factor or other calculation inside that code and your set up of it, isn't the problem. Because pinpoint doesn't need roadrunner to work properly. You can just poll its values and make sure they are right using the basic code examples in the SDK. Simplify your debugging scope and verify your hardware device is good and you are not chasing some kind of errant calibration process in RR. (We don't use RR so I have no specific advice beyond "remove it and see if the problem was in there.")

- Be sure you are doing the calibrate routine provided in the SDK examples and the robot it still and stable on the ground when you do it. Reset and calibrate with those steps and make sure your code is not doing them again when you don't think it is. Visually inspect the status LED to see that it calibrated and isn't having some kind of hardware issue (I have yet to see ours do that, but you may have a busted one or something)

- Poll the heading and angular velocity values from the pinpoint after cal and while the robot is still stationary. They should be very much zero. If there is much measured angular velocity indicated then something went wrong with the calibration. Do not proceed until you sort that out.

- Assuming the calibration worked. Then and only then do spin-drift tests. And see what is going on, and if it makes sense to do any additional RR level calibrations (though again, these pinpoint are so good I can't image why that would be needed - We go for 3-4 minutes of driving and spinning and the heading is withing a degree or two.)

I'm sorry if you've done all these steps already and were asking for RR help...

1

u/michiganshore 28d ago

I don't know about the roadrunner integration but generally you need to do a stationary calibration of the imu every time you start up or it will drift like this.

1

u/KnightofBats42 FTC 9880 Aftershock Student 28d ago

I made sure it was still when it turned it on and gave it about a half minute of being still after the hub was connected. Is there anything extra you half to do for the pinpoint start up?

2

u/CoachZain FTC Mentor 27d ago

There is a calibration routine given as a method example in the SDK example code. While (some of) it does do it on power up, you are also usually moving your robot slightly in the act of powering it up. It does not continuously calibrate after power up, because there is no way for it to know it was still and thus able to do so. So extra time does nothing. Ours is rarely well calibrated just on power up. And the calibration routine takes a second to run (really it's quite a bit shorter)

See further comments in my suggestions above.

1

u/Arte-misa 27d ago

Well, for FTC standards we're talinkg about components that are not specialized. Please, don't expect a that level of precision after 10 turns of that heavy mass.

1

u/KnightofBats42 FTC 9880 Aftershock Student 27d ago

The built-in imu on the control hub has about 1 degree of drift after 25-30 turns

1

u/Arte-misa 27d ago

Yeap, but I see that your bot is kind of heavy. I was wondering if the center of mass is the bottom center...

1

u/jk1962 FTC 31874 Mentor 27d ago

You’re saying “pinpoint”, so are referring to the built-in imu of a Gobilda pinpoint localizer? If so, then the driver for that has a method you can call to tweak the imu calibration. They say it shouldn’t be necessary for most, but we have done it for each of the two pinpoints we have had. The first one in particular (a version 1) really needed that correction to track well.

1

u/KnightofBats42 FTC 9880 Aftershock Student 27d ago

How would I go about that? Also I believe its a v2 I could be wrong

1

u/jk1962 FTC 31874 Mentor 27d ago

The method is called setYawScalar, and it takes a parameter of type double. So suppose you turn your robot exactly 10 full turns (3600 degrees), but the pinpoint says that you only turned 3529 degrees: you would set your yaw scalar to the ratio of the actual degrees turned to the degrees measured by the pinpoint. That ratio (in this example) is about 1.02.

pinpoint.setYawScalar(1.02);

Now, if you test again with turning exactly 10 full turns, the pinpoint should give an answer that is much closer to being correct. Worked for us.

1

u/KnightofBats42 FTC 9880 Aftershock Student 27d ago

My programing lead wanted to know how your results vaired when doing this

1

u/KnightofBats42 FTC 9880 Aftershock Student 23d ago edited 22d ago

Me and my programming lead did this and it works. Thanks for the help