Navio SDK for Windows IoT

So I just got the first April 29th Windows 10 IoT (Internet of Things) image running on my Raspberry Pi 2 and when looking at the samples it seems although there’s not much in the way of end user apps for the device there is a ton of robotic/electronics capabilities. Specifically in relation to potential NAVIO+ support, their samples already include multiple I2C and SPI samples, gyros, basically most of the main components needed to build a quadcopter.

So how about it? This is supposed to be some kind of realtime OS build too, the next-gen Windows Embedded basically. So NAVIO+ should run? They’ve got nice tutorials on writing drivers and it shouldn’t be too difficult (compared to Linux stuff) because you’ve got the Microsoft quality APIs (usually much simpler) and tools available.

Would be real cool to see Emlid get behind this. Maybe if you get in touch with Microsoft you could get a freebie and major PR exposure as the first Windows drone? It’s there for the taking guys and maybe Windows runs stable for drone usage. Worth a try?!?


Well, that may be interesting as a concept. But that would require a separate HAL for the APM and it’s not clear what does the end user get from it? I doubt that embedded Windows is more user friendly than Linux.
Interesting idea for a project, though:)

EDITED: Actually, it is very interesting what is the real time performance of the system. If you would be able to find some test for it like cyclictest for Linux, don’t forget to share the results:)

1 Like

Ok will have a look at cyclictest. I’d like to know how it compares too.

If a HAL-only “APM on Windows” Pixhawk (NAVIO+) clone is possible that is certainly an interesting first version, but it could be too difficult or slow to emulate all the Linux/NuttX stuff than it is worth. The whole NuttX system is end-of-life so long as APM follows the lead of 3DR; their released specification for Solo confirms they are now running some kind of full Linux build.

So my longer term plan (which I would also be happy if some other organization did) is to re-write something like the APM firmware native. Just the firmware! The rest of the APM stuff, the ground control and telemetry device compatibility can be maintained, thanks to the MAVLink protocol. This is a kind of service orientated solution then, and that’s where the whole IoT thing is going so it feels like correct architecture to adopt.

For this purpose we need an adapter which gives us access to all the standard RC equipment and on-board mandatory sensors (gyro, GPS, compass). That’s exactly the Emlid NAVIO+ board! This device is the perfect “bridge” in my opinion so I’m jumping on this opportunity now :slight_smile:

The bigger benefit of having a complete operating system and framework is the simplicity=speed at which people can expand upon it. Users can just download drivers, services and apps directly on top of a rock solid base (when designed/programmed correctly).

It’s a totally different development life-cycle:

  • APM development (firmware process) = 1) branch the (potentially unstable) development codebase, 2) hack-in your changes all over the place, 3) submit a pull request and wait ages before it is officially available, 4) the main developers at DIYDrones have to sort-out all the mess and have multiple discussions before the code is finally in place, then go through a long release process for every single service or app (on the drone), testing and release is more complex, everyone has to rebuild everything themselves.

  • Windows IoT development (framework process) = 1) do nothing, use the current release “framework/platform”, 2) code on top of the “stable” base, 3) install the software like an add-on, 4) Testing is much less effort, running new code less risk for users.

Working with a real “platform” compared to “firmware” is just better in every way It means your system extensions and apps are immediately available and usually backwards and forwards compatible (within acceptable limits). The developers can achieve finished reliable solutions faster because they have excellent guidance (fitting into the fully documented framework, in the right places put there for them to extend upon) and less stress/mistakes compared to one big mash of code with changes all over the place.

3DR are clearly going in this direction with DroneCode and the Solo, but I fear they will follow DJI with a locked-down system and $premium$ options if you want to do anything interesting. It all looks a bit “Apple” to me. With the solution I propose, just like any traditional OS, we can do pretty much anything we like at zero additional cost or bureaucracy.

There is no need to “emulate” Linux\NuttX stuff, that is what HAL for - to allow code run on different platforms. You are not emulating one of them in the HAL, you use an abstract one. APM is native on Linux. It’s not emulated.

Flight controller in solo is based on STM32 with NuttX. Separate processor with Linux is used for extra stuff.

And firmware\framework approach has nothing to do with Windows. It can be the same on Linux. No need to hack your changes in APM if you want to do something external - simply use MAVROS (or DroneAPI).

@CodeChief I think this talk by Andrew Tridgell on the APM to Linux port and the APM structure in general is a very good primer.


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… :slight_smile: 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.

Hi Tony,

Have you made any progress on this topic? win10 iot for navio+

Best regards,
Bert Helsen

Hi Bert,

Yes I’m right on this topic now… The problem was I got delayed getting the existing Linux builds working with custom drivers and some other stuff. I think it’s important to fully understand (and be able to develop with) the existing system before trying to make a clone. On the Windows side Microsoft are busy with IoT as there is already a new build released and every day more and more samples and information on hardware projects. They’ve already provided I2C and SPI samples so in theory most of the work is already done by Microsoft.

Regarding conversion there are two approaches. First get the same samples from Emlid (sensor/controller tests) working as a stand-alone Windows samples. That will deliver new (Windows 10) “Universal Drivers” or wrappers/configuration for existing drivers (I2C/SPI) so they “just work” with the Navio+. Then we fork into two directions.

First get APM running (probably with some help of Cygwin libraries for any Linux specific stuff which does not easily map to Windows APIs). Secondly, play with a totally new framework for autonomous control. I’d hope I can get something hovering within a short amount of time for fun, but will focus on APM conversion as you just cannot beat the amount of development there.

I’m looking at a couple of weeks to have some demonstrations, then before the Windows 10 release (July 29th) to have something “useful”. I think anything created must be shared/openly developed as APM itself, maybe even transferred to their repositories if they’re interested in a Windows IoT HAL.

As soon as there is enough source to be interesting I’ll share the GitHub link here so anyone can jump in and help as they wish.


Hi Tony,

Yes indeed we could try to port the code as is and try to emulate. or try to rewrite. Rewriting as a whole would take a massive amount of time. as far as I get right now is that ardupilot exists of python c++ arduino sketch. Which way would you have in mind for the iot (unmanaged c++/ managed c#)?

I’m a c# programmer so I’m not used to go unmanaged. But I’ve been told that if you would use .net (managed) c++/c# and the garbage collector passes by your drone wont be in the air anymore ;o). So my guess is that c++ unmanaged is our only option? I just found out thata there are c++ examples for iot will have a look at those to get started

Definite let me know if you have more info on this topic in the future

Best regards,
Bert Helsen

I’m thinking “drone enabling the OS” rather than trying to prescribe (or limit) what can be done right-up to the autopilot level. Same as how Emlid provide drivers and samples on Linux, and APM runs, but Navio+ is not just an APM device. Windows IoT will help underline that.

Basic stabilized flight with geofence is about the scope necessary to prove the concept. After that I think several branches will occur if people are interested, APM HAL, ROS, etc…

Like any other part of the OS, it would have a C++ API at the core and managed C++ to provide a neat .NET interface so more people can program and quicker.

For .NET applications there are plenty of techniques to deal with garbage collection and with a good object model it won’t be too busy anyway. You’re correct that it is an important design and test factor but it’s not true that .NET applications randomly hang or anything horrible like that, not unless it’s got serious code issues.

The core motor control/sync can be abstracted into a time critical process/dispatch loop or even a kernel level driver. Anything a user mode application wants to do will be second class. The proof of concept will no doubt require several flavours of components to see which method works best.


Good news… The first part of the SDK is complete! The PCA9685 LED & PWM chip is implemented, along with a sample application and hardware test GUI.

It was a lot of work, but now I feel like I’ve mastered the “method”, the other chips should be supported very soon! :sweat_smile:

Also good news is Emlid are behind this 100%, they’ve added it as a new repository on their official GitHub page:

Okay so of course we need proper documentation for this, which will follow. But for now here is a quick start:

  1. Follow instructions on to get a basic Raspberry Pi 2 installed with Windows 10 IoT and connected to Visual Studio 2015. Run the Hello World sample to make sure you know how to connect.
  2. Update the GitHub extension (Tools - Extensions and Updates…).
  3. Clone the GitHub project in Visual Studio.
  4. Open the solution (.sln) file in the root.
  5. Ensure processor is ARM, select the “Navio Hardware Test” project then the drop-down arrow next to Debug then “Remote Machine”.
  6. The solution should compile, deploy and run on the Navio/RasPi. Use the mouse to select “LED & PWM” (the rest is not implemented yet). Check the frequency, set some sliders (best PWM near bottom) then click the Output ON.
  7. Play with the sliders to test your LED and servos/ESCs.
  8. Click Close then Exit to finish.

Enjoy, the rest of the chipset will be supported soon, then we can get onto making some real fun applications, maybe even a new autopilot on Windows IoT! :sunny:


Very interesting! I was actually thinking of this today…Its pretty cool how things continue to iterate!

I’m sorry but:

Seriously?! I can’t remember the amount of times I’ve cursed Linux for the most basic task. Just ask my wife…Now - not to say I’ve never cursed at Windows! :blush: 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 :smile:

1 Like

I’m not a coder, but noting that there is now a native Windows build of APM:SITL (, I imagine most of the work porting the firmware is done (the initial APM:Linux port was developed from SITL, with actual drivers substituted instead of the IMU/sensor emulations). If someone builds SITL on an RPi2 with Windows10 IoT, then I’d suggest that a Windows drone would not be too great a leap.
As for me, I’m happy with Linux

1 Like

Seriously:) I was talking about embedded usage and development, not desktop.
But I’ll trust @CodeChief on this, he already did a really cool thing.

1 Like

@auturgy It’s a native API, not simulation. Yes as you thought, for average APM users it’s nothing special right now, just something on the horizon, perhaps another choice later. I guess DIY/Makers will get the most out of it to start with.

Take a look at you’ll see this new system is getting pretty popular, even before release. Yes a new, Windows native autopilot is the next logical step :wink: 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.

After a necessary break to get some other important work done, I’m coming back on track with this project. Yesterday I updated the code to run on the release versions of Visual Studio Community 2015, fixed a bug and make some other improvements to the LED & PWM which I think is really stable now. I’ve also done the necessary research on the other chips and it all looks like plain sailing from here :sunglasses:

Next week I plan to start work on the RC input, which I think will be done very quickly, based on my research. I’m even considering having a go at supporting the SBUS protocol natively! Also I’ve investigated driver support, I’m now certain we need proper drivers in the end but that does not delay the conversion.

I’ll still finish the “components”, but then re-make them in a second platform driver flavour, so the whole Navio is automatically detected in Windows and “just works”, the way you expect it to do on Microsoft platforms. If it doesn’t complicate maintenance I’ll also leave the individual classes which wrap each chip, for people who just want to copy and paste code, one chip at a time (without drivers). Anyone running mission critical/real-time stuff (i.e. autopilot) will most likely require the driver based framework.

And there’s more to this driver support… What’s freaky is that Microsoft already put great support for GPS sensors into Windows IoT, meaning it should be possible, if I write a driver for it, to re-use the GPS as a native Windows device in parallel to autopilot functionality!!! Switching to drivers will also address multi-threading concerns and provide robust, hopefully “real-time” performance (one of the biggest open questions).

I’ve also created a project which anyone who is interested in “the story” can choose to follow and share easily. Some YouTube videos will follow once I get the thing flying (give me a month or two).

One other thing which is really important… Although this might appear to be a personal project, the intention here is honestly to produce a public community code base managed by Emlid, which is why it’s located on their GitHub repository. Once the core SDK is finished I hope many other developers will join-in the expansion of Windows support! Just give me some time to bash around different ideas with the object model and technologies until it’s really something stable we can build on top of. :+1:


The first “full” release of Windows IoT Core was just announced by Microsoft. Finally we have the missing wireless (both WiFi and Bluetooth) support necessary for a complete autopilot solution.

Also of specific interest to the Navio SDK, Microsoft hint at extended support for PWM and ADC, plus up to 10 times speed increase with GPIO! The current status of our SDK is that the RC input device code is complete, just the sample and test apps need to be written. So expect a GitHub update for that soon…

Overall the current outlook is that the “Core SDK” (all devices supported) should be ready in September, then the community can really start to use the Navio for IoT solutions. After that I guess we should have some “flying Windows” by October :wink:

p.s. According to the release notes the GPU driver is still not finished by Microsoft, so FPV and PiCam solutions will have to wait a while. There are other limitations too and it’s quite likely the list of supported wireless devices is short to start with. But they’re clearly busy so I expect we already have that capability by the time we need it. There appears to be a monthly release cycle for the IoT image.


Just checked-in an update to the SDK. I almost finished the whole RC Input, in fact the hardware part should be “done” but since I have not tested it so far I’ll only call it 50% complete. The implementation was quite easy because Microsoft already provide logic change events for GPIO.

We’ll have to see how fast this type of event handling is in reality, whether it can steadily decode RC input whilst doing other stuff (the same demo will be created as for Linux, reading input and moving servos at the same time). Also it’s the first component where we really need to check how much CPU is used, just listening to the PWM signal. I’d expect this is one of the main components which may require a driver in the end, but for proof of concept it’s still good as a user mode component.

Also I did some research on SBUS and am so confident about supporting it that I’ve already put some place-holder types and functions in the code (can always remove it later if I find a show stopper). The RC Input button is still disabled in the test app because it’s not finished. The XAML page you can see there is just a first scratch for CPPM support. But I think in the end something nice and graphical like a logic analyser would also be useful, as there is much space left on this screen too.

I’m off on holiday for a week and a half so there’ll be a little delay. But it’s coming along nicely…

1 Like

Great job, looking forward to next progress

This is a quick update which enables the “RC Input” button in the Hardware Test App and dumps the PPM values as debug messages to the Output window of Visual Studio. The PPM decoding appears to be working, with my FrSky Taranis Plus and X4R-SB receiver with CPPM adapter, producing values between ~0.5 and ~1.5 milliseconds as expected.

What I’ve learnt so far is it needs to be re-factored to batch-up events and iron-out some occasional errors. So it’s time to make it more like a network layer driver and batch-up the PPM frames into windows in a time critical thread, then apply some better normalization and error correction logic than the dumb average and time-out we have currently.

I’m keen on reproducing a logic analyser view then comparing to a real logic analyser display, to identify if the software is causing the differences or it’s just the normal drop-outs you get when the RC transmitter is too close to the receiver (I have both on the desk where I am working).