We are using a pigeon IMU for our gyro and are thinking about using a electromagnet as well and were wondering if anyone has used these together before or know if it will cause issues on our readings from the Gyro.
From the Pigeon user’s guide http://www.ctr-electronics.com/downloads/pdf/Pigeon%20IMU%20User’s%20Guide.pdf
11.3.What’s the difference between FusedHeading and Yaw?Yaw is calculated using the Gyro and Accelerometer only. In many cases this is adequate. However if Compass-fusing is required, FusedHeading can be used instead.
Additionally, the user can disable compass fusing so that FusedHeading tracks identically with Yaw without having to modify robot application to read Yaw. This is useful if user needs to compare robot performance with and without compass fusing without considerable modification of the robot application.
If Pigeon has never undergone Compass Calibration, then FusedHeading and Yaw are effectively equivalent.
If you aren’t using the FusedHeading, then the electromagent shouldn’t cause interference.
We used Pigeons in 2017, 2018, and 2019 on our swerve bot. Not a fan… many issues but interference and bootcal were the major ones…
What issues did you have? What have you moved onto?
Also a swerve team here so curious. #swerve2020
FWIW: We noticed that the pigeon was not particularly tolerant to brown out situations. We’ve since swapped back to NavX and haven’t had any issues since.
We really want to use the pigeon, it’s super tiny! And who doesn’t love that you can directly connect it to an SRX and feed it into the second PID loop?
If anyone out there has found a solution to the brownout issues, I’d love to hear about it…
The primary gremlin we had was during boot calibration. IMUs tend to not like vibration, as the Pigeon manual states. At the first 5-6 matches at OKC, the general policy was to turn the robot on at the end of the previous match, let it cal, and set it on the field. For some reason, AV placed the speaker stacks very close to queue, so when the “rocket blastoff” bass sound would come on before announcing the score, the entire floor would vibrate (we could feel it). If the Pigeon was in bootcal when the vibration would occur, it would throw us into a perpetual bootcal loop and the Pigeon would never actually calibrate. FTA Josh @Jpatterson1710 (bless this man) worked with us on this issue. AV turned down the bass, and our issues seemed to be resolved, no infinite loops after that. Though we did add a Shuffleboard widget to track status of bootcal and made it policy to turn the robot on after placing it on the field, after identifying this situation we had no problems afterwards.
One other minor issue was the Pigeon’s tendency to drift in heading. This was much more minor than the bootcal issue, but we had this happen in longer practice sessions and towards the end of some of our matches. I’m not sure exactly what caused the drift (since it shouldn’t happen in that short of time), but it was definitely noticeable in my hours of driving our 2019 bot.
After our poor (but more than likely anecdotal) experience with the Pigeon, we switched to using the NavX for the 2020 season. Part of it was us not wanting to make a mount for a different IMU (NavX plugs right in), but a fair part of it was due to generally good reviews from teams and it being available on FC for us to pick two of them up. While I’m not a programmer myself, I’ve been happy so far with the NavX and we haven’t had any setup or run issues while testing.
Why not just turn the robot on after setting it on the field and let it calibrate there? Asking the question in general, not just in response to the speaker vibrations issue.
FTAs tend to want your robots on before the match starts and the volunteers are typically all instructed to have teams turn their robots prior to getting onto the field. We’ve been yelled at a few times when we have forgotten to.
That’s interesting. We’ve never had any issues with our Pigeons. Even with the insanely loud venues at San Francisco and Silicon Valley, we never experienced that calibration issue. Same with the drifting issue, we see maybe 2-3 degrees of drift by the end of each match, which is fairly negligible (maybe not for swerve, I cant speak on that). And if I’m recalling correctly, the pigeon and navX use the same IMU chip, so drift should be the similar.
I think it was more the bass causing the vibration rather than the pure sound. Though the regionals around us to do run absurdly loud sound - I’ve worn earplugs in the stands before, and I wasn’t the only one doing it…
Honestly, sounds more like either a faulty unit or an implementation problem. I’d love to see how you implemented it in more detail.
In this case, you can do “restart robot code” in your driver station and whatever code you have in robot init will run. We used IMU for 2018 offseason and had no problems with it and this was the exact method we used to calibrate the IMU before the game started.
If the bass speaker truly was the root-cause, then this would have disrupted any IMU.
The documented drift values for Pigeon and NavX are the same. This is because they both use the same IMU silicon.
The major sources of error are temperature and mounting (center-or-rotation). These error sources are explained and we provide you with procedures for testing and solving them in the manual.
This should be done regardless of which IMU you use.
Im surprised you didn’t contact [email protected] since you were having issues across multiple seasons (I just looked through our support email and didn’t read anything about speakers).
The feedback we get on Pigeon has been overwhelmingly positive. With that said I’m not against zooming in, especially if we can reproduce a circumstance where bootcal can’t complete because of the environment. The experiment sounds simple, I’ve got Bose speakers we can blast our robot with
I’m not sure if you mean using the compass or literally adding an electromagnet for some other reason. But either way, the following is useful information.
The Pigeon-IMU compass calibration was never added to the doc despite being supported in Pigeon firmware. In testing our IMU (and other popular FRC IMUs) we found that the magnetometer typically causes more problems then solves since placement near magnetic/ferrous materials is common and can wreak havoc on compass readings, particularly in an indoor environment. If you rely on magnetometer, your placement requirements becomes complex . Finding a spot on the robot that is center-of-rotation and far from steel/magnets can be difficult.
So that means the heading relies on the accel and gyro, both of which are immune to electromagnetic interference (they are inertial).
You will stand to benefit far more by performing the thermal calibration strategy, its far simpler to perform, only needs to be done once, and temperature is a far greater contributor of IMU error in FRC then anything else, second to maybe center-of-rotation placement.
Pigeon vmin is 5.5V when powered thru pad (although you only lose CANbus, the true vmin is lower). You can also power from VRM to get better dropout threshold. When plugged into Talon, its the same as Talon SRX drop out. Moving to another Talon that has a power path with lowest series-R to the battery may improve the drop out. However the first step is to prove you are actually experiencing a true drop out. LEDs or monitoring the boot-cal would accomplish this. Also inspect the gadgeteer port for swarf as this has been reported to cause intermittent resets.
Appreciate the response. We are thinking about using the elecromagnet to lock our buddy climb mechanism in place. Sounds like that would not affect the gyro being used for our swerve drive.
Wow, thanks for the shout-out.
I have never encouraged this practice (am FTA, see above) because I think it can be a safety concern, and because it does affect teams using these types of sensors. If anyone runs into this situation, just politely explain to the your FTA why you want to wait until you have your bot on the field. All of us FTAs want to see all of you succeed!
A combination of several things could have lead to the disruption, but the bass was definitely a factor in this case. I remember the situation pretty clearly, because I remember being incredibly surprised by the amount/intensity of vibration from the bass when standing on Hab Level 1. It was definitely enough to cause disruption.
Oklahoma Regional is played in an arena setting atop and underground parking garage. In 2019, two massive ground-based subwoofers were used to supplement the flown line arrays. The ground was essentially a concrete bridge with two powerful agitators on top.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.