Andrew Tridgell is obviously the main player on this subject (for the APM side) and it’s good to see he is porting to “Linux Embedded”. But as a Linux guy presenting Linux solutions, I fear other systems are only going to be an afterthought. He does give a few words to Windows and iOS in that video (thanks @mfm) so we’ll have to see where that goes. Another positive point, when he talked about compiling on the drone, there’s a hint at some kind of standard language layer or set link libraries, so maybe an APM framework is in the works anyway.
@mikhailavkhimenia The HAL belongs to the OS and device core (including Pixhawk, clones and variants like Navio), but is not the main player (just a internal participant) in an IoT architecture. We’re talking about a layer between the OS/device and useful functionality/behaviours.
Other operating systems are not excluded, in fact easier to implement with a proper service (not just hardware) layer. The Windows 10 IoT for Raspberry Pi 2 is just a great catalyst to motivate some action, and Emlid have the right device at the right time in my opinion to present a solution which stands-out. Open source drivers should ease the transition to other platforms, great!
I really hope the APM team and Andrew are open to changes which could totally refactor the system. I don’t agree with everything he says in this video, for example what he says about update speeds and “physical limitations” does not fit together with advances made in propeller rotation control (think monocopter) and user feedback from use of high speed ESCs (on other systems). The physics do not appear to be so limited, it’s just more complex to think about. I would prefer the platform not to dictate how we wish to use the hardware, just enable it.
The APM “firmware” needs to be split into 2 or more pieces. To start with the concept of the “main loop” needs to be addressed too. Sure there will be one internally, like there is still one in every Windows application. The current APM firmware design compared to what I envisage, is analogous to what we had in the days of DOS when Windows 3.x and OS/2 came along. When IBM and Microsoft introduced the “message pump” concept, windowed applications were born and development exploded.
The main loop should always be the same, messages documented, extensible, standardized (type system) so both forwards and backwards compatible. Sure it’s a challenge to implement a service bus on a real time system, but not too hard and when done properly it should be simpler and more efficient for the services and apps running on top of it.
APM could be the next “Windows” for drones, or a new system could emerge. It shouldn’t mater which OS/“platform” you choose, more that we have open protocols and service interfaces (including behaviours) defined and independently developed. Currently I only see the MAVLink protocol as a true standard, the rest is too volatile, baked deep into code.
I just received my Navio+ board today, very efficient dispatch, thanks Emlid! Time to start playing with it, see what it can do… 
I don’t have much spare time but whenever there is a demo I’ll post a link back here. Maybe I can help APM directly, that would make more sense. Regardless of where this is going Windows IoT drivers then APM_Windows_HAL should be produced as the first steps and proof of concept.
but man oh man Linux has frustrated me on many occasion. Perhaps I just don’t know what I am doing and need to stay away from Linux. LoL 
The hardest part will be getting the PID loop correct. I don’t have an environment with cables to stablize the drone, so I expect many crashes before I get that right.
