Problem with DO_JUMP in mission planner

Phill Simpson April 3, 2015 at 3:28pm

Soren,

I've been trying to figure out how the command processor works with nav and non-nav commands for some time and just found your post, great description! The description on the Wiki leaves some gaps in the area most important to me, the processing of non-nav commands in cases where there are very few nav commands. In my particular use case (360 degree aerial panoramas from a fixed point in the air), the nav waypoints are incidental and, for the most part, not needed by me. I just fly the 'copter to a point in the sky, then I want it to loiter while the mission commands the camera gimbal to point the camera at various angles and take pictures using a series of DO_SET_SERVO, CONDITION_YAW, and DO_DIGICAM_CONTROL commands.

I thought I'd write up a description and request that it be added to the Wiki but I'd like to verify a few things first, especially around what you described as "The special cases where there are no more blocks or when the navigation command of the next block completes before the last non-navigation command of the previous block are not so important here." These are exactly the issues that are the most important in my case.

Could you answer a couple questions for me?

What I am finding is that in the case where the "navigation command of the next block completes before the last non-navigation command of the previous block", it appears to me that the remaining non-navigation commands are skipped and not executed. The only way to get them executed is to introduce a delay in the navigation command of the "next block" that gives enough time for the non-navigation commands of the previous block to complete (e.g., a Waypoint command with zero Lat, Lon, and Alt and a few seconds of delay).

1. Is that what you found also?

I'm not sure what happens in the case where there are no more blocks since my last command is always an RTL which, according to your description, will terminate the mission and any non-nav commands not yet executed within the few milliseconds between the last nav command and the RTL will be skipped.

2. Is that correct?

Right now I'm using a series of Waypoint commands with zero Lat, Lon, and Alt and a few seconds of delay between each non-nav command to give the 'copter enough time to yaw, then to allow time for the camera gimbal pitch angle to change, and again for the shutter release time. Using Waypoints causes some other issues so I'm looking at substituting CONDITION_DELAY commands but it appears from the description that it won't delay execution of the next nav command so I'm back to needing either a Waypoint command with a delay between each non-nav command or at the end of the non-nav block with enough time for the entire block of non nav commands to execute.

3. Is that your understanding too?

Thanks,

Phill

Oekedoeleken April 17, 2013 at 11:58am

I downloaded the source code for arduplane 2.71

and browsed through commands_logic.pde

If we look at the tlog file, we see the following after WP5 is reached:

First the WP7 is executed (rtl) and then WP6 (do_jump) is executed.

CMD, 7, 5, 20, 1, 0, 0, 0, 0
MOD,RTL
CMD, 7, 6, 177, 1, 1, 0, 3, 0

This is normal according to the explication of soren!

however when I look at the source code in commands_logic.pde

when you execute the rtl-command in WP7, the APM LEAVES AUTO mode !!!!! :

////

case MAV_CMD_NAV_RETURN_TO_LAUNCH:
do_RTL();
break;

////

/////

static void do_RTL(void)
{
    control_mode    = RTL;   <------------------------------------------
    crash_timer     = 0;
    next_WP                 = home;
    loiter_direction = 1;

    // Altitude to hold over home
    // Set by configuration tool
    // -------------------------
    next_WP.alt = read_alt_to_hold();

    if (g.log_bitmask & MASK_LOG_MODE)
        Log_Write_Mode(control_mode);
}

///////

SO FOR THE MOMENT WE ARE IN RTL-MODE, NOT IN AUTO ANYMORE.

according to the tlog-file the next command which gets executed is:

CMD, 7, 6, 177, 1, 1, 0, 3, 0

which is my do_jump command

we are not in auto-mode anymore, but de do_jump is still executed:

//////

static void do_jump()
{
    if (next_nonnav_command.lat == 0) {
        // the jump counter has reached zero - ignore
        gcs_send_text_fmt(PSTR("Jumps left: 0 - skipping"));
        return;
    }
    if (next_nonnav_command.p1 >= g.command_total) {
        gcs_send_text_fmt(PSTR("Skipping invalid jump to %i"), next_nonnav_command.p1);
        return;
    }

    struct Location temp;
    temp = get_cmd_with_index(g.command_index);

////

this last part bothers me a little:

struct Location temp;
temp = get_cmd_with_index(g.command_index);

is the value g.command_index still valid when you are not in AUTO mode anymore?

I suppose the index will be reset to WP1 when the mission is finished, so the struct location temp will be set to the coordinates of WP1?

Should a DO-command still be executed when the plane already left auto-mode?

BUT:

It's the first time that I look at the arduplane code so it's possible that I'm completely wrong :-)

in that case you can just ignore my comment :-)

kind regards,

Davy

Moderator

Graham Dyer April 16, 2013 at 6:11am

Was full 3D GPS lock achieved before launch? Did it not perhaps only get a lock at WP1? Can you upload a tlog?

Søren Kuula April 16, 2013 at 4:44am

Hi,

Now I don't know the GMX or KML plots you have there... how do you know that the plane went into RTL, is that the blue color?

I have looked into the command process code and see some half dubious things, but so far nothing that could shift the home position just like that..

Can you post the mission file and telemetry and/or onboard logs?

Regards

Soren

Discussions

Problem with DO_JUMP in mission planner

Replies

Activity