Thanks also to @Bert_Helsen for his contribution.
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…
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
http://www.udoo.org/udoo-x86/ - 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:
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
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 (https://github.com/emlid/Navio-SDK-Windows-IoT/issues/14) 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: http://www.thingiverse.com/thing:1780041
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.
Hi Tony I am grad you are about to complete Navio on Windows. BTW, your 3D data gives us “403 - Access forbidden”
Thanks, I wasn’t aware the TinkerCAD project URLs are available to share yet. I’ve changed the URL to the Thingiverse project I used for the Navio 2 case top, renamed and updated that to include all the models: http://www.thingiverse.com/thing:1780041
Individual TinkerCAD design URLs (which should work):
Navio 2 Top: https://tinkercad.com/things/cvdVhOuZqBk
Navio Plus Top: https://tinkercad.com/things/4z31DjB6Dxi
Navio Base: https://tinkercad.com/things/3KqMfuJ8s5K
Controlling the drone via mavproxy with Windows 10 IoT
The next release 1.0.9 alpha is out on NuGet and GitHub. This completes a major refactor of the framework to support multiple hardware models with automatic detection. Generic interfaces have been added for all devices and a provider/factory pattern now manages the lifetime/singleton of the Navio “board” and devices.
In simple terms it’s easier to use and the same code works on all devices, within limits… Where physical differences occur, like no FRAM or LEDs which are only on or off on Navio 2, additional properties have been added to the interface to allow the consumer code to adjust accordingly. Most importantly when the device and feature exists on the model, it “just works” and behaves the same way as the other models according to the interface contract (compatibility).
After updating the Hardware Test app and all samples and testing switching between Navio+ and Navio 2 it seems like the best way forwards and we should get a future proof/backwards compatible framework this way.
Next step is to gain access to the Navio 2 coprocessor and implement the missing devices (ADC, IMU, GPS). RC input on Navio 2 should work as soon as access to the coprocessor is sorted, but Navio+ RC input has to wait for Microsoft who are currently re-writing their Device Controller management driver to provide buffered and timestamped GPIO events.
Another check-in of major work on the RCIO co-processor. Turns-out the firmware it’s running emulates a PX4IO/Pixhawk co-processor (makes sense, considering APM is the main target). So I have implemented a complete (so far as I am aware) PX4IO protocol and it works! The other hurdle which was solved is access to the second SPI bus from Windows ioT. Basically it works from C++ not .NET.
The Linux RCIO driver was used as a model for the protocol and cross-checked against the official PX4IO firmware repository. Basically it operates on a concept of register/data “pages” which are already split-up into logical groups like setup, configuration, controls, sensors, etc… Here you can see the results in the debugger:
Some work still needs to be done on converting some of the values but they appear to be correct. So I can go ahead and get RC input working with hardware support on the Navio 2. Good news for Navio 1 and Plus owners too is that Microsoft came back again about the GPIO buffering and promised it will be supported in the next SDK release. So lots happening here now.
Along the firmware sides, I’m also implementing the ARM SWD (Serial Wire Debug) protocol so we can fully interact/support/configure/upgrade this co-processor. I’ve started adding an “RCIO Terminal” tool to the soluton for this purpose:
On the language side there was also a “journey”. As it turned out the C++/CX has a successor, C++/WinRT that is highly recommended (and will replace) it as the standard WinRT C++ integration “framework” (it’s actually just header “transformations” which makes it even better, like pure C++ than a heavy/slower wrapper). That’s good but not complete by MS yet so we have a mix of C++/CX for the external interface but can still use the (much) higher performance C++/WinRT code for the internal stuff.
Next steps, finish the RCIO implementation and continue conversion to C++. Right now it only works with Visual Studio 2017 RC and the WDK is not out for that yet so the drivers are not important at this time, they will follow later at lower priority. The C++ framework will perform adequately for the first version.
@CodeChief amazing work on this!
I’m currently getting error “Unable to resolve ‘Microsoft.IoT.Lightning.Providers (>= 1.1.0)’” when trying to add the NuGet package to a new project. Both when I have already added the Lightning NuGet package or when I haven’t and it tries to load it on its own. Any suggestions to resolve?
Thanks! The Lightning Providers are actually removed in the next version and this appears to be a dependency issue when installing the Navio package. Either try to install it separately in the project first then try again, or wait and I will make a new upload probably later today or tomorrow.
The current framework uses C++/WinRT for the low level IO so Lightning is no longer required at least for Navio 2. Actually it appears MS are converging Lightning back into one single provider with new features so it may disappear anyway (or throwing away the “inbox” controller and replacing it with Lightning, depending on which way you look at it).
Did you catch the small release note that the current version only works in VS2017 RC now? I didn’t have time to update all the documentation in all locations yet (just in the code, not on the Emlid site yet). Visual Studio 2017 is due for release on 7th March so maybe they already did something with the Lightning packages.I hope the new/matching WDK and compatible IoT tools should be released at the same time. I’m eagerly awaiting that date to make a big update.
If you didn’t already install that I’d recommend waiting until the RTM release date and making a clean install. Historically beta versions of Visual Studio are known to have issues when upgraded to RTM, sometimes even requiring a complete developer OS reinstall to get it working properly. So best wait for that. By the way they have a nice VM download option which is a good idea to play with: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines
Had picked up VS2017 RC thanks, so using that. As you say, MS packages are a bit of a moving target at the moment so appreciate the effort in keeping up with this.
Will hold off till your next upload, looking forward to getting it going.
Any news on updating the Nuget package? Still having the same issue.
I did try but there were endless problems with Visual Studio 2017 RC and VS 2017 RTM is out tomorrow so it’s best to wait for that. The Release Candidate didn’t compile anymore, very frustrating. The first driver was added a year ago then Microsoft broke the SDK/WDK with ther “external” (will not fix) bug. That was followed by important gaps (showstoppers, Lightning, SPI1 access, etc…) in the framework which they again had solutions to but chose not to release. Since then, we never had a complete set of tools which worked for Unviersal Windows, IoT and driver development.
So I seriously hope the RTM versions tomorrow will finally work like they are supposed to. A bit worrying was the warning at the latest Insider Preview WDK, that installing the driver kit disables Unviersal Windows development. Kindof contradictory. Whatever Microsoft do, they should release a complete set of tools, I have no more time to waste on endless betas and really want to finish the IoT/Navio solution. It’s time to stop the “insider previews” and make something which works. Fingers crossed for tomorrow then!
Thanks for that! Ok, will hold off until RTM is out, as you say, hoping it resolves all these issues.
I’ve completed the 2017 RTM update but the NuGet package script needs some tweaks. It’ll be there shortly…
A new NuGet package 1.0.11-Alpha has been published and the whole solution should work properly with 2017. MS already (just one week after RTM) released a VS217 “update preview” so the VS tools are clearly still “work in progress”. I tested with that and as they specifically state it was intended to solve issues with Universal Windows development, so use that if you get issues with 2017 RTM.
To make all this easier to use some long awaited tasks will be done soon:
- Make an IoT FFU image so the average user doesn’t need to anything special to test it out, also doubling as a hardware test tool for Emlid or a core image for anyone else’s app/code written with it.
- Documentation with screenshots and double-check the usage in a stand-alone scenario, to check if any of the dependency DLLs are still missing in the NuGet package… Let me know if you find problems before, otherwise there will be an update shortly anyway.
- Complete conversion to C++ and outstanding chips (IMU, GPS, etc…), CoreSDK milestone. Really usable then.
The driver/WDK is still dragging it’s heels due to MS tooling issues. Up-vote my comment there if you want some attention on it The general advice from MS is to not bother trying to get it working in the same GUI/VS2017 and setup some command line scripts to start/deploy with WinDbg (WDK directly). We already have some PowerShell scripts for the driver deployment so this will be implemented as soon as the next driver development work item continues (after Core SDK and Navio2 hover PoC which can be done without drivers as it has hardware RCIO).
New v1.0.12 checked-in and released to NuGet to support Creators Update preview SDK build 15063 and fix the VSDevCmd location issue using the new standard Microsoft VSWhere tool.
Version 1.0.13 checked-in and released to NuGet to support the release versions of the Visual Studio 2017 Update 1 aligned with the release versions of the Windows 10 Creators Update 1703 SDK and DDK builds 15063 and .NET Core 5.3.3.
All tools are release versions now including the NuGet package. Should make ongoing development easier…