ardupilot / mavlink Goto Github PK

Please include the definition for MAV_ODID_STATUS_REMOTE_ID_SYSTEM_FAILURE to allow reporting of Remote ID system failure.

Dear all,

I got lost a little bit.
I want to send and receive messages in java.
I can send the commands and control the drone with mavproxy

how I can achieve that in java?

thanks for the help

zeev

I am working on this commit 59ccf285025b0dad2fbd8b111d24801e9f16cb20 of mavlink in this version submodule just got crashed due to ssh clone request but when I use http path it works fine no time out.

Submodule 'pymavlink' (git://github.com/ArduPilot/pymavlink.git) registered for path 'modules/mavlink/pymavlink'
Cloning into 'modules/mavlink/pymavlink'...
fatal: unable to connect to github.com:
github.com[0: 140.82.121.3]: errno=Connection timed out

please let me know if I am doing something wrong.

[Not sure if this should be considered an ArduPilot/MAVLink issue or a MAVLink/MAVLink upstream one but feel here's the best place to start]

The "ardupilotmega" dialect defines a RADIO message with the same field names and types as the "common" RADIO_STATUS message (with a different ID).

ArduPilot appears to treat both messages the same in MAVLink handling code, e.g.: https://github.com/ArduPilot/ardupilot/blob/master/ArduCopter/GCS_Mavlink.cpp#L1283 .

In ardupilotmega against the RADIO message, txbuf is described as being How full the tx buffer is as a percentage [ https://mavlink.io/en/messages/ardupilotmega.html#RADIO , https://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/ardupilotmega.xml#L1236 ] and in common, the inverse (Remaining free transmitter buffer space) [ https://mavlink.io/en/messages/common.html#RADIO_STATUS , https://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/common.xml#L4092 ] for RADIO_STATUS.

Sending a RADIO message to ArduPilot with txbuf set to 0 to indicate, according to its description, that "the tx buffer" is 0% full leads to it throttling back messaging (see GCS_MAVLINK::handle_radio_status()).

Is the ardupilotmega description of the RADIO messages txbuf flag in need of correction? Should the RADIO and RADIO_STATUS messages be treated differently?

So I see:
https://github.com/ArduPilot/mavlink/blob/master/message_definitions/v1.0/ardupilotmega.xml

1.0 ? - why is there no /2.0/ - is it a purely cosmetic thing?

nor can I see message 244 (MESSAGE_INTERVAL) - nor is it in common

my program (on a microcontroller) is fine with this line:

 mavlink_msg_param_request_read_send(MAVLINK_COMM_0, apm_mav_system, apm_mav_component, "BATT2_CRT_VOLT",-1);

but this one fails to set VFR_HUD rate on telemetry.

mavlink_msg_message_interval_send(MAVLINK_COMM_0, MAVLINK_MSG_ID_VFR_HUD, 500000);

no error - just that it does not work (it sends a 244 packet.)

I'm trying to use MAVSDK to communicate with ArduCopter and it seems MAVSDK is mainly targeted for PX4 but I wonder if it will work if I swap the default mavlink library with the mavlink fork from here. I'm also curious what's the main reason to maintain a fork of mavlink here.

sub4.0 cloning process Pymavlink, currently this source cannot be cloned

The vast majority of messages from the Gimbal v2 protocol are missing from common.xml (e.g. GIMBAL_MANAGER_INFORMATION - 280, GIMBAL_MANAGER_STATUS - 281 etc).

Is this omission an intentional decision? Upstream has had these messages for a while now. It is technically still marked as WIP in the documentation, but other WIP messages - including the gimbal v2 device messages - are included.