Fixing a known bug

By mistake I posted this on aerial photography 
Recently I've used a flight plan with the last command DO_JUMP as below
0 1 0 16 0 0 0 0 21.062668 105.797707 2.000000 1
1 0 3 16 0.000000 0.000000 0.000000 0.000000 21.063231 105.797684 30.000000 1
2 0 3 16 0.000000 0.000000 0.000000 0.000000 21.063271 105.800064 30.000000 1
3 0 3 16 0.000000 0.000000 0.000000 0.000000 21.061043 105.800209 30.000000 1
4 0 3 16 0.000000 0.000000 0.000000 0.000000 21.061003 105.797760 30.000000 1
5 0 3 177 1.000000 2.000000 0.000000 0.000000 0.000000 0.000000 0.000000 1
However do_jump was ignored and I was told on the forum that this is an known bug.
http://diydrones.com/forum/topics/do-jump-has-no-effect-at-all
After adding a dummy waypoint after DO_JUMP, the problem solved.
Looking at the code I see that after reaching the last waypoint in the flight plan, the program calls process_next_command() in command_process.pde. This searches for the next nav command first but of no avail because of the last waypoint, so the condition in the if command is true
    if(nav_command_index > g.command_total) {
            // we are out of commands!
            gcs_send_text_P(SEVERITY_LOW,PSTR("out of commands!"));
            handle_no_commands();
        }
In this case handle_no_command() is executed, which then flies home and loiters, ignores the rest of the flight plan.


Due to personal reason, I can't code and test in practice, my idea to fix this bug is as follow:
Changes in the code of process_next_command() are only in if(nav_command_index > g.command_total) {...} else {...} command
if(nav_command_index > g.command_total) {
            // we are out of commands!
            gcs_send_text_P(SEVERITY_LOW,PSTR("out of commands!"));
            if (next_nav_command == home) handle_no_commands()    //  already met the last nav command once
            else next_nav_command = home;
} else next_nav_command = temp;
nav_command_ID = next_nav_command.id;
non_nav_command_index = NO_COMMAND;                                 // This will cause the next intervening non-nav command (if any) to be loaded
non_nav_command_ID = NO_COMMAND;

if (g.log_bitmask & MASK_LOG_CMD) {
   Log_Write_Cmd(g.command_index, &next_nav_command);
}
handle_process_nav_cmd();


Can anyone code and test in practice?

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –

Replies

  • I think carefully again on the issue and come to a conclusion that the modified code would work but not because of changes in if command's handle_no_command() branch but instead due to changes in else branch. So the branch handle_no_command() can be leaved unchanged. The change will come in else branch as follow:

    if(nav_command_index > g.command_total) {    // leaving unchanged
                // we are out of commands!
                gcs_send_text_P(SEVERITY_LOW,PSTR("out of commands!"));
                handle_no_commands();
    } else
    { next_nav_command = temp;
      nav_command_ID = next_nav_command.id;
      if (g.log_bitmask & MASK_LOG_CMD) {
       Log_Write_Cmd(g.command_index, &next_nav_command);
      }
      handle_process_nav_cmd();
    }
    non_nav_command_index = NO_COMMAND;  // This will cause the next intervening non-nav command (if any) to be loaded
    non_nav_command_ID = NO_COMMAND;

    As commented above, so these value setting commands should be executed always independently from that whether the next nav command was found.

    Any comment is welcome.

This reply was deleted.

Activity