Hi all,
I am trying to send commands and get the results for them via arduino, which is connected to telem2.
I have successfully sent command_long and can confirm the results on QGC, but command_ack doesn’t seem to be sent to telem2.
In order to get command_ack from telem2, what sysid/compid should I include in the command_long?
Thanks
Is MAVLink communication working at all on Telem 2 for you? I would verify that first. And please provide the PX4 version that you are using.
Thank you for a reply.
When I send Arm/Disarm command via Telem 2, I can confirm on QGC(connected to Telem 1) that the pixhawk is armed/disarmed. So yes, I think MAVLink communication is working at least partially.
I am using px4 v1.8.2.
Ok, so it sounds like something of your serial reading or mavlink parsing on the Arduino side is wrong. I can’t really help though without seeing any source.
Excuse me,
I’m sorry I can’t answer your question. and I have a question about how to send armed/disarmed to px4.
Thanks.
Following on this… I have a Cube autopilot running PX4 4.2.1 firmware. I am running the mavlink/c_uart_interface_example to verify connectivity between the PX4 and a companion Jetson Xavier. I had previously tried a Pi with the same result.
So, with the Cube connected to the Jetson via TELEM2 and USB. If I open the connection to the cube, I can get to the point where I see the vehicle system id and autopilot component id but then the example just sits and waits. At this point, it is supposed to provide initial position xyz values… but it just waits.
Using another computer running QGroundControl, I can get QGroundControl to connect to TELEM2 using the same cable and it reports “ready”. I then disconnect the other computer and connect the cable back into the Jetson (or Pi) and run the same example c_uart_example code, and it connects properly, gets the position values, and puts the vehicle into off board mode.
This works perfectly every time, provided I first connect to the Cube using QGroundControl.
So, my question is… does QGroundControl do something else after connection to get the CubeAutopilot to talk over TELEM2 that the example is not doing? I can seem to get anything to work unless first using the port via QGroundControl.
Any thoughts or help would be most appreciated.
This sounds like an ArduPilot version, not PX4 (unless you’re coming from the future 
).
This forum is mostly for PX4, not ArduPilot.
LOL… sorry you are correct… it’s a Blue Cube… running ArduPilot firmware. I knew that… for some reason I was not making the connection. So right… I need to post this on the Ardupilot forum.
On a tangent here… but I assumed that the operation of PX4 and Ardupilot were quite similar. I am wondering if this is something particular with the Cube… or Ardupilot itself.
Anyway, thanks for the correction 
Both use the mavlink protocol yes, but when it comes to the messages used and how, there are often subtle differences which can make a big difference such as “works” or “doesn’t work”, so it depends on the case.
So I posted something similar over at the Ardu forum, but I got no response. I am slowing narrowing in on the problem, but I am still missing something. I am running the OrangeCube firmware (Ardu) on a Cube Autopilot with a Herelink system. I am also using mavsdk_server as the software interface between a computer and the autopilot.
The autopilot and the computer are connected to each other using a USB/Serial adapter on the TELEM2 interface which is configured for MAVLINK2 protocol at 57,600 baud.
I power on the drone and connect up the Herelink controller, then connect the computer and drone together via the USB/Serial cable. I can then launch mavsdk_server on USB0 and it will connect to the drone and start sending out the following:
[05:50:37|Info ] MAVSDK version: v1.4.13 (mavsdk_impl.cpp:20)
[05:50:37|Info ] Waiting to discover system on serial:///dev/ttyUSB1... (connection_initiator.h:20)
[05:50:37|Debug] New: System ID: 1 Comp ID: 1 (mavsdk_impl.cpp:496)
[05:50:37|Debug] Component Autopilot (1) added. (system_impl.cpp:377)
[05:50:37|Debug] New: System ID: 42 Comp ID: 100 (mavsdk_impl.cpp:496)
[05:50:37|Debug] Component Camera 1 (100) added. (system_impl.cpp:377)
[05:50:37|Debug] Discovered 1 component(s) (system_impl.cpp:578)
[05:50:37|Debug] New: System ID: 10 Comp ID: 250 (mavsdk_impl.cpp:496)
[05:50:37|Debug] Component Unsupported component (250) added. (system_impl.cpp:377)
[05:50:37|Debug] Discovered 1 component(s) (system_impl.cpp:578)
[05:50:37|Warn ] Vehicle type changed (new type: 13, old type: 0) (system_impl.cpp:225)
[05:50:37|Debug] Discovered 1 component(s) (system_impl.cpp:578)
[05:50:37|Info ] System discovered (connection_initiator.h:63)
[05:50:37|Info ] Server started (grpc_server.cpp:53)
[05:50:37|Info ] Server set to listen on 0.0.0.0:50051 (grpc_server.cpp:54)
[05:50:38|Debug] Component Unsupported component (190) added. (system_impl.cpp:377)
[05:50:39|Debug] Component Unsupported component (250) added. (system_impl.cpp:377)
[05:50:45|Debug] MAVLink: critical: PreArm: GPS 1: Bad fix (system_impl.cpp:250)
[05:50:45|Debug] MAVLink: critical: PreArm: Battery 1 low voltage failsafe (system_impl.cpp:250)
[05:50:57|Info ] heartbeats timed out (system_impl.cpp:272)
[05:53:51|Debug] MAVLink: critical: PreArm: Battery 1 low voltage failsafe (system_impl.cpp:250)
As you can see from the log data, mavsdk_server is receiving data from the autopilot regarding various fail-safe issues. I then launch the telemetry.py script from the MAVSDK examples. It connects successfully to the drone through the instance of mavsdk_server that I have running. After that… it then sits and does nothing, waiting for data from the async information requests. It never does anything.
Now, if I stop the script and mavsdk_server and launch QGroundControl, it will connect automatically to the drone over the TELEM2 port and start reporting the same failsafe information, etc. I can then stop QGroundControl, disconnecting it from the drone, and again launch mavsdk_server, which connects pretty much the same way as before.
However, now when I launch the telemetry.py script, it connects to mavsdk_server and starts to print telemetry and battery data as it should.
I initially thought that the TELEM2 port was just waiting for some kind of wakeup signal to start sending mavlink data… however, it appears that with the initial connection, mavsdk_server is getting data (i.e. status of battery failsafe)… but for some reason nothing else. It is only after connecting and disconnecting QGroundControl will the port start to send telemetry data.
The only thing that I see that may be related is this line in the output…
``[05:50:57|Info ] heartbeats timed out (system_impl.cpp:272)```
However, if I stop mavsdk_server and let the drone sit for hours… with nothing talking to it… then relaunch mavsdk_server, it will still allow the telemetry.py script to work. It only stops working after turning off the drone and restarting it. At that point, I need to reconnect and disconnect QGroundControl. I know this may be an Ardu issue, but I was hoping that maybe somebody could point me into the right place in the QGroundControl or mavsdk_server code that would allow me to continue to troubleshoot this. Obviously, QGroundControl is sending something to the port that is making this work correctly… that mavsdk_server is not. I would like to try and replicate that in my code (or change mavsdk_server) and eliminate having to start and stop QGrounControl before each flight.
Any advice would be helpful.
Hi there
I was able to get similar bug using PX4_SITL Gazebo simulator on a local host ubuntu 20.0.4 platform . i have also posted this on the PX4 discord forum today . I ran the disarm command using pymavlink script and i see that during an ongoing QGC mission everything disconnects which should not be the case. I also saw the mavsdk providing telemetry at times . In my case i also have the mavros launched . I see that we have to either work thro Mavsdk or Mavros else here again things get weird with QGC disconnecting itself. !!
Could it be that you need to configure the rate of the telemetry streams manually with ArduPilot, otherwise nothing is sent by default?
Do you see any information if you request a topic using e.g. set_rate_position?
@JulianOes thanks for the clue. I finally got around to make the change… and yes, you are correct. It looks like ArduPilot (or at least the CubePilot A/P we are using) initially configures the serial port parameters (i.e. SRx_) with zero hertz values, so on A/P startup, no data is sent. This appears to happen in hardware and SITL.
One can certainly set the parameter values directly in the autopilot, but sending a set_rate_position command on the connected port gets it talking.