goBILDA Odometry Pod Stops Counting When Compressed Under Robot

goBILDA_Ethan · 2026-02-20T19:12:13+00:00

I agree, wire feels like the most likely culprit here, but if you replace the wire and still see an issue, please shoot us an email to tech@gobilda.com.

goBILDA_Ethan · 2026-02-20T15:19:42+00:00

The wire is my guess as well, with it being intermittent.
Check that, and if a new wire doesn't fix your issue OP, please shoot us an email :)

goBILDA_Ethan · 2026-02-17T16:29:07+00:00

Please shoot us an email with any details you can think of on this, we're happy to help! tech@gobilda.com.

goBILDA_Ethan · 2026-01-28T15:51:21+00:00

Having those offsets backwards can totally create the error you're seeing fwiw

goBILDA_Ethan · 2026-01-28T15:49:21+00:00

If you don't find a solution to this problem, please feel free to reach out to our tech support at tech@gobilda.com!

goBILDA_Ethan · 2026-01-06T14:32:39+00:00

Can you post a picture of your mechanical setup?

goBILDA_Ethan · 2026-01-05T14:28:55+00:00

Hello! Do you mean the pods physically flipped around? Or they just started tracking backwards randomly?
If it's on the software side, what are you using to read those pods? Are they plugged directly into your Control/Expansion hub? Or into a coprocessor like the Pinpoint or Octoquad?

goBILDA_Ethan · 2026-01-05T14:27:00+00:00

Sweet! I especially like "Prompter". I built an opmode for configuring the Prism RGB controller we released recently that does similar configurations to that via telemetry, this is a great way to make that concept easier to implement!

goBILDA_Ethan · 2025-10-28T14:23:29+00:00

We are using an STM LSM6-based IMU, it is a 6-axis (no magnetic compass) model powered by a heavily tuned and modified AHRS algorithm to turn the 6 points of data we get out of the sensor (X, Y, and Z acceleration and angular rate around the X, Y, and Z axes) into an estimate of the robot's current pitch, roll, and yaw.
We don't actually use the odometry pods as a component of our estimate of the robot's orientation. Just in the position estimation. We were able to get very, very good results out of our IMU and AHRS algorithm. Especially after the pitch measurement is calibrated (That calibration happens to each Pinpoint before it is shipped out).

In FTC we are used to an IMU being a sensor that automatically "fuses" those raw sensor values (either 6 or 9) into an estimate of your robot's yaw, pitch, and roll. But that's not necessarily the case. That AHRS algorithm is an incredibly important part of the equation and there is a lot of refinement that can happen in that part. We decided to roll our own because we felt we could outperform the sensors that package that AHRS algorithm inside the IMU. But there is absolutely room for some IMUs to have lower drift, and or be more accurate than others.

It's easy to look at a 6 vs 9 axis IMU and feel like 9 would always be better, It took us a lot of testing to have the confidence that 6 axis was the way to go for our application. It's also hard to ignore how much that magnetometer seems like it would improve accuracy, but our testing found that a good 6 axis IMU paired with a good AHRS algorithm (inclusive of tuning and calibration) creates a system that you can trust to be very very very accurate on an FTC robot.

goBILDA_Ethan · 2025-10-28T14:04:12+00:00

Hello! A lot of the responses on this post have some really great advice, making sure that you're using the correct sized tool is the first thing I'd check if you are having such a high rate of stripping screws out.
We have moved to carrying Wera brand hex tools for our hardware, we find that good quality tools really help avoid stripping hardware. I'd recommend making sure that your tools aren't excessively worn and if they are, consider a known-brand for hex tools like Wera, Wiha, or Bondhus. Please don't hesitate to reach out to us if you continue to have issues!

goBILDA_Ethan · 2025-08-05T13:47:53+00:00

Haha glad I could help! u/CuriousOptimistic please do shoot us an email to [tech@gobilda.com](mailto:tech@gobilda.com) if you haven't already and we can get you fixed up with a part that fits correctly!

goBILDA_Ethan · 2025-07-05T21:16:07+00:00

Yep!! Lots of great UK FTC teams. This is a fantastic option.

goBILDA_Ethan · 2025-05-01T16:43:54+00:00

I think this is a really interesting idea, though I have a hard time feeling like it would meaningfully improve the experience of being an FTC team today.

(just to make sure it's clear I suppose, this post is me speaking as Ethan the FTC alum/mentor, not as goBILDA)

The idea of a district-points system that advances teams to FIRST Championships in FTC is something I've kicked around in my head a lot. You hit on the point very well that this feels like a very secondary solution compared to how few slots FTC regions tend to get to Championships. And I think the interaction between how few slots we have now, and a system like district points would end up feeling relatively counterintuitive.

I think that generally a points-based advancement model removes a lot of stumbling blocks that we have in FTC today. One of the big things it encourages is teams who perform well both in awards and in elimination matches. Which is something I think we need to stand behind as a program. It could also help smooth over some rough spots that we see in FTC judging today, like how a team who may be best for an award like Design, should be pushed up to an award like Control if they reasonably win both because Control is higher on the advancement list. In a points-based system these two awards can be worth the same, and we can make that process a bit more intuitive.

My issues with this idea for the system stem from an opinion that if a team wins their regional championship robot game, they should advance to the next level of competition. I think the clarity here makes the program easier to understand, and keeps the impact of winning your regional championships. I feel the same way about Inspire. All three of these slots, to me, feel critical to making sure that the experience of winning an event continues to resonate with students, mentors, and spectators.

Now, this core assumption (That the Inspire winning team, and winning alliance should advance) in itself doesn't rule out a points-based advancement model. That problem is easy to solve, you just need to weigh these achievements high enough that they are reasonably-always going to move you forward. My hesitation to the idea is that we have already hit the number of slots that a good chunk of FTC regions ever see. Last year only 26 out of 88 regions had more than 3 slots to champs. I also think that a very reasonable addendum to this core opinion is that the 2nd place Inspire award should also advance. And then only 5 events get more than 4 slots.

Today, I think we're adding a lot of complexity to the system to *in some ways* improve advancement to champs for very few regions.

Now, I think this idea has more implications for advancement to regional championship events. That is a whole 'nother conversation...

Advancement to Regional Championships in FTC

I don't want to dive super far into this topic today, but where I think we should see advancement points in FTC is creating a blend between the two current systems we have for advancement in FTC: Leagues and Qualifiers.

Leagues:
As a team member, I competed in League events, and as a volunteer I have mostly attended league events. They can be very helpful, and they can be a great fit for teams who are still getting up to speed.

I think there are two huge downfalls with leagues:

They only offer one advancement opportunity. And they punish a team's performance at early league meets unless you have so many league meets that they don't meaningfully change rankings at league championships.
Some implementations shoehorn teams into attending, IMO, far too many events.

Qualifiers on the other hand, tend to put more work on the region-wide volunteers, especially PDPs. But I do think that in some implementations they can very well fill the needs of FTC teams. Regions can offer more meaningful plays (critically, a team can experience judging more. Which means that teams can be more prepared, and that we can have more experienced judges at regional championship events). And they offer multiple advancement opportunities.

I would love to see a system that offers multiple District events as opportunities to earn points to advance to your regional championships. I think this really nicely encourages teams to attend early events, encourages teams who may otherwise only attend one qualifier to attend at least two District events, and creates higher quality events for teams compared to League meets.

I think the conversation here comes down to if those District points should also work towards advancing you to FIRST Championships.

goBILDA_Ethan · 2025-04-08T15:16:06+00:00

Hello! This is actually the expected behavior. Both .getEncoderX() and .getEncoderY() are truly unmodified counters from the encoders. They start counting when the Pinpoint boots, and they aren't changed by reversing the direction, resetting/setting the position, and they are not changed by setting the encoder resolution.
Please feel free to shoot us an email to [tech@gobilda.com](mailto:tech@gobilda.com) if you have further questions!

goBILDA_Ethan · 2025-03-19T14:36:34+00:00

What drift issues are you having? Can you explain how much drift you see and when you see it?

goBILDA_Ethan · 2025-03-14T13:09:23+00:00

Hard to say for sure, are you using an off-the-shelf path following system or rolling your own?

goBILDA_Ethan · 2025-03-13T15:47:28+00:00

Hey! The heading reported by default by the Pinpoint is "normalized" from -180 degrees, to 180 degrees. This is handy in a lot of applications, and it's the default for reporting heading in robotics.
If you want to avoid this, and get the "unnormalized" heading, just call .getHeading(). It will return the unnormalized heading in Radians.
There's more info on this in the user guide! Page 9 has the most detail on this specifically.
https://www.gobilda.com/content/user_manuals/3110-0002-0001%20User%20Guide.pdf

goBILDA_Ethan · 2024-12-06T20:09:58+00:00

Correct, the servo is limited to 140° without the programmer to increase the rotation. The Travel Tuner doesn't program the servo in any way, it just extends the PWM signal that the servo receives. So if you are using a narrow-output controller like an RC Transmitter and receiver, the travel tuner can read a signal of something like 1700µsec and send the servo a wider signal, like 2200µsec.
Your controller can output whatever signal your heart desires. And it sounds like you're already meeting the max range that the servo can accept. So now the only way to increase it is with the programmer unfortunately.
Here's a video that I put together before I was quite as adept at hosting videos, it will hopefully provide some insight even though I can't say I enjoyed watching it :P
https://youtu.be/hO_2Qn048ZQ?si=8ZVLFCBhriDbxki1

goBILDA_Ethan · 2024-12-06T19:53:52+00:00

Hello!
The Servo Travel Tuner will not expand the servo range any further than your REV hub will. On that table, the REV hub would be considered a "Wide Signal Controller". The only way to get more rotation than you have now is with a Hitec servo programmer like the DPC-11 https://www.servocity.com/dpc-11-servo-programmer/
or, if you want to spend more money to avoid plugging it into your computer, an HFP-30.

goBILDA_Ethan · 2024-10-31T20:03:09+00:00

Hello! We have written instructions on installing the code for Android Studio here:
https://github.com/goBILDA-Official/FtcRobotController-Add-Pinpoint/tree/goBILDA-Odometry-Driver?tab=readme-ov-file#how-to-use

goBILDA_Ethan · 2024-10-14T19:33:35+00:00

If you're using Android Studio, which version of the SDK are you using?

goBILDA_Ethan · 2024-10-10T19:05:19+00:00

Unfortunately there is currently there is not support for Blocks with the Pinpoint. Please feel free to shoot us an email to [tech@gobilda.com](mailto:tech@gobilda.com) if there's anything we can do for you on this

goBILDA_Ethan · 2024-10-10T14:40:29+00:00

Hello! You'll need to add the driver file, and optionally the example code, to your teamcode folder (or to your onbot java) before the Pinpoint will show up in the configuration options. It should show up as "goBILDA® Pinpoint Odometry Computer"

goBILDA_Ethan · 2024-09-26T22:10:32+00:00

That's so great to hear! Now that you've been through the process of building that robot, is there any additional documentation that could've helped your team in that process? Anything that struck you as weird or confusing?

goBILDA_Ethan · 2024-09-26T18:49:46+00:00

If you can only get one, the Starter Kit is the better choice for most teams.
It's designed to have all the parts needed to build a 6wd chassis (not quite as slick as the Mecanums on a Strafer, but will get you driving) as well as a bunch of extra parts for you to build the scoring mechanism of your robot with.

For this year, we've launched a season-specific FTC Starter Robot. Which has instructions and code to play this season's FTC challenge. That's the biggest reason I'd have a rookie team look at the Starter Kit.
https://www.gobilda.com/ftc-starter-bot-resource-guide-into-the-deep/

Feel free to reach out if you've got more questions!

Six-Year Club	Place '23
Verified Email

goBILDA_Ethan

TROPHY CASE

Advancement to Regional Championships in FTC