ground speed sensor

[SijmenHuizenga]

No description provided.

[davidoort]

This is mostly useful if teams were doing LLC (low-level-controlls), which is not the case. So I would put this as low prio.

[SijmenHuizenga]

Wheel speed sensors is something I want to add some day. But at this moment there are higher priority tasks where we are focusing on, like spectator mode for livestreaming and higher camera fps. However, if some teams require this for their autonomous system we might be able to give this a higher priority.

[smnschfr]

Hi, in our system, both SLAM and control and therefore the whole pipeline relies on rpm's + gear ratio. We don't use a GPS.
We would very much appreciate to get access an interface for this, so a higher priority would be great.

[SijmenHuizenga]

Hi @smnschfr, thanks for joining the conversation! Personally I have not that much experience with wheel speed sensors. To get a better understanding of how this should work, can you explain in a bit more detail what you need?

Do you need transforms between the wheels and the car? If so, between what and what? Do you need rpm's for each wheel individual? What kind of frequency range do you expect to receive these values?

In the simulation, there are no gears (just rotating wheels). Would you still want to receive gear ratios and if so, how do you see this work?

When sending to ros, what sensor messages would you want to see used?

Out of curiosity, are you part of any formula student team?

[smnschfr]

Hi @SijmenHuizenga, I'm from KA-RaceIng. We've taken a closer look at the simulation this weekend, that's why we've come up with a number of issues here.

Basically, what we would need is a relatively hight-frequency (100Hz in our real car) longitudinal velocity estimation. It's both used extensively in the SLAM (together with the IMU for pose updates between landmark measurements) and the controller.
It has some inaccuracies due to slip, but it's (in reality) a lot more precise than integrating IMU data. GPS is too low-frequency to play the same role.

Whether that data comes from motor rpm + gear ratio or wheel rpm + wheel diameter doesn't really matter for the purpose of this simulation, as well what kind of msg (probably easiest to use some std_msgs)

Wheel-individual data would be useful for some controller optimizations in reality, but in the simulation that likely doesn't make much sense and a single value would probably be enough. Regarding frequency, I think 50 Hz is the minimum for it to be useful, 100Hz would be nice.

[SijmenHuizenga]

Thanks the information! A high frequency (100hz), precise velocity sensor is definitely something that can relatively easily be added.

I do think we should add some slight noise or inaccuracy to the sensor values. Do you by any chance have statistics on how precise an average wheel speed velocity sensordata is?

@davidoort maybe you have thoughts on this as well?

[davidoort]

Given our time constraints, I think the most feasible option in this case is to model a Kistler ground speed sensor completely in the ros wrapper code by using the ground truth odometry and some sensor specs which we can agree on (like the ones here). Eventually it would also be nice to support wheel speeds, but would this suffice for now? @smnschfr

[smnschfr]

A Kistler GSS would definitely be precise enough. Thanks for reacting so quickly!

[SijmenHuizenga]

Oke! I will create the sensor this week 👍

I think the most feasible option in this case is to model a Kistler ground speed sensor completely in the ros wrapper code by using the ground truth odometry

@davidoort I think we should model this in unreal engine, just like we did with all other sensors.

[davidoort]

Yes, this will allow other clients (not just the ros wrapper) to use it

[SijmenHuizenga]

The fsd-resources by amz provide a rosbag with the Kistler Correvit SFII. It has the geometry_msgs/TwistStamped, so let's use that message type here as well. The angular velocity will be empty:

header:
  seq: 0
  stamp:
    secs: 1494414891
    nsecs: 886937502
  frame_id: "optical_speed"
twist:
  linear:
    x: 8.02999973297
    y: -0.140000000596
    z: 0.0
  angular:
    x: 0.0
    y: 0.0
    z: 0.0

[SijmenHuizenga]

This is a plot of the real Kistler data:

It seems like there is some noise. Should we model this in the senor as well?

Edit: No I don't think so. This is data at 250hz, we will max at 100hz, and it is not even sure if we can reach that, see #156 . So let's just say that there is no noise. Basically we are modeling a Kistler where the 250hz data is running-averaged into ground through aka ground thrugh.