Should AltimeterSensor output depend on the gravity vector?

[osrf-migration]

Original report (archived issue) by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

Originally posted as a comment on gazebo_design pull request:

The AltimeterSensor (merged in pull request #1792) measures altitude along the Z axis. Technically, an altimeter works by measuring barometric pressure. In an atmosphere with a constant gravity field, the pressure varies in proportion to changes in position in a direction parallel to the gravity vector. which varies in proper. I'm going to pose a series of questions and answer them with my opinion separately in a comment:

1. Instead of always using the Z axis, should the AltimeterSensor define a vertical direction based on the gravity vector?

2. If the gravity magnitude is zero, should the AltimeterSensor output anything?

3. Should the noise properties in the AltimeterSensor depend on the gravity magnitude? (since the signal available to the sensor will be weaker with a smaller gravity magnitude, but the noise would presumably be the same magnitude)

[osrf-migration]

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).

---

I think the most likely issue users would have is if they are simulating a drone with gravity defined along the X or Y axes. In this case, the Altimeter wouldn't measure "elevation". This seems like an edge case. The advantage of the current implementation is simplicity, which makes it less prone to implementation errors. As such, I am fine with keeping the current implementation until users express an interest. So please comment on this issue and vote for it if you really want the AltimeterSensor output to be more general.

Regarding the questions:

1. We can add support for this if users request it. Though some users might modify gravity to simulate disturbances, which would interfere with the AltimeterSensor.

2. We can enable this as well if (1) is implemented. Though again, some users might disable gravity during testing, which would also interfere with the AltimeterSensor.

3. This seems like an edge case as well and is probably more suited for a SensorPlugin.

@asymingt

[osrf-migration]

Original comment by Andrew Symington (Bitbucket: asymingt).

---

I think that this is related to the question that asks whether we should be modelling a barometric altimeter as a fluid pressure sensor or as a simpler position sensor. I guess that this is a design choice that trades fidelity for simplicity. I initially designed the altimeter with simplicity in mind, but your question has made me rethink this.

Ultimately, barometric altitude is calculated by measuring the relative pressure change with respect to a reference point. To properly replicate this Gazebo should support a fluid pressure sensor (defined in ROS sensor_msgs package), with the altitude estimation being implemented in a navigation package, not the simulator. By default we could implement a very simple (Gazebo Z) -> (pressure) model. Then, a more complex gravity-based model, as suggested by @scpeters, can be introduced as a sensor plugin if required. I realise that this is a bit more work, but it may make more sense in the long run.

On a related note, I still think that it would be beneficial to include some sort of noise-perturbed Pose/Twist sensor in Gazebo. Typical use cases would involve simulating the feedback from a Vicon motion capture system, or some sort of wireless localization system.

[osrf-migration]

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).

---

• set version to "all"

[osrf-migration]

Original comment by James Goppert (Bitbucket: jgoppert).

---

I also think a pressure model would be best. We could just use the standard atmosphere model.