@CodeChief is the Pi Cam or any other USB Camera usable under the Windows Image ?
Do you have any metrics how they behave ? Delays etc.
Is DirectX loaded ?
I havent used it at all…and I have some ideas.
When Microsoft finish their DirectX driver then I can’t imagine any reason why you wouldn’t get similar performance to Linux when running the hardware encoding (think it’s H264): Historically the whole DirectX stack could bring a lot more too. That’s probably why it’s taking so long.
In the meantime there are some USB web cameras are supported ( http://ms-iot.github.io/content/en-US/win10/SupportedInterfaces.htm#Cameras ) and due to the ribbon cable requirement perhaps it’s better with a USB camera anyway (depends on the size of your drone/rover too). Still we need DirectX drivers running on the RasPI IoT OS to support efficient use of any other camera and H264 streaming down to the ground station/FPV.
As suggested in the last post, the strategy has shifted back away from the drivers until MS get the bugs in their tools sorted out. At least the user mode part is relatively stable and easy to work with, so we should be able to get the NuGet downloadable “Hardware Framework” finished with everything except RC Input quicker now.
Then we have something to play with very soon, and you can test your ideas and test latency. At least for a simple demo, there should be minimal delays because it’s not like we would be starting with full APM code. A basic PID loop and stabilize mode would be a fantastic achievement when everything has been written from scratch.
Flying around with an XBOX controller should be feasible to start with then. The Navio 2 is exciting because that has hardware support for the RC input, so it is likely to be the first board with fast control capabilities running on Windows. Navio 1 won’t be forgotten for RC input, just later.
Maybe the wifi support in IoT is fast enough anyway, as it would have been ported from Windows 10 desktops/mobile anyway (should already be optimized). I suppose you could test in advance by copying files around/benchmark and comparing it to Linux realtime OS wifi stacks.
We can track the progress of the MSIOT RasPi2 video driver (and browse the source directly) here:
Looking at the last commit dates it’s in active development and already has plenty of source there. Just one point of concern is in the Read-Me file it says it’s a 1-2 year project (!) so I hope there is enough demand on the IoT forums and MS customers to get this brought forwards. It says one guy is running the project but there should be a lot of MS support around him.
Fingers crossed there, looks like a “render driver” will be first before all the fancy shader stuff, that makes sense. Maybe some of us could help them by testing their driver versions and giving feedback? At bare minimum we need #1 the renderer and #2 video encoder support. Then next preference #3 is the PiCam, but we could live without it (USB camera) to start with.
2015.12.22
Device driver “capability” proof of concept. Working skeleton RC input kernel mode WDF driver which successfully deploys and can be communicated with from a user mode Universal application.
Various patches and documentation updates to existing source code and samples.
Updated solution to work with latest IoT December 2015 OS build 10586, SDK/WDK 1511, Visual Studio 2015 Update 1.
This is an interim check-in which does not add any end-user (consumer developer) functionality, but solves the technical requirement to be able to write a kernel mode driver and communicate from user mode. Because of the difficulties with the VS2015 tools and lack of improvement in update 1 (which actually got worse in some aspects) focus will temporarily shift back to the user mode framework for all other features than RC Input. Also with the release of Navio 2 which has RC Input hardware, the device driver can wait a little while, so we can first gain the full chipset functionality in user mode and maybe see if a simple quadcopter can hover with it (and a joystick instead of RC input). Commitment is still there to produce high performance (real-time) and robust drivers shortly after a successful user mode PoC.
So I managed to get the device driver skeleton and user mode communication working with the new tools and OS build (besides open issues with Microsoft). There’s an interim check-in on GitHub to save all my driver work-in-progress, before continuing with the user mode framework as discussed previously.
This is not for consumption, unless anyone wants a headache trying to get a self-written driver deployed with the current Visual Studio tools 
Here are some screenshots in case you are curious what it looks like 
Deploying with proper INF package from Visual Studio:
OS driver update boot loader (Windows Phone style):
Driver loaded successfully (also means plug-and-play/ACPI resource assignment working):
Successful access from user mode application (using new style device interface GUIDs rather than older DOS path emulation):
Next steps:
- Skip RC Input for a bit, go back and complete all other features in user mode.
- See if implementation of Navio 2 RC Input hardware is possible in user mode.
- See if we can get a drone hovering in user mode (with RC input via joystick if still no RC Input solution).
- Back to writing drivers to provide a real-time robust solution.
3 Likes
Version 1.0.6 has been released to GitHub and NuGet:
# Change Log
*2015.12.28* v1.0.6
1. Barometer (pressure and temperature sensor) implemented.
2. LED cycle feature added to LED & PWM test app.
Continued development of the existing C# sensor library. Note the barometer temperature is always about hotter that then environment because of heating by surrounding components, e.g. the Raspberry Pi processor is sitting underneath it. For that reason you will also see the temperature rise in the hardware test app, because the processor is being taxed with the GUI functionality.
This version requires Visual Studio 2015 Update 1, Windows SDK & WDK for Windows 1511/VS2015 Update 1 and IoT build 10586 running on the target.
Updated screenshots (excuse the quality I have to find a better solution for screen grabbing as MS do not have any remote screenshot capability):
Click the new Barometer menu item to try out the new sensor code:
The barometer was a really successful chip implementation with no apparent issues (feedback and bug reports welcome). Like the Linux code we see the hardware reports many degrees greater than room temperature and continues to get hotter as we tax the processor with GUI rendering tasks (MS still didn’t write the RasPi video driver so it’s all software/high-CPU load under test).
I wonder if it would be possible to isolate the Navio board from the heat of the RasPi board beneath by either shielding it, fitting a heat sink which draws energy to the side, or using a ribbon cable to split it off to the side. So effectively with this sensor, we only use the pressure to get the vehicle’s height and the temperature is only useful as an internal temperature. I suppose an external I2C wind speed sensor would provide more accurate temperature, like those already available for the PixHawk.
Anyway to use the new code simply update the NuGet package and look for the new NavioBarometerDevice and MS5611* types:
The LED & PWM test has also been updated to automatically cycle the LED:
The RC Input test remains in it’s beta semi-working state. Obviously the refresh rate is terrible, as discussed previously GPIO decoding is software driven so requires a driver. To get some output you will need to move the sticks around and wait a while! I am deliberately not working on this until after the other components and Navio2 hardware RC input support (see previous posts). Then the whole framework will be converted to high performance C++ and drivers, over a longer period whilst people can still use the slower user mode C# framework.
Next-up… something easy I think… hmm… I think it’s time to poke-around with the FRAM 
2 Likes
Version 1.0.7 has been released to GitHub and NuGet:
2016.01.02 v1.0.7
FRAM memory device implemented, both the MB85RC256V of Navio+ and MB85RC04V of Navio.
General test app GUI display, usability and multi-threading improvements.
Continued development of the core SDK. FRAM complete and fully tested on Navio+ device. Support for the original Navio’s FRAM chip had been coded but has not been fully tested.
Updated screenshots and YouTube video coming…
2 Likes
Okay it’s done…
Had to film it with my phone in the end. Tried Mobius and other tricks but the focus is just impossible against a high contrast FPV monitor. I’ll order an HDMI game capture box next week as I think I’ll use it more in the future. Shame Microsoft don’t provide any kind of RDP access to Windows IoT yet. If it were any other Windows box it’d be easy to make a video with free capture tools.
Anyway so you all get an idea now what it looks like when you boot Navio with Windows IoT and what the graphical test app looks like so far.
Next I’ll upload a preloaded image soon so people can just blast it onto an SD card and try it out without any development tools. Then just the ADC, IMU and GPS sensors left to do. Not long before we see if windows can really fly (hopefully not just smash into the ground)! 
5 Likes
@CodeChief
You got skills, 
Really amazing how you have put everything together. I’m keeping a close eye to this development, and i hope you will succeed flying an Windows based aircraft.
Keep up your good work.
4 Likes
Guys some fantastic news… The “UP Board” kickstarter was successful and they have achieved “Windows IoT Core” support. Since they claim the same or similar GPIOs to RasPi, that means all of the Navio for IoT code should work, or with minimal modification, on the Up Board.
That’s crazy, a full next gen Intel Atom potentially running Navio!
The pin out is not only compatible with RasPi (save a few GPIO# sequence changes) but there are additional optional features on many pins, for example 2 pins can be configured as PWM pins!
In contrast the original RasPi pin-out below:
No promises here, Emlid don’t support this of course and the focus remains on the officially supported RasPi2… But personally I really want to give that a try after the Core SDK is finished on RasPi2 
4 Likes
If only they would have included second SPI… Maybe worth letting them know about this incompatibility with RPi connector?
Thanks Igor for checking that out, shame something appears to be missing. I’ve contacted them and will post any update here. If they have no solution I wonder if there would be some kind of hack, that we could get 90% or more of Navio working. Producing a special ribbon cable with a few passive components or something like that might be worth it if the benchmarks are significantly better.
Anyway, on with RasPi2 support… 
I agree that more mhz is better, but is there any issue foor .net RPI i think for controlling purposes of the drone 800mhz is more than enough not? in the past things were flying <100mhz if we want to do video processing than we might need extra computation power but than the question is do you want it on the same board as your flying unit…
1 Like
Had a nice email from Tom Rice who said he was able to make use of the code in the SDK (not for Navio but similar chipsets) and in return shared some additional stuff they wrote for the MPU. So that will be next and should not take as long now
This community stuff rocks I really look forward to when the SDK is finished and we get commits into a new APM-like system.
1 Like
After a long delay mostly due to personal commitments I have time again to complete this project. Zzz…
Good news is during the wait Microsoft were busy and just released a “lightning” provider udate (the original was not sufficient) with the requested events and debounce timeout. So we should be able to get something like usable software RC input on the Navio+ and perhaps more realtime like performance with all GPIO/I2C/SPI devices. I already integrated the new lightning module and will refactor-in the outstanding contributions for the other sensors.
As it stands I still think the overall project has a good chance, because MS are obviously committed to RasPi. There is a lot of activity, RasPi 3 support and multiple GPIO/I2C/SPI controllers should now work with the lightning drivers (necessary for Navio2 RC input support).
The .NET Core upon which the whole cross-platform application system is based (also running C# code on Linux and Mac now) is near completion and Microsoft have proven Linux and Mac support on top of the existing Android and other mobile devices. That provides an additional field of development, with a single codebase but minmum complexity, it should be straightforward to produce great looking stable cross-platform ground stations, proxies and other “drone code”.
Whatever proof-of-concept autopilot spins-off from this work (at least to prove the Navio IoT works) may also become a useful toolset/application suite even for non-Windows firmware. Let’s see where the journey goes but at least finally get Navio IoT off the ground…
4 Likes
RE: Up Board - Windows IoT
We purchased and reviewed a couple of their boards for a project we are working on, we also reached out to their OEM partner contact.
It wasn’t great news, Windows IoT is now not supported by them, they cite MS / Intel lack of Processor support out of the box. Doing our own research it’s true their is no BSP support for UP out of the box but couldn’t tell if there was still an issuing with the IoT tooling for custom images or it was a lack of skills / understanding from UP which preventing them from building a custom image.
We did considered building a custom image but decided against adding even more technical risks to our project and settled with Raspberry PI + Navio for at least the 2nd stage of our project; we evaluated the following boards also:
http://www.lattepanda.com/product-detail/?pid=3 - This runs full Windows with built-in Arduino IO
404 - This runs full Windows with built-in Arduino IO + 6 axis sensor
I was checking on the latest status of the Lighting providers to see if they would provide a middle ground, looks like they done a bunch of work to these; I found some old performance stats as well, I’m just looking for the code for this so I can try re-running them:
https://raw.githubusercontent.com/ms-iot/content/develop/en-US/Docs/LightningPerformance.md
Some examples of use
I’m still not sure if this would be enough performance vs direct device driver though.
On that note there’s some documentation on the hoops needed to install the device driver here now:
A new version of the SDK has been released on GitHub a few days ago with the Lightning provider and SDK updates implemented. It only runs on the Insider Preview build so you should register for that to get the OS image.
The Lightning provider works but it appears the overhead of the faster events from the driver slows down the timestamp calculation/PWM decoding in user mode (makes it worse). Also some initialization issues (hangs) were observed when running in the GUI. The background task samples didn’t have such problems so it’s possibly to do with multi-threading. I checked the GUI code quite a lot regarding initialization/disposal and everything seems okay, also it works fine with the standard “inbox” driver so I won’t waste anymore time there until the next Lightning provider and/or OS build is released because…
Microsoft now tell us that an upcoming public build will include both PWM timings and a buffer of information. That will be great because then we can get the user mode code working as fast as possible, with Microsoft drivers.
For anyone wanting to test the current version, with the hardware test GUI, leave the driver type (in the web console) set to the “inbox” driver for now. The GUI may totally lock-up with the Lightning driver. To test lightning with RC input, best use the background application, i.e. the “RC Input CS” sample.
For most people who are interested in this topic, you probably don’t want to download this version if you have already seen it. There are no visible changes, just code improvements and updates. It still works as demonstrated in the YouTube video.
Anyway the good stuff is that now MS finally produced a working driver development kit (the Anniversary WDK) work can continue 
1 Like
Sorry for the delay. I’ve finally finished a move, load of other work I had to do and setting-up a new office where I can continue development more efficiently. Work has already restarted and I’m committed to get this project finished before the end of the year.
A small update to the source was published on GitHub last week to fix an expired certificate (Build error .pfx file · Issue #14 · emlid/Navio-SDK-Windows-IoT · GitHub) so it’s usable again now.
I’ve also adjusted and 3D printed the Navio 2 case from the forums here to work with Navio+, Raspberry Pi 2 and 3 interchangeably: Emlid Navio Case by CodeChief - Thingiverse
I now have the 3D printed parts I need to build identical drones with each Navio model for proper Windows IoT testing, proof of concept and cross-platform benchmarks. This reference build will be documented with photos and published soon.
Some people have already implemented a couple of the remaining chips which were possible (don’t have issues described below) in branches or private code, namely IMU and GPS. Just be aware as indicated in the documentation, that until the core SDK is finished major changes will occur. Currently major refactoring is underway to support new hardware. The goal here is to produce a consistent, tested, reliable and easy to use framework rather than quick gains with errors.
The main issues are to do with real Windows IoT hardware compatibility which may prevent a feature complete version from ever being implemented, e.g. access to the second SPI bus, protocols and firmware for the new coprocessor in Navio 2, lack of buffered PWM input drivers for Navio/Plus.
With Navio+ we could live without RC input in a worst case scenario, but in Navio 2 it appears both the RC input and PWM output are hidden behind the new coprocessor. A drone/robotic solution without PWM output is pretty useless, so a proper solution must be found.
Regardless, I’ll push support for IMU and GPS forwards in my priorities and get the official branch updated soon. You’ll also see some standard interfaces appear which will help avoid so many code changes later.
1 Like
Hi Tony I am grad you are about to complete Navio on Windows. BTW, your 3D data gives us “403 - Access forbidden”