accel_brake_map_calibrator sometimes produce invalid map file

[VRichardJP]

Checklist

• I've read the contribution guidelines.
• I've searched other issues and no duplicate issues were found.
• I'm convinced that this is not my fault but a bug.

Description

I went through the accel/brake map calibration of one vehicle today. After driving with a joystick for a while I saved the file with the /accel_brake_map_calibrator/update_map_dir service.

But upon testing, the raw_vehicle_cmd_converter would always crash on loading the generated data (in interpolation_utils::validateKeys). I inspected the file and saw that sometimes the column values were the same over consecutive rows. Like this:

0.3,-1.48,-1.5,-1.48,...
0.4,-1.48,-1.5,-1.85,...

I manually edited the value so that accel values are strictly increasing. Like so:

0.3,-1.48,-1.5,-1.48,...
0.4,-1.49,-1.51,-1.85,...

And the raw_vehicle_cmd_converter is not crashing anymore.

I don't know whether it is normal for the interpolation to crash when values are not strictly increasing. But either the interpolation of the calibrator should be fixed

Expected behavior

accel/brake maps generated by the accel_brake_map_calibrator should always be valid.

Actual behavior

sometimes incompatible maps are generated

Steps to reproduce

1. calibrate

Versions

• Ubuntu 20.04
• ROS2 galactic
• master (~1 month old)

Possible causes

No response

Additional context

No response

[takayuki5168]

@VRichardJP Thanks for your bug report! I guess this should be fixed. In this case, the interpolated function has a discontinuity.

@TakaHoribe How about asking this bug fix to a PT student. Or just setting help_wanted sounds fine.

[VRichardJP]

example of brake_map.csv generated from the calibrator:
brake_map.csv

0.6, 0.7 and 0.8 rows have not been calibrated (too strong brake), most values are the same and raw_vehicle_cmd_converter crashes at runtime when using this map.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity.

[xmfcx]

@TakaHoribe @takayuki5168 any updates on this issue?