4 ms·

I see, yes controlling at 2 Hz will not be easy no matter how you slice it. What's preventing you from doing more? At one point I experimented with mine. I thin

by auspiv 2y ago

I see, yes controlling at 2 Hz will not be easy no matter how you slice it. What's preventing you from doing more? At one point I experimented with mine. I think below 5 Hz things got choppy. Greater than 10 didn't do a whole lot. For reference, Arduplane (RC plane OS/autopilot/etc) uses 50 Hz for defaults - https://ardupilot.org/plane/docs/parameters.html#sched-loop-rate-scheduling-main-loop-rate https://ardupilot.org/plane/docs/parameters.html#sched-loop-..., and quite a bit higher for copter (at least 400 Hz). I'd be interested to know how your autopilot reacts with just the P & I portions. Everything I've read/learned about PID loops say to incorporate each term sequentially, meaning do P first, then introduce I to correct long term error, and finally introduce D to prevent overshoot. Not many use only P & D.

TheRealPomax 2y ago
> What's preventing you from doing more MSFS itself, mostly - it's pretty much always CPU bottlenecked already, and you can do fast polling using C++ (by basically allocating a piece of shared memory that MSFS keeps dumping updates into), but when you're using an FFI layer in Python, JS, etc. you end up transferring "fat" objects and running real time without bogging down an average specced machine gets tricky. The game itself will generally run well below 60fps, so realistically the fastest you're going to get updates is 20~30Hz (which should be enough) but then you might also have your AP code competing with MSFS itself if they decide to run on the same core. It would be cool to add a completely new chapter going "so we got all of this working pretty well: time to delete all our code and now redo it using control loops on an unused core" but that's one of those "if I ever have time again" things =P > Everything I've read/learned about PID loops say to incorporate each term sequentially Aye, but the problem is we don't have the luxury of tweaking the controller ourselves beforehand: the goal is an autopilot "that works for all planes", so the challenge would be to write a self-tuning PID solution that can do the job without any prior knowledge (because we're not profiling every plane in MSFS, that'd be a full time job). If we were writing an autopilot for our favourite, single plane, then tweaking the controller would be relatively easy, but the solution has to work for everything from a Top Rudder Solo 103 to a DC-3, which complicates things a little. I'm not in love with the current implementation in erms of having quite a bit of "emergency detection" that changes control parameters if the current values end up steering us into bad control territory, but at the rate we're getting updates, it's at least serviceable.

by auspiv 2y ago

TheRealPomax 2y ago

> What's preventing you from doing more MSFS itself, mostly - it's pretty much always CPU bottlenecked already, and you can do fast polling using C++ (by basically allocating a piece of shared memory that MSFS keeps dumping updates into), but when you're using an FFI layer in Python, JS, etc. you end up transferring "fat" objects and running real time without bogging down an average specced machine gets tricky. The game itself will generally run well below 60fps, so realistically the fastest you're going to get updates is 20~30Hz (which should be enough) but then you might also have your AP code competing with MSFS itself if they decide to run on the same core. It would be cool to add a completely new chapter going "so we got all of this working pretty well: time to delete all our code and now redo it using control loops on an unused core" but that's one of those "if I ever have time again" things =P > Everything I've read/learned about PID loops say to incorporate each term sequentially Aye, but the problem is we don't have the luxury of tweaking the controller ourselves beforehand: the goal is an autopilot "that works for all planes", so the challenge would be to write a self-tuning PID solution that can do the job without any prior knowledge (because we're not profiling every plane in MSFS, that'd be a full time job). If we were writing an autopilot for our favourite, single plane, then tweaking the controller would be relatively easy, but the solution has to work for everything from a Top Rudder Solo 103 to a DC-3, which complicates things a little. I'm not in love with the current implementation in erms of having quite a bit of "emergency detection" that changes control parameters if the current values end up steering us into bad control territory, but at the rate we're getting updates, it's at least serviceable.