Pigeon2 appears to lose Mount Calibration.

[GaCo1629]

There is growing evidence that if you have the Pigeon mounted inverted, and you get some type of elec/mech glitch while driving, then when it recovers, the rotational axis orientation is incorrect.

The chief delphi post is here. https://www.chiefdelphi.com/t/ctre-pigeon-2-reversing-rotation-after-glitch/516704

I'm the original poster. We encountered 5 or 6 instances during a 2 day competition where an apparent impact caused a temporary loss of IMU connection, followed by the inability to perform closed loop heading control.

Reviewing ,multiple logs and videos points to the fact the after each incident, the Pigeon is showing positive yaw on clockwise rotation.
It also shows very erratic Yaw data for a few seconds after the reset/disconnect.

Our IMU is mounted inverted, but we have performed a Mount calibration, and it opperates normally the majority of the time.

[CoryNessCTR]

Can you provide hoot logs of the event occurring here?

If the Pigeon were to power cycle and reboot it needs to re-determine its orientation to correctly identify the "positive yaw" direction.
Due to the nature of Yaw Pitch Roll, it doesn't matter what the mount orientation is, positive yaw is always referenced counterclockwise about world Z (gravity vector).
The only case where mount orientation significantly impacts yaw is if the Pigeon is oriented on its side so that Pitch is near +/- 90 degrees, where you encounter gimbal lock.

If a power cycle were caused by an impact it's very possible the accelerometer data is indicating that the "correct orientation" is right side up, and it could take some time for the motion stack to re-orient and recognize it's upside down.
I don't remember off-hand, but it could also be that if the accelerometer is noisy we assume a "default" orientation of flat and level until we get more data, so if you flipped the Pigeon to make it right side up you may also get better results.

Ultimately I think the root cause of the issue is a power pathway problem that's resulting in the Pigeon power cycling.
You should be able to prove this with the uptime status signal the Pigeon reports. If it resets to 0 when the event occurs it a reboot occurred.
In which case I'd primarily be looking at your power wires to see if there's a loose connection between the Pigeon and your power supply.

[gearsincorg]

Thanks for the feedback.

I may not have the HOOT files. I'm new to logging and so I may have only retreived the Advantage scope logs.
I don't know if the Uptime is logged. I don't remember seeing it in the AdvantageKit logs.

Regarding: <If a power cycle were caused by an impact it's very possible the accelerometer data is indicating that the "correct orientation" is right side up, and it could take some time for the motion stack to re-orient and recognize it's upside down.>

We were never able to convince the Pigeon to revert back to the correct Yaw orientation after a glitch (without powering down) . we tried adding code to physically stop the robot for 4 seconds while issuing a IMU reset (when the operator hit a key combination) . But the issue persisted.

The "disconnection" itself lasts about 0.5 seconds, and no other devices show a simmilar disconnect. The Pigeon is colocated with the Canivore, sharing power and can bus within a 3D printed mount on the RoboRio.

Yes. We have now flipped the Pigeon over, and so it now has a "default" orientation. It was mounted inverted because all the electronics are on the underside of the robot, and in order to see it's LED's it needed to be pointed to the floor :)

[CoryNessCTR]

We were never able to convince the Pigeon to revert back to the correct Yaw orientation after a glitch (without powering down) . we tried adding code to physically stop the robot for 4 seconds while issuing a IMU reset (when the operator hit a key combination) . But the issue persisted.

This is unexpected to me, the Pigeon should eventually correct itself, especially if you've given it like 4 seconds while still.
When you have time (after the competition season is fine), if you can capture a hoot log of the event occurring and send it our way I'll take a look to see what's going on and if there's anything we can do to improve the scenario on our end.

On another note, we got a couple of reports of the Pigeon power cycling after this first issue. Taking ESD-protection measures (mount the Pigeon to metal, wrap it in aluminum foil, etc) seemed to have stopped the resets for these teams, so I'll also mention it here in case you also want to take ESD protection measures to further reduce the likelihood of the issue occurring again.

[GaCo1629]

Here is the hoot file for the match. oops it won't upload...30MB size limit?
I tried giving it a .txt extension after I zipped it, still no upload.

The even occurs at time 423 Sec. (8 sec into teleop).

Things I notice.

1. The UpTime does reset to zero.
2. I get two faults at that time: BootDuringEnable and BootIntoMotion.
3. The gravity vector definately flips after a short period when it's just not sure where gravity is. It stays flipped until the match is over.

[CoryNessCTR]

Hmm, the gravity vector being wrong until the match ends is very odd to me.
Boot into motion and boot during enable makes sense if the Pigeon reboot, which the uptime signal seems to indicate.

Can you email the hoot to support@ctr-electronics.com?
Or put it in a google drive and link it here?
That should hopefully give us what we need to try to reproduce the event and see about getting a fix in place.

Checking the match video from the match referenced in the hoot log name, it seems like going over the depot bump triggered the event.
I could see the bump either causing a power disconnect if you have a weak connector somewhere in the Pigeon's power pathway, or possibly even zapping the Pigeon if the Pigeon is mounted on the bottom of the bellypan.
So even though the Pigeon should be able to partially recover and give you world referenced data again (you'll lose your Yaw as that's relative on boot), it's still less than ideal that the power cycle happening in the first place.
Given the prevalence of ESD related issues this year (https://api.ctr-electronics.com/changelog#fixed-20260323), I'm inclined to believe the root cause could be ESD and doing something like wrapping the Pigeon with foil grounded to your chassis may be sufficient to prevent the issue in the first place.
But if you haven't re-verified the power cabling, that's also a good step just to rule it out.