Basically the title, I have a use case that could use this data, was wondering if the Pigeon 2.0 could provide that?
The Pigeon 2.0 is an inertial measurement unit (IMU) that can sense acceleration, angular velocity, and magnetic
fields. With this information, Pigeon 2.0 can be used to sense a mobile platform’s pose, which then can be used for
a variety of applications.
base on this you can’t or at least i don’t think you can get directly the velocity, but if you have acceleration and you don’t need that much acracy
v = v0 + at
it will be a little hard with angular acceleration, but it’s possible.
The answer depends on how big of an error is acceptable, as it integrates the acceleration and can drift over time. I hope someone from CTRE has this data for the pigeon 2 and would post it here.
Wheel encoders though use the derivative of the position which is not susceptible to drift, only to slippage and incorrect measurements of the wheels.
Seems like a combination would be the best answer perhaps.
Though some actual testing might reveal otherwise
I can’t use a combination of wheel encoders plus IMU because in my case the point is to have a secondary source of data to compare against the encoder velocity.
EDIT: Maybe I could do a Kalman filter (combining IMU and encoder velocity) biased toward IMU, and compare that against the encoder velocity.
What’s the use case exactly? Maybe an outer source like a stationary camera could do the job?
A traction control algorithm, it works relatively well now.
You can view it here: PurpleLib/src/main/java/org/lasarobotics/drive/TractionControlController.java at master · lasarobotics/PurpleLib · GitHub
Yeah, I’d be willing to guess you could try taking the last “frame” of your camera position, and see how much time has passed, then compare.
Though I’m not an expert
If you are interested in detecting wheel slippage, drive motor current is worth considering. You probably want to look at the data that comes off an accelerometer when you do start to slip – during that interval of time, and not by looking at the derived velocity.
Given four independent wheels, I suspect drive motor current is going to be a better data source, given that you are already using wheel velocity.
It is possible to obtain velocity from Pigeon 2. However, since the gyro does not have an integrated Kalman filter for velocity, calculating velocity by integrating acceleration in the RoboRIO can be challenging. The RoboRIO operates at a maximum frequency of 256 Hz, while the internal Kalman filter runs at 1000 Hz, making the integration process more difficult.
It’s not just about knowing when slipping is occurring but knowing what to do when it is.
Do we know what IMU IC is used on the pigeon 2? If we do, you can search up the spec sheet which usually are quite a lot more detailed than FRC datasheets and will have detailed accuracy information and sensor bandwidth.
Its highly insufficient. IMU spec sheets typically contain about 2 pages of specifications on just accuracy of various forms.
I wouldn’t count on it, I asked chatgpt to find a citation for this and it gave me like 3 different answers to the initial question, especially since your post is the only reference to BMI270 on this entire forum and the BMI270 does not contain a magnetometer, and only is a $5 IMU
People need to stop asking ChatGPT questions like that. It doesn’t know when it knows stuff! It will happily lie to you!
Thats why I cited my source, GPT’s suck when it comes to facts. I was simply hoping that it had a shot at being right
That sounds like localization more than traction control… If so, there’s quite a bit on fusing odometry, IMU, and other (camera) data. The use case is still unclear to me though.
Not really, its about how much to reduce the speed output by, given the amount of slipping, known coefficient of friction of the wheel against the carpet, mass of the robot, etc, in order to regain traction, while not needing to impose (as restrictive) stator current limits, which could leave more performance on the table.
I mean sure, but in pretty much all scenarios an unchecked GPT answer is actively worse than no answer.