mavlink
Is there any tutorial explaining connecting to real done instead of SITL using mavsdk?
I am new to MAVLINK/ MAVSDK, tried https://auterion.com/getting-started-with-mavsdk-python/, to run examples provided with mavsdk using jmavSIM which worked well. However, I need more information as how to connect to Pixhawk4 via USB using mavsdk. Thanks for any help!
Have a look here: http://mavsdk-python-docs.s3-website.eu-central-1.amazonaws.com/system.html?highlight=serial#mavsdk.system.System.connect
It should be something like serial:///dev/ttyACM0:921600.
There is one catch though, right now it doesn't send mavlink by default and so the connection doesn't start. You have to connect QGC first and then switch over to MAVSDK.
I'm planning to do a bugfix for this soon.
Wow… I am so glad I came across this open issue! I have been messing with this for several months now and I could not figure out why the UART connection from my companion computer would only work once I connected /dev/ttyUSB0 to QGroundControl first…and then switched back. The C UART example also has the same problem. Anyway, @julianoes is this related to the serial port settings, or something else? I was looking at the QGroundControl code to see how it’s done there… but they are using the QT serial port class. Anything I can help with? I would love to get this fixed…but I don’t know where to start…lol
For my setup, I am using a Cube and a Jetson connected via TELEM2 with a USB to serial cable. It works great after first connecting to QGroundControl. I am using Python code to connect to a manually running instance of mavsdk_server which is then connected to TELEM2 via /dev/ttyUSB0. It seems the system is more stable running mavsdk_server separately rather than connecting from Python directly to TELEM2. Not sure if this is just my setup or just they way the software works.
We should just send heartbeats by default on serial, that would fix this problem. Thanks for the reminder.
Hi @julianoes, interesting... I am somewhat new to all of this... I thought the heartbeats were things the autopilot sends out. So is this something that I can fix on my end by just opening the port and sending in a heartbeat? Or is this something that needs to get added to the A/P firmware so that it sends out a heartbeat on the TELEM2 port?
So a heartbeat is just a way to signal that a mavlink connection still works. Usually every MAVLink node sends it, so it's both ways. However, in the case of MAVSDK when used as a ground station, it doesn't send a heartbeat until it has received one. This behaviour makes most sense when MAVSDK is just waiting for packets arriving on the UDP port 14550 or 14540, so in this case it doesn't know where messages will come from, so wouldn't know where to send them to. It could broadcast in the network but that might lead to other problems. So, anyway, discovery is just not specced properly for MAVLink.
So then for serial, we have the same behaviour, where it doesn't send heartbeats until it receives some. However, PX4 then changed the implementation on the USB port to enable either the nsh console or MAVLink. It starts nsh when you hit enter, and starts mavlink when it receives a heartbeat. And this change makes it incompatible with MAVSDK for this case as now both are waiting for MAVLink, and neither starts until the other one does. I could just say that PX4 has changed its API (which it has) and that it's a PX4 problem but then again the PX4 release is already out and there is not much I can do then just work around it in MAVSDK.
Or is this something that needs to get added to the A/P firmware so that it sends out a heartbeat on the TELEM2 port?
On Telem2 that should not be a problem. It doesn't have the auto-detect magic like on USB.
So that is the interesting thing... it's not working on Telem2 until after connecting QGC. So I have the drone up and running... it has position fix and is ready to ARM. I plug my Jetson into the Telem2 port using the USB-to-Serial adapter cable. I can then run the c_uart_example code (https://github.com/mavlink/c_uart_interface_example) and it will open the port, print the system id and component id info and then it just sits there. If terminate the example, connect the USB-to-Serial cable to another linux machine and then run QGC, QGC connects to the drone over Telem2. I then unplug the USB-to-Serial cable from the QGC computer and plug it back into the Jetson. I then run the c_uart_example code again... and it then works as expected, printing position information and other mavlink messages.
I am probably not understanding this completely... but my question then is how do I modify the c_uart_example code to make it work without needing the connection first to QGC? I have set Telem2 up on the Cube to be a serial port and using Mavlink2 protocol, but it appears to still need a heartbeat of some kind to work.
So again, pardon my inexperience here... but would simply sending the same heartbeat message that QCG sends to Telem2... but from inside the c_uart_example do the same thing... and make it work?
If that is true, I could not find an example code block that shows how to send this heartbeat message.
Oh.. adding to this... what I am really trying to do is that I run mavsdk_server on the Jetson, connected to the Cube autopilot using the USB-to-serial cable. The real problem is that when I connect the cable to Telem2 and then fire up mavsdk_server, it does nothing... i.e. it picks up some components, but it does not get any heartbeat or position information from the Cube. If I do the QGC connection thing first and then relaunch mavsdk_server... everything works as it should... but it needs the QGC connection first. What I want to do is add something to my python code (that talks to mavsdk_server) that will get the Telem2 port active without needing the QGC connection to start it up. Does this make sense? Is there something I am doing wrong or should be doing differently?
So for example, from my Jetson python code, should I send some kind of GCS, path planner, or companion computer heartbeat to the Cube to get it to start dumping position messages out Telem2 via MAVLINK2 protocol?
When I run the c_uart_example code (without first connecting QGC), I get the following output:
OPEN PORT
Connected to /dev/ttyUSB0 with 57600 baud, 8 data bits, no parity, 1 stop bit (8N1)
START READ THREAD
CHECK FOR MESSAGES
Found
GOT VEHICLE SYSTEM ID: 1
GOT AUTOPILOT COMPONENT ID: 1
and it stops there... notice that there is no line that says
Found
but, if I connect Telem2 to QGC then disconnect it and reconnect it to the Jetson and then run the example again, it prints out the "found" message for the heartbeat and then proceeds to print the following as expected.
OPEN PORT
Connected to /dev/ttyUSB0 with 57600 baud, 8 data bits, no parity, 1 stop bit (8N1)
START READ THREAD
CHECK FOR HEARTBEAT
Found
GOT VEHICLE SYSTEM ID: 1
GOT AUTOPILOT COMPONENT ID: 1
INITIAL POSITION XYZ = [ 2.0328 , 3.2463 , -40.1498 ] │
INITIAL POSITION YAW = -2.5242 │
│
START WRITE THREAD │
│
ENABLE OFFBOARD MODE │
│
SEND OFFBOARD COMMANDS │
POSITION SETPOINT XYZ = [ 2.0328 , 3.2463 , -42.1498 ] │
0 CURRENT POSITION XYZ = [ 2.0374 , 3.2399 , -40.1562 ] │
1 CURRENT POSITION XYZ = [ 2.0145 , 3.2396 , -40.1657 ] │
...
Well, I don't understand that :thinking:.
@cryptik what PX4 or ArduPilot version are you running?
Hi @julianoes, I thought it was strange too as most I have talked to seem to think it should just start talking mavlink... no matter what I do, it only starts working after first connecting QGC to the port. I can then plug the cable into anything and it will just work... until the Cube is rebooted.
Before switching to running mavsdk_server as a separate manual process, I had the same problem with connecting to the port using the embedded version of the server. This also happened (using the same cable) and a Raspberry Pi... before upgrading to the Jetson. So it would seem the issue is probably either in the ArduCopter firmware or perhaps the Cube A/P. We are using the standard ADSB carrier board (which is where the Telem1 and Telem2 ports are).
The firmware version is ArduCopter 4.2.1. I think 4.3 is out, be we have not upgraded to it yet as the upgrade process is a bit of a pain and I don't think our drone manufacture supports it yet. TELEM2 is configured for MAVLink2 at 57600 baud. I have attached screen shots. Any advice would be most helpful.
Oh, ArduCopter! Well, MAVSDK support is not complete for ArduCopter, and I have very little experience with it. That explains why I don't understand it. I'm afraid I don't have time to further look into this in the next few days as I'm busy with client work.
I'm planning to do a bugfix for this soon.
@julianoes any update on this issue?
@valeriyvan, Adding my 2-cents here... the same as far as I can tell. Ardu appears to be waiting for some query on the GCS side before responding to a TELEM port request. In my case, I have a companion computer USB port connected to the TELEM2 via a USB-to-serial cable. Connecting QGC to the port first and switching it to the companion computer solves the problem. When running the same setup, cable, and port configuration, using a Pixhawk 6C with PX4 firmware, the problem does not occur. Once the port is active, it continues to work just fine until the autopilot is power-cycled.
I have posted this issue on the Ardu forums and I think the suggestion was to try and send a message-type request or rate limit request to see if that wakes up the port. Obviously, QGC does send something to the port to get it to start working... I just have not had the time to try the above suggestion or look through the QGC code.
Is this the issue where you have to send heartbeats first in order for PX4 to respond? Which usually could be done by connecting with QGC first. If that's what we're talking about then that has been fixed in the meantime.
Yea, I think it’s the same thing. Just about three weeks ago I loaded PX4 firmware on a pixhawk6c and I was able to connect to TELEM2 via MavSDKServer without the help of QGC, so it must be working on PX4. It is still broken on ArduPilot.
What’s interesting is that I use the same mavsdkserver for both PX4 and Ardu firmware, so it must be something else wrong with ArduPilot and the TELEM port since I still need QGC to make it work.