Home        Store        Learn        Blog

Teleop_joy and SITL

Hi, I am attempting to control a SITL instance of the BlueROV2 via mavlink and the teleop_joy project found here:

I am using an XBox controller and I have edited the launch file to match what I see in /dev/. I can arm and set modes via the controller just fine, it’s just the actual movement I dont see in gazebo.

Since I am also running the bluerov playground I can see the topics in /joy change when I move the joysticks. Also there are topics under /BlueROV and /mavros I can see and they seem to be similar values, but /BlueROV is slower to update. What is the difference between these two?

Hi,

Are you talking about the gazebo simulation in bluerov-ros-playground ? For that you’ll need to run SITL running, can you check if the /mavros topics are all updated ? Can you connect QGC without bluerov-ros-pkg ?

Its connecting now. Not sure why it did not earlier. It does state “Parameters are missing from firmware COMPASS_PRIMARY”

It may be a problem related to the firmware version that you running, but you can set the first compass as primary.

OK, I got QGC to communicate with the joystick and SITL by changing its SYSID_MGCS=1 rather than 255. It was actually 254 at first, and Im not sure why.

This brings me to 3 questions:

The teleop_joy project mentioned earlier does not seem to set SYSID_MGCS at any time. Perhaps that is why it is not working?

I reviewed the blue_rov_playground code found below, and I cant find it there either.

Finally, in said code, in pubs.py, line 102, it seems to be continuously sending [1201, 1200, 1200, 1200, 1200, 1200, 1200, 1205] to mavros/rc/override. WHY?? See here:

Interestingly, the gazebo_sitl.launch file actually specifies the sys ID:

But Im not sure then why I had to make GCS sysid 1

The teleop_joy project mentioned earlier does not seem to set SYSID_MGCS at any time. Perhaps that is why it is not working?

teleop_joy is a generic ROS service, there is no connection with MAVLINK related protocol or interface.

Pubs is a class that is used to abstract ROS publications, if you run the Pubs class it’ll execute the test script in the bottom, that as you saw, will set all channels to 1200.

The Ground Station ID only needs to be configured when multiple softwares are controlling the ROV at the same time, like the mavlink code that does the bridge between mavlink-ROS and QGC.

“The Ground Station ID only needs to be configured when multiple softwares are controlling the ROV at the same time, like the mavlink code that does the bridge between mavlink-ROS and QGC.”

Thank you! Where does the mavlink-ROS bridge actually set the SYSID? I looked for it and cannot find it.

Also, I could not find where the bridge or associated classes sent heartbeat signals.

This is done by mavros directly.

OK!

Ive reviewed mavros and your bridge and I was wondering

Is there a reason why you used pymavlink and pyros to write your own bridge instead of using mavros?

Is there something in mavros that means I should avoid using it?

The bridge doesnt use mavros, does it?

Hi @rdehart,

Yes it does, you can check the usage of mavros here, for more information check the README.

You can run the same code without ROS.

Ah, I should clarify. The bridge doesn’t call mavros functions, does it?

Hi @rdehart,

mavros is a ros package, it is like a service that provides mavlink messages via ros topics. There is no need to call functions of the package, the only that is being used is the mavlink abstraction from mavros and the information for the mavros specific messages.

So is the bridge acting as a GCS? This goes back to my heartbeat question (see above). If I post a ROS topic that sends a rcoverride command via the bridge, I have to be a GCS, right? And if so, I have to be sending heartbeats?

OK, I think I have answered the previous question for myself now.

However, I dont fully understand WHEN one should launch with user_mav.launch and when one should launch with bluerov2_node.launch. In fact, it would seem that both user_mav.launch and bluerov2_node.launch eventually call user.py as “user_node”. The Readme provides no clarification if one is supposed to be run when SITL is running only, or if the blue rov is running only, which is what I suspect.