RTC Manager reports future objects at -100000.0 distance

[VRichardJP]

Checklist

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

Description

In this example, the ego vehicle needs to go through 3 traffic lights to reach the goal point, traffic lights handling is set to manual mode to better understand the situation. Before the first traffic light, the RTC manager panel reports multiple events at a distance of -100000.0:

When the first traffic light is reached, I press the "Execute Velocity Change" button so that the vehicle can resume its course. Note that when I do this, the traffic light at -100000.0 meters is also enabled:

The vehicle drives forward a bit, and reaches the second traffic light, which is already enabled, so the vehicle ignores it. You can see the ID is the same than the previously reported traffic light at -100000.0 distance:

Finally the vehicle reaches the third traffic light and wait in front of the stop line as expected:

---

Expected behavior

I have 2 problems with this:

• obviously, the events are not at -100000.0
• but also, clicking on "Execute Velocity Change" enables too many things at once. The 2 traffic lights are separated by like 200 meters, not to be able to enable only the first one without the second makes the RTCManagerPanel a bit akward to use. It would be nice to have a button for each event reported in the table.

Actual behavior

Some future events are reported at -100000.0 distance

It looks like this value is set here when the distance is not finite.

Steps to reproduce

?

Versions

No response

Possible causes

No response

Additional context

No response

[kyoichi-sugahara]

@VRichardJP Thank you so much for the report. I would like to investigate this issue. And want to know the priority for this issue. I mean this issue is the blocker for some project? And is it possible to share the map file so that I can reproduce situation?

[VRichardJP]

I cannot share the map, but I could try to re-create one with the issue.

I fixed the issue by simply filtering out large negative value in RTC plugin.

I also modified the "Execute ..." buttons so that only the closest non-enabled item gets enabled, instead of all. On my map, some traffic lights are not far from each other so the RTC manager see multiple but I only want to enable the first.

[VRichardJP]

You can reproduce with this:

lanelet2_map.osm.txt

It looks like there is no need to have multiple traffic light on the path. With just this initial position from above and the goal point after the first traffic light, all the events (traffic light, intersection, etc) are reported at -100000.0.

[kyoichi-sugahara]

@VRichardJP Sorry for late reply and thank you for sharing map. I try to reproduce the situation. One traffic light's distance doesn't seem to be calculated successfully, but the others are calculated well.

Basically, if the distance to the stop line is behind the base_link, the -100000.0 is reported. And if the stop line is not on the trajectory, also -100000.0 is reported because distance is calculated by using trajectory.

If you want to avoid enabling all the modules at once, I think this is the reasonable solution

I fixed the issue by simply filtering out large negative value in RTC plugin.

[mehmetdogru]

@tkhmy friendly ping to ask if we have any update on the issue?

[tkhmy]

@mehmetdogru I think @kyoichi-sugahara is the one working on this issue?

[kyoichi-sugahara]

@VRichardJP I spoke with the developer in charge of RTCManagerPanel and confirmed the background that led to the current specifications.

• The functionality to individually approve was considered during the initial design phase, but it was not implemented due to concerns about potential misoperations caused by sorting based on distance, which could lead to a change in the order.
• Concerning individual approvals, it would result in publishing topics from the terminal, but it is possible to approve by specifying the UUID. Therefore, it seems appropriate to handle individual approvals in that manner.

[VRichardJP]

@kyoichi-sugahara Thank you for the feedback. I also agree it is not a good idea to have buttons moving around. For individual approvals, what about having a fixed button to enable selected items in Rviz RTCM list? It is still possible to missclick an event in the list, but as long as the button is click, this would have no effect.

[kyoichi-sugahara]

@VRichardJP

Sorry for the late reply, and thank you so much for the suggestion! I had some trouble understanding the following comment:

having a fixed button to enable selected items in Rviz RTCM list

Do you mean to fix the position of modules associated with a UUID once they become approvable until they become unapprovable, and set an approval button for each? Either way, please feel free to create a PR, and I will review or I will ask the developer in charge of this package to review it.

[VRichardJP]

having a fixed button to enable selected items in Rviz RTCM list

My idea is that to have a new button like the current "enable xxx" buttons. So the position of the button is fixed.

Then to enable one or multiple module, you select the corresponding rows (click to select, click again to unselect) then click on the button. The rows can still move around, but selection state is preserved.

So if you ever misclick on a row because of a sudden reorder, you can just click again on the row to unselect it.

[kyoichi-sugahara]

@VRichardJP I feel that the proposed method is good as a user interface, and the addition of these features would greatly benefit developers by increasing the number of scenarios that can be reproduced using the planning simulator.

Just to confirm, when you say "enable xxx", you mean to individually approve modules, not to activate auto_mode, correct?

[VRichardJP]

Yes ^^

[stale[bot]]

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

[stale[bot]]

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