Position Sensor at medium to high speed is inaccurate and varies depending on World BasicTimeStep

[austingreisman]

trafficstars

Describe the Bug It is possible there is an issue with the Webots Position Sensor when measuring a Hinge Joint being acted upon by a RotationalMotor at high speeds on an ackermann vehicle (I used the TeslaModel 3 proto from the webots cloud platform).

While testing, converting to speed (m/s) using the Position Sensor measurements over consecutive timesteps yields values that change in accuracy overtime (never being actually accurate).

This is on Webots R2023b

Steps to Reproduce

1. Open a flat Webots world with the Tesla Model.
2. Run the vehicle at a set speed.
3. Record the speed determined by taking the measurements overtime from the Position Sensor, record a GPS sensor speed output, and record your commanded speed.
4. See error.

Expected behavior I would expect the RPM (converted to speed to compare) would be the same as the commanded speed. I would also expect it would match the output GPS speed.

Screenshots In the above image, we have the vehicle dropping from a small height when the simulation starts (hence the weird GPS speed blip at the beginning). Then I begin to command to vehicle at various speeds and attempting to hold those speeds as the vehicle approaches it. You can see that the GPS speed, which comes directly from the gps sensor, properly matches the commanded speed. However, the reported speed, which is calculated from taking the changing value of the Position Sensor output on both front wheels over time (time being the basicTimeStep which in this case was 30 ms). This is a steady state test (where the basicTimeStep is now 5ms), where we command a speed of 25 m/s continuously for the whole ~27 second. As seen above, the GPS reported speed approaches a steady state of 25 m/s. However, the reported speed is over predicted the whole time vs, the under prediction in the previous example (a much slower timestep).

This test was interesting as we have a "true" speed (assumed to be the GPS speed) and the reported speed crossing at around the 31 m/s mark. In this test, I increased the speed to attempt to achieve to see if the inaccuracy pattern continued, which it did. In this case, we have the basicTimeStep at 17 ms.

I attempted these tests with a different wheel radius (0.28 instead of the 0.36 reported in the proto) to see if maybe that was my issue. However, the GPS data then no longer fits the commanded speed and the reported speed becomes even more incorrect.

System

• Operating System: Linux Ubuntu 20.04
• Graphics Card: Mesa Intel® Xe Graphics (TGL GT2)

Additional context I attempted to find some documentation on how to properly implement measuring of the Position Sensor but was unable. I currently do this in my custom WebotsController which I supply to the Teslamodel.

I believe my code is correct. I take the previous Position Sensor measurement, compare it to the current measurement, then divide by the basicTimeStep provided by the wb_position_sensor_get_sampling_period method. Then I convert that value to RPM. I hold the RPM until I'd like to obtain the speed where I convert RPM to m/s by multiplying by my wheelRadius (0.36) and and 60 / Two * Pi.

If there is a way to get actual hinge rotational information out of the simulator without using a sensor that would be ideal. I believe it would bypass this issue of something being strange with the Position Sensor.

Any advice or help would be greatly appreciated (I feel like this is a bug but I'd be happy to be proven wrong).

[lukicdarkoo]

Can you provide a simple world and controller so we can evaluate this?

A few general (hopefully related) comments:

• Lower basicTimeStep means more accurate simulation overall
• GPS returns total speed in all directions, taking speed from a position sensor means speed along one axis only (you need to move the robot perfectly perpendicular to a wall)

[austingreisman]

Can you provide a simple world and controller so we can evaluate this?

A few general (hopefully related) comments:

• Lower basicTimeStep means more accurate simulation overall
• GPS returns total speed in all directions, taking speed from a position sensor means speed along one axis only (you need to move the robot perfectly perpendicular to a wall)

Hi @lukicdarkoo, I can't provide my controller as it's IP. However, I'm in the process of creating a very basic controller to recreate this problem for you.

Replying to your comments:

• yes, lowering the basicTimeStep does seem to improve accuracy for all sensors other than the PositionSensor at the moment.
• You can get a vector from the GPS (which is what I'm doing and what I think you're talking about), then taking that vector, getting the Norm, then multiplying it by the sign of the positional sensor data to get proper directional information. However, I don't like the reliance on 1 sensor for multiple data inputs (GPS and driveline speed) as it's not a true simulation of what would happen in the real world (as much as you can get a simulation of the real world).

Will comment back soon. Thanks

[austingreisman]

Hi @lukicdarkoo,

I've created a sample set up for your team to checkout. It can be downloaded here: https://github.com/austingreisman/simpleWebotsController

The controller will create a file while running the simulation so that you may plot the results. Here is a sample that matches my results above. This was created using the plotCompareSpeeds.py script in the repo shared. It's in the controller directory.

You can look at the README for additional information.

Let me know what you find. Thanks for the help

[austingreisman]

@lukicdarkoo just following up, were you or your team able to look into this?

[lukicdarkoo]

If you set the basicTimeStep to e.g. 1 you will see significantly lower disperity. Lower basicTimeStep means more accurate and stable physics.

E.g. in your example, once Tesla reaches 50/ms your avgChangeRotationalPosition variable reaches 2.3 radians. That is almost a half circle. Physics is just too much discretized for the speeds.

I am not sure if we can do anything about it. It is probably the easiest to reduce the basicTimeStep.

[austingreisman]

Hi @lukicdarkoo

It appears at a basicTimeStep of 1, it sort of follows the GPS, but still overshoots the entire time (assuming the GPS is correct)

However, this is useable. Here is at 10 which is also not very useable.

I'm confused how this issue relates to the physicis being too discretized, this is an issue with a sensor, it shouldn't be effected this significantly by the physics engine. I'd imagine at any speed and any timestep, the sensor would perform the same. Shouldn't the GPS also be wrong if this was a physics issue?