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

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

Open
austingreisman opened this issue Nov 15, 2024 · 0 comments

Comments

@austingreisman
Copy link

austingreisman commented Nov 15, 2024

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
image
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).
image
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).

image
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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

1 participant