Open yzpd opened 2 years ago
@yzpd Thanks for raising the issue
@rob-clarke Looking at the state mavros ros2 #128 will be delayed further. Ideally we could just bridge all of the topics for students. However, in the flight arena we are running into a ROS2 discovery issue where (I believe) all of the ros2 topics are bottlenecking the networking with their discovery packets causing other rosnodes to malfunction.
My proposal is that we switch the bridge setup (and manual namespacing) to container runtime. The bridge configuration is only required during the running of the parameter bridge, and not required at runtime.
BRIDGE_CONFIGURATION={MINIMAL | TELEMETRY | ALL}
, defaulting to MINIMAL
As I understand the bridge config is already taking place at runtime. We should just be able to set BRIDGE_MOD_CONFIG_PATH
and MAVROS_MOD_CONFIG_PATH
and the container will use those? I guess a flag for "do it dynamically" could be added?
On the ROS2 discovery issue, is that likely to be problematic with MAVROS2? Or is it just because the bridge is trying to forward every topic?
Ah you are right, all you need to do is set BRIDGE_CONFIG_PATH
and it will autogen BRIDGE_MOD_CONFIG_PATH
for us. But we still need to pass in a configuration - unless we have a couple of preset configurations that a user can choose from.
On ROS2 discovery. tbh I am not sure. If Mavros2 has the same number of topics then that might be an issue too. In which case we have to properly make use of the white/black lists. I think it is also an issue that the bridge is forwarding every topic right now. However, I also think that it might be a hardware issue - the old flight arena pcs not keeping up with the rates (at least more likely then bottlenecking the network)...
global_position/local is not supported in current mavros version