-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add AHRS to Tethys equipped model #158
Conversation
@braanan do we have a reference AHRS system from which to derive a noise model? Not that we have a lot of options -- we have gaussian or gaussian. Also, I'd really need access to all of our repositories to complete AHRS integration. Couldn't get things going with the latest MBARI Docker image -- it'd appear |
I think we'll go with Gaussian then. Here's a link to the Sparton AHRS-M2 we have installed across the fleet: https://www.spartonnavex.com/product/ahrs-m2/ All the info you need should be in the datasheet. As for access, all checks are cleared — just waiting for final approval from our MT. |
Alright, after much digging, I think I extracted all that can be extracted from the datasheet. There's no characterization of the magnetometer whatsoever, and IIUC I'm lacking data to use the bias drift model in Ignition (which is loosely explained in https://github.com/ethz-asl/kalibr/wiki/IMU-Noise-Model). |
} | ||
|
||
////////////////////////////////////////////////// | ||
TEST_F(AhrsTest, FrameConventionsAreCorrect) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@braanan @arjo129 at first I tried to break this test into smaller ones, but I'm unable to instantiate ignition::gazebo::TestFixture
more than once in the same process. It aborts with CHECK failed: GeneratedDatabase()->Add(...)
, which appears to be coming from the shared library that bears lrauv
protobuf messages. I suspect the Ignition plugin system is attempting to reload it upon fixture construction (see here).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yeah I forgot to mention I think we keep each test isolated in a separate process as there was a bug in the way we are linking the messages. For whatever reason if we rely on external messages google protobuf will go 💥 if we have two tests in the same process. I have not been able to isolate exactly why this is the case. Tracking this issue in #159 as we had not been tracking this.
ignition::gazebo::Entity tethysEntity = | ||
world.ModelByName(_ecm, "tethys"); | ||
using ignition::gazebo::components::Static; | ||
_ecm.CreateComponent(tethysEntity, Static(true)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@braanan @arjo129 I forced the model to be static to avoid motion whenever I put the AUV in unusual orientations. Unfortunately, it also means we are not testing AHRS output when moving. It'd be tricky nonetheless. Hydrodynamics modelling gets in the way and it's hard to tell what the angular velocity and linear acceleration is going to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we agreed that as long as the AHRS is reporting the correct coordinate frame we should hope for the best with the gyro.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's right. Thing is, I cannot test for gyro frame conventions if its output is always zero. I guess we are testing that the body frame is correct for the accelerometer so it should be good for the gyro too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @hidmic thanks for the tests and the imu. I think this is good to merge. For integration one possibility is to use the lrauv_state
to pass the imu outputs. This structure is populated in TethysCommPlugin.cc
. In particular the ratePQR
field may be of interest. Then again, I don't know much about the LRAUV source code as I am living in Singapore which means I dont have access to the MBARI code.
@hidmic Should I merge this? |
Had to rename topics in 11c2ad9. Unlike others, no plugin is relaying them from |
Combining upstream IMU and magnetometer sensors Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Signed-off-by: Michel Hidalgo <[email protected]>
Integration tests are failing upon installing |
@hidmic looks like there's a reverse sign in the accelerometer data - FSK should have positive down. I'm seeing:
Updated so the printout above is reported with the vehicle sitting on the surface - I'd expect to see gravity reported on Z with a value of roughly 9.8 m/s2 If this is the std convention for the imu in Ign we can process the data in the lrauv-app end. Thanks |
@braanan my (perhaps vague) understanding of MEMS IMUs is that when standing still under constant gravity, its proof mass is displaced as if it was accelerating in the opposite direction (ie. upwards). This matches Ignition's IMU sensor behavior (see here and gravity defaults here). Having said that, I have no first-hand experience with Sparton's AHRS-M2 so perhaps it behaves differently. |
It does. Here's the output from an actual vehicle
I'm not sure if this output format is true to all AHRS models or unique to the M2. I'll check, since that will inform where we should implement the sign flip. If it's indeed true for all AHRS models we can see about reversing the sign in the plugin, otherwise, the sign flip should go in the AHRS_M2 device driver in the lrauv-application. |
OK, I've asked around and it seems like there's not much consistency between vendors, so I'll add the sign flip in the AHRS_M2 driver with a comment. |
@braanan hmm, will that work? It's not that the linear acceleration Z-axis is flipped, only gravity is. I'll go ahead and guess that the real AHRS is estimating gravity's magnitude and direction and re-applying it to provide these acceleration measurements. Maybe we have to do the same in the plugin :/ |
@hidmic Looks like the imu plugin assumes that the linear accelarations (and the sensor) are alligned with the ENU frame of refrence. As far as I can tell, the rotation to NED is only applied to the oriantation data here, so we'll have to add that rotation to NED (FSK) to the linear accelarations and angular velocities in the plugin or take care of that on the LRAUV side. Maybe I'm missing something. Since this is an upstream plugin the second option will be simpler I think. |
@braanan that has been taken care of here. The issue we have now is the minus sign that gets applied to gravity here. As I mentioned above, AFAIK that's correct for most IMUs, but apparently not for the AHRS-M2. The only solution I see here is to allow the user to flip that sign through configuration. |
@braanan may I get an approval? |
Combining upstream IMU and magnetometer sensors. This is lacking a test but perhaps this is best tested as part of #151 e.g. make the AUV describe a known trajectory and sample IMU and magnetometer measurements along that trajectory to ensure values make sense.