StarlingUAS / ProjectStarling

BRL Flight Arena Infrastructure 2.0
Other
16 stars 3 forks source link

Mavros bridge: global_position/local is not supported #154

Open yzpd opened 2 years ago

yzpd commented 2 years ago

global_position/local is not supported in current mavros version

mhl787156 commented 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.

rob-clarke commented 2 years ago

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?

mhl787156 commented 2 years ago

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)...