Adding MAVLINK_DATA_STREAM bricks px4 on boot-up

Hey there,
Im working on adding a custom data stream to be displayed over mavlink. I added the definition of the stream to common.xml and the message definition to ardupilotmega.xml. I also added cases to the functions “handle_request_data_streams” and “try_send_message”. Added to const AP_Param::GroupInfo GCS_MAVLINK::var_info[]. I don’t quite get why this leads to a lock up and freezes px4 during boot.

Anybody have an idea, what went wrong?

Tried running your code in SITL?

Also, consider running my message-intervals branch instead. It should be
a lot less work.

Hi!
Thank you for taking on my question. I’m pretty new to git, c++ and ardupilot, which is making everything a little cumbersome.

I don’t know what SITL is yet, and neither did I know that there exists a concurrent mavlink branch for arduplane, but I will try to find out and give it a shot!

I probably will report back at the latest at the end of the day!

Setting up SITL didn’t work for me… I got stuck, when sim_vehicle.py wanted an installation of JSBsim and cygwin did not want to run the autgen.sh. Today I will try it with Vagrant.

So vagrant does not work either… The VM-image that you’re supposed to load does not exist anymore… At least I could not find it and neither could the vagrant.

I tried loading another vm, “geerlingguy/ubuntu1604”, but that did not work either. The vm got stuck somewhere in the middle of initvagrant.sh.

I have to say, I’m pretty frustrated by now, because nothing seems to work.

@peterbarker : Where can I find your message-interval branch?

So vagrant does not work either… The VM-image that you’re supposed to load
does not exist anymore… At least I could not find it and neither could the
vagrant.

There are several different Vagrant virtual machines present in the
Vagrantfile. If you are working on master it should be trying to install
artful32 - and the images really, really should exist for that. Which
image did it fail to get?

Which branch are you currently working on?

I have to say, I’m pretty frustrated by now, because nothing seems to work.

If you come onto gitter or mumble I can help you out in a more interactive
fashion.

@peterbarker : Where can I find your message-interval branch?

I’m working on ArduPlane-3.8.5 release and the vagrantfile was ubuntu/yaketty32.

I resorted to splitting the changes I made into two groups: Group one: Adding a stream; Group two: Adding a message. I commented everything out, that concerns the stream and tried to fire my message together with RAW_IMU… The px4 is up and running again. But it doesnt’t send my message. :joy:

I tried artful32 and it even made it through the setup! But now it seems I’m out of luck again, because, if I’m not totally mistaken, the VM can’t access the tools required from ardupilot:

permission_denied

I’m working on ArduPlane-3.8.5 release and the vagrantfile was
ubuntu/yaketty32.

Ah, now that makes sense. I think this shows that we need to update the
Vagrantfile in the stable releases. I’ll discuss this with people. The
Vagrantfile in more modern branches specifies a vast range of different
machines - including the LTS machines so this sort of thing is less likely
to occur.

In the meantime - you could rebase on the new Plane stable release, 3.9 -
that will have you flying the best code and get you an up-to-date
Vagrantfile.

If you would like help rebasing, let me know.

I resorted to splitting the changes I made into two groups: Group one:
Adding a stream; Group two: Adding a message. I commented everything out,
that concerns the stream and tried to fire my message together with RAW_IMU…
The px4 is up and running again. But it doesnt’t send my message. :joy:

Poke in a “gcs().send(MAV_SEVERITY_INFO, …)” on either side of your
message-send - and then check the tlog. One common gotcha is having the
mavlink client not understanding the mavlink message you are sending -
that will typically just be discarded.

A bit more output will be required to help out with this one.

So, what you are saying is, that albeit the protocoll for communication using xml formats, the messages don’t contain information about their own nature, apart from their ID? And that a prerequisite for using newly defined messages is to make them known to the groundstation? (If that is the case, I wonder if you would know where to edit, because I didnt’t find a matching .xml or .cpp in the code of qgroundccontroll)

Does that mean, just changing some message definitions on the client side and recompiling the whole GCS-Code, or is there more to it?

I will migrate to 3.9 in any case. Seems the most sensible to me.

I really appreciate your help.

Update:

I was finally able to set up the SITL and also inserted my custom message into the code. It did compile and everything. All this took quite some time, but I’m positively thrilled that I can start working now.

Currently I’m looking into that “making the GCS know about the new message” thing… Don’t know yet, how I’ll do it. Feel free to tell me, if you have an idea!

Thanks!

So, I did what you told me to und used gcs().send_text… which will prove to be very usefull. It does get send before and after the mavlink_msg_###_send(), only my custom message is not being displayed. From what I get, I have to implement the message on the gcs side aswell… I will look into that now, but help is as always appreciated. (using qgroundcontrol)

So the critical thing is that the GCS know about the message.

In SITL, for example, MAVProxy needs to know about your new message type.
The way I typically accomplish this is to reinstall pymavlink (which
MAVProxy is based on):

pbarker@bluebottle:~/rc/pymavlink(master)$
MDEF=$HOME/rc/ardupilot/modules/mavlink/message_definitions python
setup.py build install --user --force
running build
running build_py
Using message definitions from
/home/pbarker/rc/ardupilot/modules/mavlink/message_definitions
Building
/home/pbarker/rc/ardupilot/modules/mavlink/message_definitions/v1.0/ualberta.xml
for protocol 1.0
.
.

After that, your tlog should contain your new message.

I just don’t get it. In my ArduPlane code I set

void GCS_MAVLINK::send_raw_ang1()
{
gcs().send_text(MAV_SEVERITY_INFO, “raw_ang_message_debug1”);
uint16_t x=1,y=2,z=3;
mavlink_msg_raw_ang1_send(
chan,
AP_HAL::micros(),
x,
y,
z);
gcs().send_text(MAV_SEVERITY_INFO,“raw_ang_message_debug2”);
}

but in the tlog of the SITL, there is no message in between the debug messages.

How can that be? Is there a nother layer between the SITL and the GCS, that filters out wrong messages? Or is there something wrong with the way I’m using the send-function(Plane 3.9)? Does it mean, the message is omitted or is it never sent?

So, I just did some testing, analyzed the tlog of the SITL and realized that my message is not even sent. I don’ really understand why…

As before mentioned I called the mavlink_msg_*_send correctly and don’t get any compiler errors…

If your GCS doesn’t understand the message it may not appear in the tlog.
Are you sure the GCS is aware if your message?

You could verify if the message is sent or not with something like
tcpdump.

Hey there,

I found out, that I missed a step in dev-guide: adding mavlink message at #6, which detailes exactly what you told me a few posts earlier. Sadly, it doesn’t do the trick. I verified that my new message now is contained in ardupilotmega.py. But it still does not show up in the tlog.

I also listened on all devices with WinDump, which is tpcdump for Windows. Sadly, the dumps were unconclusive.

Any guesses?

EDIT: The tlogs are generated directly by SITL. I don’t even start qgroundcontrol. So the message is definitively not sent.

My guess is something related to step 6 - MAVProxy not understanding the
message. Make sure pymavlink is installed from source, and that you are
using that. You need to repeatedly run pip uninstall pymavlink and the
like until it indicates it’s not installed, that sort of thing.

Last resort; I also did not implement a module. Step 6# says to do so, but I cannot find the directory where the modules are supposed to be located.

Do you think, not having a module would prevent the message from beeing added to the tlog?