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.

Sign up for GitHub

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

Jump to bottom

ROS2 static transforms partially propagating through the web bridge to studio #238

Closed
asymingt opened this issue Jun 27, 2023 · 6 comments · Fixed by #239
Closed

ROS2 static transforms partially propagating through the web bridge to studio #238

asymingt opened this issue Jun 27, 2023 · 6 comments · Fixed by #239
Labels
bug Something isn't working

Comments

@asymingt
Copy link

Description

  • Version: Foxglove Studio 1.55.0 / Foxglove Web Bridge 0.5.3
  • Platform: Foxglove Studio on OSX, Foxglove Web Bridge on Linux
  • Data source: Only affects streaming from a live system. Does not appear to affect loading a MCAP file directly into studio.

Steps To Reproduce

Take a look at this simple launch file that sets up a basic static transform hierarchy:
https://gist.github.com/asymingt/1d833ac9857ecba36eb2fa523137a7ba

Launch like this from a ROS2 rolling distribution:

$ ros2 launch static_frame_issue.launch.py

Confirm you see the correct frames with:

$ ros2 topic echo /tf_static
transforms:
- header:
    stamp:
      sec: 1687902344
      nanosec: 58697684
    frame_id: bar_child1
  child_frame_id: bar_child1_grandchild
  transform:
    translation:
      x: 0.0
      y: 0.0
      z: 0.0
    rotation:
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
---
transforms:
- header:
    stamp:
      sec: 1687902344
      nanosec: 55601655
    frame_id: bar
  child_frame_id: foo
  transform:
    translation:
      x: 0.0
      y: 0.0
      z: 0.0
    rotation:
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
---
transforms:
- header:
    stamp:
      sec: 1687902344
      nanosec: 54859102
    frame_id: bar
  child_frame_id: bar_child1
  transform:
    translation:
      x: 0.5
      y: 1.0
      z: 2.0
    rotation:
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
---
transforms:
- header:
    stamp:
      sec: 1687902344
      nanosec: 56240568
    frame_id: bar_child2
  child_frame_id: bar_child2_grandchild
  transform:
    translation:
      x: 0.0
      y: 0.0
      z: 0.0
    rotation:
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
---
transforms:
- header:
    stamp:
      sec: 1687902344
      nanosec: 56478622
    frame_id: bar
  child_frame_id: bar_child2
  transform:
    translation:
      x: 0.5
      y: -1.0
      z: 2.0
    rotation:
      x: 0.0
      y: 0.0
      z: 0.0
      w: 1.0
---

Expected Behavior

I would expect to see a transform hierarchy that looks like this, in both the Transforms section of the 3D panel, as well as in the 3D visualization itself:

+ baz
  + bar
    + bar_child1
      + bar_child1_grandchild
    + bar_child2
      + bar_child2_grandchild
    + foo

However, only a subset of the frames are actually received and drawn. So, for example sometimes you see this:

+ baz
  + bar
    + bar_child1
      + bar_child1_grandchild

And sometimes you see this:

+ baz
  + bar
    + bar_child2
      + bar_child2_grandchild

Example screenshot of the problematic Transforms panel:

Screen Shot 2023-06-27 at 2 30 44 PM

Example screenshot of the problematic 3D window:

Screen Shot 2023-06-27 at 2 32 04 PM
@asymingt asymingt added the bug Something isn't working label Jun 27, 2023
@foxhubber
Copy link

foxhubber bot commented Jun 27, 2023

Internal tracking ticket: FG-4047

@achim-k
Copy link
Collaborator

achim-k commented Jun 28, 2023 •
edited

Launch like this from a ROS2 rolling distribution:

$ ros2 launch static_frame_issue.launch.py

Confirm you see the correct frames with:

Note that ros2 topic echo also doesn't show all transforms: You publish 6 transforms, but ros2 topic echo only shows 5 messages. The transform baz-bar is not printed.

You can fix this by increasing the qos depth:

ros2 topic echo --qos-depth 10 --qos-durability transient_local --qos-reliability reliable /tf_static

You can do the same for foxglove bridge:

ros2 launch foxglove_bridge foxglove_bridge_launch.xml min_qos_depth:=10

I believe that this solves your issue?

@achim-k achim-k mentioned this issue Jun 28, 2023
Closed
@achim-k
Copy link
Collaborator

achim-k commented Jun 28, 2023 •
edited

Doing ros2 topic info -v /tf_static, I can see that the depth of the /tf_static publishers is reported as UNKNOWN (using the default rmw). This probably prevents foxglove_bridge to select an appropriate QoS depth. Maybe we can use a fallback depth of 1 if the publisher's depth could not be determined.

QoS profile:
  Reliability: RELIABLE
  History (Depth): UNKNOWN
  Durability: TRANSIENT_LOCAL
  Lifespan: Infinite
  Deadline: Infinite
  Liveliness: AUTOMATIC
  Liveliness lease duration: Infinite

Edit: This depends on the used RMW:

RMW History
rmw_fastrtps_cpp (default on iron) UNKNOWN
rmw_connextdds UNKNOWN
rmw_cyclonedds_cpp KEEP_LAST (1)

@asymingt
Copy link
Author

I'm just conforming that I am using RTI ConnextDDS, so depth UNKNOWN applies to my case, and may be the cause of the issue.

@asymingt
Copy link
Author

@achim-k I can confirm that your proposed fix min_qos_depth:=10 works well for me! Is there any way we might be able to make that the default argument, or have a longer default fallback depth in the case the bridge detects it as UNKNOWN?

@achim-k
Copy link
Collaborator

achim-k commented Jun 29, 2023

Is there any way we might be able to make that the default argument, or have a longer default fallback depth in the case the bridge detects it as UNKNOWN?

Yes, we have to be smarter here. Will transfer this issue to https://github.com/foxglove/ros-foxglove-bridge and submit a PR that fixes it.

@achim-k achim-k transferred this issue from foxglove/studio Jun 29, 2023
achim-k added a commit that referenced this issue Jun 30, 2023
@achim-k
Assume a publisher qos depth of 1 if RMW does not store the history d…
331835d 
…epth

Some RMWs do not retrieve history information of the publisher endpoint
in which case the history depth is 0. We use a lower limit of 1 here,
so that the history depth is at least equal to the number of publishers.
This covers the case where there are multiple transient_local publishers
with a depth of 1 (e.g. multiple tf_static transform broadcasters).
See also
#238 and
#208
@achim-k achim-k mentioned this issue Jun 30, 2023
Merged
achim-k added a commit that referenced this issue Jul 5, 2023
@achim-k
Assume publisher qos depth of 1 if the middleware reports the qos his…
6660b0d 
…tory as unknown (#239)

### Public-Facing Changes

Assume publisher qos depth of 1 if the middleware reports the qos
history as unknown

### Description
Some RMWs do not report history information of a publisher endpoint in
which case the history depth is reported as 0. We internally use this
depth to calculate an appropriate depth for the subscription, which uses
the `KeepLast(depth)` history policy.
In case a publisher's history depth is reported as 0, we assume a depth
of 1 so that the final history depth is at least equal to the number of
publishers. This covers the case where there are multiple
transient_local publishers with a depth of 1 (e.g. multiple tf_static
transform broadcasters). Before this PR, a user would have to manually
specify a `min_qos_depth` of N when having N tf_static broadcasters.

This PR also increases the max qos depth default value, 10 seemed very
low. I'm not sure anymore why we added an upper limit in the first
place. Additionally, a warning is logged when the upper limit is
reached.

Fixes #238 
See also #208
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Milestone
No milestone
2 participants
@asymingt @achim-k