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

Missing state transition messages #174

Closed
rgov opened this issue Feb 27, 2023 · 6 comments
Closed

Missing state transition messages #174

rgov opened this issue Feb 27, 2023 · 6 comments
Labels
bug Something isn't working

Comments

@rgov
Copy link

rgov commented Feb 27, 2023

ros-noetic-foxglove-bridge/now 0.3.0-1focal.20230106.232224 arm64 [installed,local]

Streaming data from a system to Foxglove Studio (1.39.1; Darwin), I was surprised that my state transition panel seemed to be stuck on the same state since connection, even though the system was progressing through other states.

When I pulled the rosbag afterwards, I saw indeed the state transition messages were being sent:

image

(I only broadcast the message once per state transition, I don't spam the current state to the topic.)

Other messages seemed to get through; I had an image panel that updated occasionally as expected (though I didn't watch it carefully).

What is the behavior regarding when messages get dropped? If I have a high bandwidth topic, will it elbow out small topics?

@rgov rgov added the bug Something isn't working label Feb 27, 2023
@foxhubber
Copy link

foxhubber bot commented Feb 27, 2023

Linear: FG-2202

@achim-k
Copy link
Collaborator

achim-k commented Feb 27, 2023

What is the behavior regarding when messages get dropped? If I have a high bandwidth topic, will it elbow out small topics?

The current behavior is rather simple and does not take into account which topic a message originates from. This is something we have to improve on in the future.

Are you sure that messages are dropped? Do you see the corresponding log messages?

On another note, the 0.3-0 release is rather outdated. I would recommend building the latest version from source or to wait for the next noetic sync (which seems to be just a couple of days away)

@achim-k
Copy link
Collaborator

achim-k commented Mar 9, 2023

@rgov do you have any update on this? Do you still have this issue?

@rgov
Copy link
Author

rgov commented Mar 9, 2023

Has anything changed with the algorithm? I haven't really used it since filing this. My system is offline for a few days.

@achim-k
Copy link
Collaborator

achim-k commented Mar 9, 2023

Has anything changed with the algorithm?

No it's still the same. But we are definitely open to improve on that. Have you had the same issue with rosbridge?

achim-k added a commit that referenced this issue Mar 13, 2023
### Public-Facing Changes
- Do not allow connection output buffer to exceed configured limit

### Description
Makes sure that we only put messages in the output buffer if they do not
cause the output buffer to exceed the user configured limit.

This mitigates that larger messages (images / pointclouds, ...) prevent
smaller messages from being sent (see #174)
@defunctzombie
Copy link
Contributor

Since the ros-foxglove-bridge server side can get backed-up under certain workloads, I think a reasonable enhancement to resolve this poor UX experience would be for the server to send a warning Status when it drops data. While this won't solve the problem of dropping the data, this will give visibility into what happened so you don't think "this panel has failed" but instead realize "oh my data connection could not keep up".

achim-k added a commit that referenced this issue Mar 27, 2023
### Public-Facing Changes

- Notify client when Server's send buffer limit has been reached

### Description
Rather than only logging a message, the client is now also informed when
the server is about to drop messages due to the send buffer limit being
exceeded. See
#174 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

No branches or pull requests

3 participants