Incorrect vehicle ID in WS messages

Blue Robotics Software Cockpit (beta)
1 
{"header":{"system_id":255,"component_id":240,"sequence":0},"message":{"type":"COMMAND_LONG"
,"param1":1,"param2":0,"param3":0,"param4":0,"param5":0,"param6":0,"param7":0,"command":{"type":"MAV_CMD_COMPONENT_ARM_DISARM"}
,"target_system":1,"target_component":1,"confirmation":0}} //target_system 1 instead of 42

The vehicle ID of the robot is not 1, its 42. It is visible in mavlink2rest under “42”.
Is there something that I am supposed to do, or is this supposed to be automagically handled (but is not as of yet). Any workarounds for the time being, so that I can get some more testing done?

I suspect this not only affects WS send stuff, cus I am also missing a lot of other information I am expecting to be there, so I kind of get the impression that stuff is atm only looking at vehicle_id 1.

BlueOS 1.1.1, cockpit v1.0.0-beta.7

2

Hi @goasChris, welcome to the forum :slight_smile:

That is apparently the case, and it’s seemingly a reasonably deep issue (since it’s also a problem for some of the components Cockpit is reliant on).

Is it possible for you to use vehicle ID 1 in the interim, or is your vehicle part of a fleet that makes that impractical to do?

3

It is unfortunately not possible for me to do in our fleet :sweat_smile:

My entire infra and data gathering is built on distinguishing robots based on vehicle_id unfortunately.
Its ok, I can wait, just checking to see if I can progress in testing by using some sort of workaround in the interim. Thank you for the swift response :slight_smile:

1 Like
4

Thank you for understanding and for your patience, Chris.

I will take a look at this issue again in the next days to see how much of work it is. I can see it maybe not being that much hard on the Cockpit side, but as @EliotBR mentioned, we are not yet sure that this would not require changes also on the mavlink-camera-manager and BlueOS.

To understand the problem better:

  1. You said your vehicle is already running BlueOS. Have you configured the ID there or only on Ardupilot?
  2. You mentioned robots. Are you using video? If so, are you using mavlink-camera-manager (BlueOS regular video streams) for that?
5

Heh, its interesting you should mention that. I was under the impression that my test bot was a bit wonky, because cameras have been quite bothersome at times.

Suddenly they work great for a day, and then suddenly I have to fight to even get them into blueOS at all (not cockpits fault). I did not mention it, because I didn’t think it would be relevant.

However, that could certainly be the reason as to why I am struggling with the cameras. When the cameras are working, they work perfectly in cockpit as far as I can tell. Its just that a lot of the time, they are not (again, in blueOS, at all) :stuck_out_tongue:

  1. I have configured the ID every which way I know how (sysid this mav, or whatever it is called). Its what I use via mav2rest, it’s what I use to talk via websockets (still mav2rest). Its what QGC uses when it talks to the robots. The entire fleet has been running a slightly older version of blueOS, and the cameras have been well behaved, even with a non “1” vehicle_id.

However, we do not use the cameras in the traditional way. We don’t want (or have) them in qGroundControl. We access the RTSP streams directly from a video server we run.

If we get everything working we cockpit, then I’ll probably remove that service tho, so I do want the cameras.

I am honestly not sure what is meant by “configuring the vehicle_id / sysid_thismav in Ardupilot”. At least that is how I interpreted the question. It is set on the robot as a param, and it gets used everywhere. Im sorry if I am unable to properly answer the question.

— end of question 1 —
Question 2:
Yes, we use video. I don’t think we use the mavlink-camera-manager. We might rely on it to setup the RTSP streams initially, and maybe, perhaps to change stuff like brightness etc. We like to access cameras when necessary, instead of them being forced upon as, like it used to be many months ago, when we ran a different setup.

I believe the answer is No. I don’t think we actually use it (currently, in production).
— end question 2 —

I wanted to ask. Is there a discord or similar community to talk about cockpit currently?

2 Likes
6

About the first question, there’s a parameter in Ardupilot called SYSID_THISMAV that you have to set to your desired ID.

And there’s a discord indeed! We opened it in the end of the last year! You can access it here.

7

Yes, I mean I have set the SYSID_THISMAV. That is what I call robot id. I don’t know of any way to set a different kind of id in blueOS.

BlueOS runs on a docker container inside the pi (which is inside the robot).
Thats the only place we run it. We use QGC as our GC currently.

8

Perfect!

I think that with the PR that you proposed we should be ready to go in terms of telemetry.

In therms of video streams, BlueOS currently does not use the correct ID (it always fallback to 1). I’ve opened an issue to track this fix.