Add a network debugging tool to help with common connection problems

[fmauch]

This aims at solving #66

As questions about setting up the network configuration often popup and the approach to debug them is always the same, I've wrapped some of those steps into a helper script that should get started alongside with the driver.

ToDo:

• [ ] Check the robot's installation for remote IP and port (I currently do now know how to do that)
• [x] Add hints / guide on checking most common firewalls
• [ ] Include into launchfiles with a flag

Runtime checks

We could add runtime checks, as well, but that should probably go to a separate script / be activated through a service call

• [ ] Check if controllers are running
• [ ] Check if the robot can currently accept commands

[gavanderhoorn]

High-level initial feedback: don't use rospy here.

I'd make this a stand-alone tool, which still checks the same things, but doesn't use ROS parameters or logging.

That decouples multiple problem domains, and would also make it possible to run this on OS which ROS doesn't OotB support / has different level of support for (like Windows).

An argparse-based implementation should easily allow this.

[fmauch]

High-level initial feedback: don't use rospy here.

I'd make this a stand-alone tool, which still checks the same things, but doesn't use ROS parameters or logging.

That decouples multiple problem domains, and would also make it possible to run this on OS which ROS doesn't OotB support / has different level of support for (like Windows).

An argparse-based implementation should easily allow this.

Actually I started with exactly that. Then I realized, that it might be good to query as much configuration as possible from the driver's setup (such as robot_ip, reverse_port, etc.) I am still unsure whether the benefits are worth it tying it to ROS, though. (Especially, since we want to use the same thing for ROS2, as well...)

[gavanderhoorn]

There are other ways of getting that information, such as parsing the .launch files or loading the .yaml files.

Whether that's worth the extra effort I don't know.

There is certainly value in using the same parameters while attempting to diagnose problems, as one potential cause of those problems could exactly be those parameters.

[fmauch]

I think I'll stick with getting the parameters from the parameter server, but I'll reduce the overall dependency on ROS so we can more easily re-use this for ROS2.

[github-actions[bot]]

This PR hasn't made any progress for quite some time and will be closed soon. Please comment if it is still relevant.

[fmauch]

this is still on my whishlist...

[github-actions[bot]]

This PR hasn't made any progress for quite some time and will be closed soon. Please comment if it is still relevant.