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?
https://github.com/peterbarker/ardupilot/tree/message-intervals
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. 
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:
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.
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?
I erazed the pymavlink-directory in SITL, downloaded it anew. Then I uninstalled again using pip untill cmd did output, that pymavlink was no longer installed.
I then reinstalled with the command you specified before “python … --user --force”. I verified that the new ardupilotmega.py does contain my new message. But still it does not appear in the mav.tlog…
Try introducing a flaw in that generated file (make a backup first). Do
you get an error when trying to run MAVProxy then?
If you’re willing to push this up to github I can have a look for you.
When installing pymavlink from the source - how are you invoking it? This
is how I typically do it:
MDEF=$HOME/rc/ardupilot/modules/mavlink/message_definitions python
setup.py build install --user --force
I migrated to Ubuntu 18.04. Now everything works like a charm.