Also, if you have a joystick that you can hook up to mission planner, that works fairly well. It is just like flying a real aircraft off of instruments. Plus it allows you to make the yaw inputs you want
Just a suggestion, it would be great if ardupilot code could utilize more sophisticated error handling, such as (there are many different ways different companies do this): Modern C++: Error Handling with Result - Yegor Pomortsev
basically a template that wraps an optional result and optional error details.
that way, the error could be more informative instead of just “init failed”, and come directly from the source of the error.
However, as these would certainly be a little more heavyweight than a simple boolean flag, i dont know if embedded constraints would preclude this. might not, i just dont have context on the standard requirements for ardupilot.
apparently realflight actually wont start if you dont have a controller connected, which i found odd. so i whipped out an old joystick. doesnt seem to work well with drones (i might just have to fix configuration), but ive read that you can connect the TX16S to control a drone, which would be ideal for me. havent tried it yet though.
You are talking to the wrong guy. My C++ programming skills are only slightly better than Leonard’s. I only know that because I’ve helped him once on something we were working on. And that was no where close to error handling. The people you want to talk to about that are @peterbarker and @tridge. And maybe @rmackay9. Probably want to post this in the main arducopter section.
ok… following this Using SITL with RealFlight — Dev documentation
and i have the copter loaded in realflight and i am connected in mission planner.
I can read waypoints (currently none loaded), but i cant write them. always get a “mission upload timeout”. seems to hang on “set total wps” and then times out. I have a simple mission with just 2 commands: Take Off and Land.
i can also arm. but while mission planner says the quad is armed, i dont see movement of props in realflight.
Mission Planner logs:
INFO MissionPlanner.MAVLinkInterface - 4/11/2023 4:49:01 PM 6 Initialising ArduPilot
INFO MissionPlanner.Controls.ProgressReporterDialogue - RunBackgroundOperation
INFO MissionPlanner.Controls.ProgressReporterDialogue - Focus ctl
INFO MissionPlanner.Controls.ProgressReporterDialogue - in focus invoke
INFO MissionPlanner.Controls.ProgressReporterDialogue - DoWork
INFO MissionPlanner.GCSViews.FlightPlanner - wps values 0
INFO MissionPlanner.GCSViews.FlightPlanner - cmd rows 3
INFO MissionPlanner.MAVLinkInterface - set giveComport current False new True
INFO MissionPlanner.MAVLinkInterface - setWPTotal req MISSION_COUNT {"count":3,"target_system":1,"target_component":1,"mission_type":0}
bps 102 loss 0 left 0 mem 422.0947265625 mav2 True sign False mav1 0 mav2 4 signed 0
INFO MissionPlanner.MAVLinkInterface - setWPTotal Retry 3
bps 42 loss 0 left 0 mem 424.0537109375 mav2 True sign False mav1 0 mav2 2 signed 0
INFO MissionPlanner.MAVLinkInterface - setWPTotal Retry 2
bps 42 loss 0 left 0 mem 420.1865234375 mav2 True sign False mav1 0 mav2 2 signed 0
INFO MissionPlanner.MAVLinkInterface - setWPTotal Retry 1
bps 42 loss 0 left 0 mem 422.115234375 mav2 True sign False mav1 0 mav2 2 signed 0
INFO MissionPlanner.MAVLinkInterface - set giveComport current True new False
ERROR MissionPlanner.ArduPilot.mav_mission - System.TimeoutException: Timeout on read - setWPTotal
at MissionPlanner.MAVLinkInterface.<setWPTotalAsync>d__224.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at MissionPlanner.ArduPilot.mav_mission.<upload>d__2.MoveNext() in C:\Users\mich1\Desktop\CubePilot\MissionPlanner\ExtLibs\ArduPilot\mav_mission.cs:line 91
ERROR MissionPlanner.GCSViews.FlightPlanner - System.TimeoutException: Timeout on read - setWPTotal
at MissionPlanner.MAVLinkInterface.<setWPTotalAsync>d__224.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at MissionPlanner.ArduPilot.mav_mission.<upload>d__2.MoveNext() in C:\Users\mich1\Desktop\CubePilot\MissionPlanner\ExtLibs\ArduPilot\mav_mission.cs:line 157
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.ConfiguredTaskAwaitable.ConfiguredTaskAwaiter.GetResult()
at MissionPlanner.GCSViews.FlightPlanner.<>c__DisplayClass209_1.<<saveWPs>b__2>d.MoveNext() in C:\Users\mich1\Desktop\CubePilot\MissionPlanner\GCSViews\FlightPlanner.cs:line 5885
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.GetResult()
at MissionPlanner.GCSViews.FlightPlanner.saveWPs(IProgressReporterDialogue sender) in C:\Users\mich1\Desktop\CubePilot\MissionPlanner\GCSViews\FlightPlanner.cs:line 5883
bps 42 loss 0 left 0 mem 424.0283203125 mav2 True sign False mav1 0 mav2 2 signed 0
INFO MissionPlanner.MAVLinkInterface - 4/11/2023 4:49:06 PM 6 Initialising ArduPilot
bps 77 loss 0 left 0 mem 420.19921875 mav2 True sign False mav1 0 mav2 3 signed 0
bps 42 loss 0 left 0 mem 422.0888671875 mav2 True sign False mav1 0 mav2 2 signed 0
bps 42 loss 0 left 0 mem 423.9619140625 mav2 True sign False mav1 0 mav2 2 signed 0
bps 42 loss 0 left 0 mem 419.962890625 mav2 True sign False mav1 0 mav2 2 signed 0
bps 42 loss 0 left 0 mem 421.7265625 mav2 True sign False mav1 0 mav2 2 signed 0
INFO MissionPlanner.MAVLinkInterface - 4/11/2023 4:49:11 PM 6 Initialising ArduPilot
bps 102 loss 0 left 0 mem 423.7412109375 mav2 True sign False mav1 0 mav2 4 signed 0
INFO MissionPlanner.MAVLinkInterface - 4/11/2023 4:49:12 PM 4 Mission upload timeout
INFO MissionPlanner.CurrentState - messageHigh Mission upload timeout
MISSION_ACK MAV_MISSION_OPERATION_CANCELLED {"target_system":255,"target_component":190,"type":15,"mission_type":0}
bps 92 loss 0 left 0 mem 419.7275390625 mav2 True sign False mav1 0 mav2 4 signed 0
bps 42 loss 0 left 0 mem 421.6015625 mav2 True sign False mav1 0 mav2 2 signed 0
bps 42 loss 0 left 0 mem 423.4990234375 mav2 True sign False mav1 0 mav2 2 signed 0
bps 42 loss 0 left 0 mem 419.3115234375 mav2 True sign False mav1 0 mav2 2 signed 0
im just going to forgo realflight for now, and just use native sim. the altitude indicator is all i need to demonstrate the issue.
I am able to successfully run a demo mission that should trigger the target performance bug. how do i modify the weight (or perhaps thrust) of the SITL aircraft such that I can get a T/W < 2? I actually did no physics configuration of the SITL aircraft at all. ill still be going through the tutorial docs in the meantime to see if i can find the answers.
im actually only able to peak the yaw at 0.5 (normalized) using LOITER_TURNS. looks like i might also have to write a custom mode that sinusoidally changes yaw to get higher outputs. or continue messing with the yaw parameters to get max out. ideally, turn up the rotational inertia on the physical model, if i ever figure that out.
edit: nevermind, there is CONDITION_YAW !
Reduce MOT_SPIN_MAX to get the hover throttle you want.
Increase ATC_SLEW_YAW or PILOT_Y_RATE to get higher yaw rates depending on how you are commanding the yaw.
Increase ATC_RAT_YAW_P to get yaw saturation you want.
Some pointer for the simulation physics :
ardupilot/SIM_Multicopter.cpp at master · ArduPilot/ardupilot · GitHub for simple model
otherwise Callisto model is more advanced :
ardupilot/Callisto.json at master · ArduPilot/ardupilot · GitHub
For testing don’t forget the logs ! Visualization means nothing, specially on simulation …
For the codebase, if you read correctly our codebase and wiki guide, we have a real C++ codebase due to historical reason. So yes it could looks weird for C++ developpers. But most of the case there is nothing worring from safety or performance point of view. The things you mentionned are more code style than anything else, so we generally don’t care. But contributions are welcome to raise the codebase level if we can deploy the contribution and make everything to continue to follow the new rules
thanks for the code links, i now know how to modify mass and rotational inertia. ill start with just a test branch that hard-codes modifications. later, if everyone wants an “underpowered” (T/W < 2) frame type, we can add this with its own name.
well, I think magic numbers may have had a part to play in concealing this bug for so long (if this is actually confirmed to be a real bug in SITL tests). one reason to maintain a certain level of style is to maximize readability and understanding so that some bugs can be identified and prevented more easily. fixing magic numbers, in my view, is low-effort, but high-gain in terms of developer experience. but in general, i agree with you, style is not usually critical, but it can sometimes help prevent major bugs. if its low-effort, i see no reason not to adhere. if its high-effort, it could be counterproductive.
1 Like
looks like the default max thrust-to-weight ratio in sim is 2.56 by summing up static motor thrusts at voltage_scale = 1 and default altitude of 593m AMSL. Going by default Model::hoverThrOut (0.39) it would be approx 2.56 (consistent).
ok guys. what is the first rule of flight club? never unwillingly drop like a rock.
this essential rule that i just made up is violated by arducopter when 2 conditions are simultaneously met:
- thrust-to-weight ratio (T/W) < 2
- attitude output is maxed out (roll, pitch, yaw, or some combination of the 3)
I reproduced the problem and solution in sim (after having experienced this in real life some time ago). the sim copter has a T/W of 1.8 and performs a mission containing an aggressive sinusoidal yawing motion that maxes out yaw output.
without my fix, here is the drop in altitude reproduced in sim:
you can see that despite the short duration of maxing out yaw, the copter quickly loses altitude.
here is the same mission with my fix:
notice no drop in altitude, which i believe is consistent with arducopter’s general prioritization of altitude / throttle. i believe this is the preferred behavior (correct me if im wrong).
before i submit a PR, are there any other testing requests?
here is a human-readable form of the mission:
2 Likes
Nice !
I’m not a dev in this project so cannot evaluate your PR, but thanks for your time and contribution.
What we see in the graphs are motors outputs and altitude.
. Is it possible to trace also attitude edit - and yaw ?
. Is it possible to try a triangular “sawtooth” signal for the yaw ?
. Or even a square one ?
It seems that the amount of motor correction in the second example is less than in the first (which is consistent with the aim of maintaining altitude).
How did the yaw follow the order ?
Was there any significant drift, and if so was it caught up over time ?
1 Like
Sadly I saw my share of flying machines turning into rocks 
1 Like
You are the expert here. I am sure if you are happy then we will all be happy. Share the PR so we can all learn from your insight. Maybe after we see the code there might be one or two things we could suggest you test, just to subdue the doubters…
1 Like
No PR, no code? I am worried you have found MAJOR problems with your approach or something…
That sales and marketing professional has done a wonderful job selling the dream, now someone needs to tell the “professional programmer” they need to deliver on these promises.
1 Like
sure, i can get another graph sometime today.
sorry i misused the term “sinusoidal”. i really just meant oscillatory, not an exact sine wave. the mission plan implements desired yaw as a square wave.
yes, this fix simply prevents the controller from digging into the altitude budget. this means the yaw output will be reduced.
not sure what you mean by this, can you explain?
this might be able to see when i provide the yaw plots later today.
hopefully this fix will reduce the frequency of such experiences by arducopter users the world over 
nope, i have not found any major problems. i havent done anything since my last post, except reading more of the code to see if i can improve my impl. so, to produce the test results in my last post, i hard-coded the (increased) throttle limit into the flight controller. once we got the SITL test data verifying the problem and validating the solution, i originally planned to allow users to set it. but i see 3 approaches of implementing this fix:
- Make a new user-configurable param for the throttle limit. default will not change anything from current impl. the user will change this param based on the T/W of their craft. this is the least invasive impl.
- Hard-code a new much-higher limit, based on other assumptions made in other AttitudeControl impl (ill dig it up and update here). this one would require more testing, unless there is consensus among devs. edit: actually, scrap this idea. i think one goal for the hard-coded limit was to allow the controller to sacrifice climb rate for attitude control. a much higher limit would not allow sacrificing climb rate.
- Dynamically determine the new throttle limit. This might be in your purview. I am actually not sure why the current impl is the way it is, relying on hard-coded limits. Perhaps there were reliability issues? (edit: I think one reason for the current impl is that it allows the controller to sacrifice climb rate for attitude) this maybe you can think about more if i decide to submit a pr based on 1 of the 2 approaches above, if you dont have any comments on this now.
so ill make a decision today and hopefully have the pr ready for review by today. there’s a fair chance the impl might be changed completely. but as i alluded earlier, the impl for this fix is very small, so its easily changed.
i thought the SITL tests put us on the same page. is there anything that doesnt make sense to you? at least we agree this solves a major problem right?
edit: after some thought i think i will go with the original approach: a new user-configurable param.
edit 2: actually, something even simpler… set the limit to the (readily available) hover throttle…
I won’t be able to evaluate this until I see the PR. This problem is obvious and easy to fix. It was a design decision. I am interested in seeing how you have fixed the problem without introducing the other problems I was avoiding…
I am happy to hear the PR is imminent!