PigeonIMU.getAccumGyro breaks simulation

[adam-mcdaniel]

I can't sim any of my robot code because of this function. I don't need it for the sim, but it would be a lot of work to rip out everything in my program just because it's not implemented in the sim. Is there a way to just force it to not throw an error, or to return [0, 0, 0] and print a warning or something of that nature?

[auscompgeek]

You could catch the exception or check whether you're in simulation.

Currently almost none of the PigeonIMU simulation is actually implemented. Contributions welcome.

[MrRSquared]

Thank you all for working on this. We would love to be able to help, but as it stands now, we are only able to utilize these incredible libraries and are not yet strong enough coders to help develop them. We are not certain if we will be using accumulated gyro, fused heading, or Yaw, Pitch, Roll methods, but chances are good we will use the Yaw, Pitch, Roll. As such, the methods we will attempt to use are below.

getAccumGyro()
getYawPitchRoll()
getFusedHeading()
setAccumGyro()
setFusedHeading()
setYaw()

If anyone attempts to add any of these, we could certainly test them.

[virtuald]

Before I saw your note, I read the documentation and guessed what someone might use. It seems to me that getYawPitchRoll is really what most people will want to use? ... or maybe fused heading, but that seems to be the same as yaw?

It's not clear to me what the difference between the output of getYawPitchRoll and getAccumGyro and getFusedHeading are. I've implemented getYawPitchRoll and getFusedHeading because that's probably what one wants to use. Anyone who has actually used a pigeon please speak up and let me know if that's wrong. :)

[auscompgeek]

I think, judging from the documentation, that getAccumGyro is purely the integrated gyro reading, whereas getFusedHeading uses all the sensors on the IMU. A team would probably almost always want to use getFusedHeading instead of getAccumGyro (although we screwed up getFusedHeading slightly; see #110).

[adam-mcdaniel]

Our team is using getAccumGyro in place of getYawPitchRoll. We tried to use getYawPitchRoll at first on our bot, but for some reason the angles we were getting were not continuous. For example, when we would tilt our bot upward, it would go very slowly from 0 to 10 degrees, but very rapidly from 10 to 20 degrees. When we use getAccumGyro we don't have this problem.

[MrRSquared]

That is why I put all three. We know what we want to accomplish, similar to adam-mcdaniel, but the documentation on CTRE's end seems confusing as to which is best. To make matters a bit more confusing, they do not use the same terminology as some other IMUs (think Navx), so it will require some trial and error to get everything to work as we envision.

[virtuald]

Which axis of getAccumGyro is the heading, x?

[MrRSquared]

So, after reading through the manual, I noticed two things.

1. Accumulated gyro z seems to be the yaw.
   2)They mention the specific issue @adam-mcdaniel's team had. They say the yaw and Accumulated Z can be off if the Pigeon is located too far from the center of rotation, which does make sense.

[virtuald]

Hm, Z? Ok.