QGC + Pixfalcon: disarm command delay

1

Hi!
Describe my problem in steps.
I was developing some QGC features for my own needs upon v.3.1.2 with Qt5.5.1 in Ubuntu. Once I noticed strange behavior during start: I arm copter (with PixFalcon px4 v.1.6.1 and Intel Joule running mavros), then press disarm (from gamepad or gui - doesn’t metter) - and copter doesn’t stop props. It answers with disarm only after some time, pretty big.
Hmm, I thought, let try it on unchanged QGC build downloaded in binaries. And it worked well!
After time trying to fix my code (of course I thought the reason is my code) I decided to load latest repo, built it with Qt 5.7.1 and started checking and… it worked well anytime from binary load QGC and carried on not to reply on disarm with my build. Furthermore I noticed that problem is unstable - sometimes it appeared, sometimes anything went Ok.
…I keeped on trying dig into code. And noticed finally that when copter doesn’t reply disarm, QGC puts console message with following text thrown from MavLinkLogManager.cc:

MAVLinkLogManagerLog: Start MAVLink log command failed

So the reason is most probably in that QGC waits for MAV command reply 3 times 3000 ms each, and then posts message and only then disarm works.

But this exploration didn’t make something more clear for me. Questions are:

  1. Why the problem denotes itself with my builded QGC whereas with binaries from http://qgroundcontrol.com/ anything works well? How?..
  2. In case of message above appears - does it mean the problem is onboard? Or still in QGC code.

I looked through px4 Firmware fluently and saw such strings:
mavlink_receiver.cpp, in handle_message_command_long(mavlink_message_t *msg):

if (cmd_mavlink.command == MAV_CMD_LOGGING_START) {
            // we already instanciate the streaming object, because at this point we know on which
            // mavlink channel streaming was requested. But in fact it's possible that the logger is
            // not even running. The main mavlink thread takes care of this by waiting for an ack
            // from the logger.
            _mavlink->try_start_ulog_streaming(msg->sysid, msg->compid);
}

mavlink_main.h:

 void try_start_ulog_streaming(uint8_t target_system, uint8_t target_component)
    {
        if (_mavlink_ulog) { return; }

        _mavlink_ulog = MavlinkULog::try_start(_datarate, 0.7f, target_system, target_component);
    }

Does it mean that if ulog streaming is already active, we don’t receive answer from device on our MAV_CMD_LOGGING_START packet? And wait for 9 seconds not responding on disarm command.

Thank you for any suggestions!

2

Ok, maybe I have hack to my problem (and maybe it isn’t a problem at all, who knows).
If we decrease in QGC code _mavCommandAckTimeoutMSecs member (in Vehicle class), for example tenfold to 300 ms, system will detect MAV_RESULT_FAILED for MAV_CMD_LOGGING_START (or -STOP) faster (less than a second), and disarm will be active after that time - that’s Ok.
And maybe even that is what we have actually in QGC downloaded in binaries from site. If we do here arm-disarm without appropriate timeout between, logging onboard falls (it could be shown trying get logs from “Log Download” menu and getting permanent “pending” status for last shown log). The difference with my build might be then timeouts and putting message “… log command failed” in console or not.
The most valuable conclusion I got from this experience is maybe not to twitch like a monkey arm/disarm sticks shortly ))