I can only make the controls work by assuming the motors in the C++ drone are numbered like [[1,2],[3,4]], whereas the motors in the Lesson 4 - 3D Drone Full Notebook.ipyb are quite clearly numbered as [[1,2],[4,3]].
Once I make that assumption, my solution works like a charm, producing graphs for drone attitude control consistent with the README - and if I assume the numbering as in the notebook, nothing works.
Specifically, that impacts the GenerateMotorCommands function, where with the former numbering the last two lines look something like
cmd.desiredThrustsN[2] = (c_bar + p_bar - q_bar - r_bar) / 4.f;
cmd.desiredThrustsN[3] = (c_bar - p_bar - q_bar + r_bar) / 4.f;
(note the signs) and work fine, whereas in line 137 of solution.py used in the last lesson it says
omega_4 = (c_bar + p_bar - r_bar - q_bar)/4
If my understanding is correct and the numbering is indeed different, it's worth highlighting it very prominently in the README to save other people the hours of debugging I had to do to figure this out ;)
I can only make the controls work by assuming the motors in the C++ drone are numbered like [[1,2],[3,4]], whereas the motors in the Lesson 4 - 3D Drone Full Notebook.ipyb are quite clearly numbered as [[1,2],[4,3]].
Once I make that assumption, my solution works like a charm, producing graphs for drone attitude control consistent with the README - and if I assume the numbering as in the notebook, nothing works.
Specifically, that impacts the
GenerateMotorCommandsfunction, where with the former numbering the last two lines look something like(note the signs) and work fine, whereas in line 137 of solution.py used in the last lesson it says
omega_4 = (c_bar + p_bar - r_bar - q_bar)/4If my understanding is correct and the numbering is indeed different, it's worth highlighting it very prominently in the README to save other people the hours of debugging I had to do to figure this out ;)