Thank you! @Yuri_Rage for looking into this more - I think I can say with a high level of certainty that we ran into the bug you found when trying to fly these missions in real life. The students would not often arm their copters more than a minute in advance, to my recollection. From what I understand of how you are describing the bug, arming less than a minute before the UTC delay/takeoff command time would’ve caused the unwanted nearly 24 hr delay that we also saw. This is also great that you were able to reproduce it reliably - I will make sure in any further testing we arm more than a minute ahead of time, at least until the PR is taken care of.
1 Like
The bug is a very specific edge case where you have to use the “-1” ignore value in the minutes field but specify absolute hours.
It would also manifest with “-1” in the seconds field and absolute hours or minutes specified, but that would only cause the improper rollover during second 59, so an even narrower case.
If your missions did not use the ignore flag, there’s still something else to blame, and the logs would tell the whole story.
2 Likes
Ah, thank you. That makes sense, so we likely still had something else going on, as what you found does seem to be a bit narrow of a case for it to have happened with us. I’m learning/reinforcing more and more from this experience (and others) that if anything strange happens (even if not a crash) with a student’s aircraft, I need to have them get me a copy of the logs/missions/etc. as soon as it happens, right there after the flight! That would give me much better data to share for things like this. If I test fly myself and reproduce, I’ll definitely share logs here. Thanks again, @Yuri_Rage !
1 Like