Contributing to robot web tools - seeking guidance

General
,
1

I apologize in advance if this question is better suited for robotic stack exchange; given as I am not seeking a technical solution to a technical question this felt llike the better location.

For context, I’ve been working in robotics for over a decade now but am relatively new to ROS. The system’s I’ve worked on previously have been proprietary/closed-source, but have included large generalized DDS middlewares with numerous similarities to ROS.

Currently I am working with some of the robot web tool projects – specifically rosbridge_server and related client APIs – and I am running into some issues that I would like to resolve. However, I am running into the roadblock of lack of maintainer interaction and guidance and I am not sure how to procede. I would like to avoid forking projects or maintaining my own set of changes on top of the standard distribution if at all possible; but more importantly, I want to get involved and I want to contribute.

In the webtools case, there are two open issues that I am involved with, one which I opened and one which someone else opened, both of which I am willing to spend time coming up with a fix. Before proceding in implementing a solution, I would like some feedback about what is the correct approach before investing time in an implementation that ultimately wont be accepted, but beyond opening an issue and waiting, I am at a loss for what to do.

I see that the robot web tools working group was disbanded 2-3 years ago in favor of the foxglove community meetups. I also see that foxglove wrote their own replacement for the rosbridge_server (note at least my two most pressing issues deal with that application but the solution may also extend into other repos). Of course, I also know foxglove recently went closed source. This all just raises more questions for me.

So, first and foremost, what is the state of rosbridge_server and robot web tools. Is there still development going on here or have people moved on to something else and I should be investing my time elsewhere?

In the former case, how do I get involved when faced with the lack of feedback on opened issues? Do I just make the changes I see best fit and hope for the best? Do I need to just maintain my own custom fork and that just is how it is?

Perhaps I am being impatient, but noting the lack of feedback on some other’s issues as well gives me concern that if I resort to waiting I will be waiting for a very long time.

2 Likes
2

I’m not sure of a better way to say this, but if you have issues to be fixed, you have the ability to fix them, and the repos are open-source, what stands in your way?

For context: A former colleague and I worked on signficant improvements to rosbridge_server and roslibjs last year, which included ROS 2 action support. We were even granted maintainer access to help us move things along. So I can first-hand tell you that this is very much doable!

EDIT: I now see your question is more about high level guidance. Indeed Foxglove is not actively involved in these tools anymore, but many others in the OSS community are. Namely, all the folks using roslibpy, roslibjs, roslibrust, etc. So your efforts would not be wasted in contributing: just that you may not have anyone helping you do the actual contributions.

EDIT 2: As a maintainer of RobotWebTools, I would be happy to review your PRs if/when you have any.

3

Could Foxglove 1.x be forked by ROS as community effort (ROSglove :rofl:)? I don’t know about licenses as I haven’t used Foxglove, but I think it too was fork of open source Webwiz

4

@JayHerpin thanks for your well articulated post. I was part of the working group when it was still meeting and I want to add some nuance.

Yes, there are several projects on https://robotwebtools.github.io/ that no longer seem to be maintained. However, Robot Web Tools is not one project or one group. It is a collection of projects, run by disjoint groups, and many of the projects listed there are still in very active development, incl. Foxglove, (my own) Transitive, and rclnodejs, and rosnodejs is stable and used in production.

As for rosbridge: can you describe what you are planning to use it for? In my experience, a direct connection from the browser to the robot is the wrong architecture, which is why I created Transitive, incl. mqtt-sync. Transitive instead focuses on selectively synchronizing data between robots and the cloud, and separately between the cloud and the web (browsers). This way, the web pages and data are always available, even when the robot loses network connectivity or is offline. In addition, mqtt-sync can significantly reduce bandwidth usage as it avoids sending duplicate data.

5

You are absolutely right, nothing does stand in my way; however given that I am relatively new to the ROS ecosystem, I do not necessarily trust my own judgment in aligning my efforts with any long term plans for those tools.

If jumping in sans discussion/guidance (or rather, if attempts at discussion are not fuitful) is the correct way forward, then that’s my answer and I will happily do so. I was just concerned about wasted effort; either in terms of implementing something in a way not compatible with the long term roadmap or by spending time improving something that is soon to be abandoned.

1 Like
6

Thanks for pointing me at mqtt-sync.

As this project is relatively young, at the moment we are running the web server directly on the platform, however that is not the long term plan. I am of the same mind as you in that I do intend to move the web server into the cloud at somepoint and use a different mechanism for offloading the data.

I’ve scouted around for tools to assist with that and will definately add mqtt-sync to my list for evaluation once we move to that phase of the project. Thanks for that!

1 Like
7

Yeah, I think the repos in this org are not trafficked enough where you’ll find a large group of people engaging in discussion. So I’d recommend taking the “do first, ask for forgiveness later” approach in this case, despite your very valid concerns about this.

The great thing about open source is that if your changes break someone else’s workflow, they can either fix/update it themselves, roll back to an older commit, fork, etc.

Also, and this is mostly my opinion, there are many more users of these tools than people willing to work on them. So even though the maintainer activity doesn’t look super hot, rest assured that the tools are being used!

2 Likes
8

It has already happened in terms of the bridge server :smile: There’s ROS Websocket Server which supports both ws_protocol and the rosbridge protocol so it can act as a drop in replacement for either. Still a bit rough around the edges since it’s not widely used yet, and has some minor limitations, but it’s quite a bit more performant than rosbridge.

9

I did take a look at that package. I was messing around with your package vizanti (very cool BTW!) and saw that is what you are using.

1 Like
10

Seems that the license is MPL so it could be forked.
I’m using foxglove and was also wondering if an active fork existed. I just saw that bmw is working on a fork called foxbox : GitHub - bmw-software-engineering/foxbox