Skip to content
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 sensor #144

Closed
Tracked by #150
chapulina opened this issue Jan 12, 2022 · 4 comments
Closed
Tracked by #150

Add AHRS sensor #144

chapulina opened this issue Jan 12, 2022 · 4 comments
Milestone

Comments

@chapulina
Copy link
Contributor

Add an "Attitude and Heading Reference System", which we may be able to implement as a combination of an IMU and a magnetometer.

Here's the data it needs to output:

float roll: rad in NED world frame
float pitch: rad in NED world frame
float yaw: rad, vehicle heading relative to true north (in NED)

float accelX, accelY, accelZ: m/s2, vehicle-frame linear accelerations in XYZ (XYZ=FSK)
float gyroX, gyroY, gyroZ: rad/s, vehicle-frame angular velocities in XYZ (XYZ=FSK)

// Optional (not really required)
float magX, magY, magZ: microtesla (can also be in milligauss), vehicle frame magnetometer reading in XYZ (XYZ=FSK)
@caguero caguero mentioned this issue Jan 19, 2022
39 tasks
@caguero caguero added this to the 2022 M1 milestone Jan 19, 2022
@hidmic
Copy link
Collaborator

hidmic commented Feb 3, 2022

@caguero @braanan I've been digging through LRAUV and Ignition code. Also played a bit with the latest MBARI Docker image. I think we have two options here:

  1. We arrange an AHRS by adding stock IMU and magnetometer sensors to the tethys_equipped SDF model. They seem feature complete, offer a typical ignition-transport interface using stock imu.proto and magnetometer.proto messages, and IIUC we can arrange them so that their local frame matches FSK. If we don't need data synchronization between both sensors and nobody has strong opinions against stock interfaces, this is perhaps our best option.
  2. We merge (and perhaps simplify?) stock IMU and magnetometer sensors' implementations into a single AHRS plugin. We'll need an ahrs.proto message that could combine both imu.proto and magnetometer.proto messages. This one's perhaps the most flexible approach if we have some funky needs.

In both cases, we'll need to update the TethysComms plugin to populate an extended lrauv_state.proto message if we want to maintain compatibility. Thoughts?

@caguero
Copy link
Collaborator

caguero commented Feb 7, 2022

We could start with (1) that requires less custom code. We could potentially play with the topic names to give the impression that data is coming from the same sensor.

/model/tethys/ahrs/imu
/model/thetys/ahrs/magnetometer

@braanan
Copy link
Collaborator

braanan commented Feb 7, 2022

Thanks, Mich. I agree with @caguero, option 1 sounds like the path of least resistance. I think we should consider integrating the IMU/Mag receive interface in the lrauv-app instead of adding more fields to TethysComms' state msg. This should be straightforward as we already have multiple Ign transport nodes in the lrauv-app.

@hidmic
Copy link
Collaborator

hidmic commented Mar 23, 2022

Alright, considering all PRs have been merged and Docker images have been updated, I think we call this done. Closing.

@hidmic hidmic closed this as completed Mar 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants