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

Neville Rodrigues liked Neville Rodrigues's profile
Jun 30
Santiago Perez liked Santiago Perez's profile
Jun 21
More…