Many people with RC multi-rotors, planes, rovers or boats know
the "APM" autopilot system, previously known as ArduPilot. In fact it's probably the most popular open source drone system in the world. Originally limited to Arduino size boards, the hardware has finally grown-up to run on embedded computers.
Emlid's Navio+ is a relatively inexpensive HAT for Raspberry Pi which provides a full range of sensors, GPS, servo outputs and inputs, A2D, I2C, SPI and UART interfaces. So you can run APM on your Raspberry Pi, but also open up a whole new world of power and flexibility for your autonomous vehicle, robot and DIY projects.
Enter Windows IoT!Until now, autopilot systems have lived in a Linux world. So with the announcement of Microsoft Windows 10 IoT running on Raspberry Pi 2, it was time to do something about it! This project follows the port of the whole SDK from Linux to the Windows Universal platform! It's actually a complete re-write with an object orientated framework approach, using native Windows technologies and best practices.
Not only should this achieve a full autopilot system for Windows IoT, but also open-up this unique hardware device to the Maker community.
See it in action here:
Why Windows?Of course you can already use the same hardware with Linux, so you may wonder why this is being done. The biggest reason to port over to Windows is to enable real end-user plug and play solutions we have come to expect on Windows! When written and packaged correctly, you can finally produce projects and products which "just work" out the box.
No more complex Linux commands and cryptic text files for users to edit. No more Linux driver re-compilations. We're on Windows, it's easy! Just tell your users to plug the hardware in, download the prepared image (or drivers and app separately), then run!
All this on Windows with almost guaranteed backwards and future compatibility, thanks to the Application Binary Platform and professional approach we all know Microsoft are good at. Now that's something Linux developers and companies wishing to sell products based on such systems can only dream of!
Work in Progress!The system is already running and one of the hardest components has already been successfully ported. You can view the source code and build it at the GitHub repository. You can also follow progress and discuss in the Emlid Community Forum thread.
We encourage users to play with the samples and test programs. Developers can also start using the framework for their own applications. However, development contributions to the framework and test apps themselves are best avoided until we are finished with the core SDK.
Milestone 1: "Core SDK"Mission statement: "Full hardware support for Navio on Windows IoT."
- LED & PWM (PCA9685) device, sample and test app (100% complete).
- RC Input (PPM over GPIO) device, sample and test app (60% complete).
- IMU (MPU9250) device, sample and test app.
- Barometer (MS5611) device, sample and test app (100% complete).
- GPS (U-Blox NEO-MN8, possibly NEO7M, NEO-6T too) device, sample and test app.
- ADC (ADS1115) device, sample and test app.
- FRAM (MB85RC04) device, sample and test app (100% complete).
Mission statement: "Answer the question; can you really fly a drone with Windows IoT?"
- Motor control and PID logic for a quadcopter.
- FMU test app, enable raw flight with RC input in stabilize mode.
- Manual (acrobatic) mode and switch capability.
- RTL failsafe mode and switch.
- GPS fence failsafe with auto-correction.
- MAVLink proxy, including Ground Control Station support.
Mission statement: "Expand support and add new devices."
- Support other multirotor types in the PoC application.
- FrSky telemetry.
- FrSky SPort (sensors) device(s) and test app(s).
- U-Center GPS proxy for easy configuration / upgrade of GPS.
- RTKLib integration for highly accurate GPS.
- Emlid REACH integration, similar to Windows Remote Arduino or as close to full IoT Intel Galileo (Intel Edison) support as possible (depends on how good Microsoft's support is in this area).
- Expand the Windows drone sample, possibly spinning-off a new autopilot (includes support for other vehicle types, e.g. planes and rovers).
- Experiment with Windows HAL for APM (requires a good Linux code bridge like Cygwin, but for IoT).
- Expand samples for other (than drone) projects, e.g. general robotics, trackers and DIY solutions.
2016.08.24 v1.0.8
- Updated solution to Visual Studio 2015 Update 3 and Windows 10 SDK and WDK version 1607 build 10.0.14393.
- Support new Microsoft Lightning provider v1.1.0 for faster hardware access. Now referenced via NuGet package, removing the need for manually built dependencies.
- Updated .NET Core SDK package to current 5.2.2.
- Refactored harwdare source into separate subdirectories/namespaces so it is easier to manage and use.
- Addressed some minor bugs in the GUI.
- General refactoring and tidy-up.
- Improved setup scripts and instructions.
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.
2015.12.28 v1.0.6
- Barometer (pressure and temperature sensor) implemented.
- 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.
2015.12.22 v1.0.5
- Device driver "capability" proof of concept. Working skeleton RC input kernelmode 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.
2015.10.06 v1.0.4
- RC input C# proof of concept complete (so far as worthwhile). Only accurate to ~1 second due to "floating GPIO" limitation (see notes below).
- Completed RC Input in hardware test app and added new RC Input C# sample.
- Added NuGet package. No need to download source and compile to use the hardware from now on! The package URL is: https://www.nuget.org/packages/Emlid.WindowsIot.Hardware
Due to a Microsoft IoT image limitation, specifically with the GPIO #4 pin hard-wired to RC Input on the Navio, we cannot achieve any kind of acceptable performance in "user mode" code.
Furthermore, the current UWP API has a lack of support for time critical threads in "user mode". It is necessary to bring forwards the conversion to C++ and device drivers.
The next release will include only drivers and provide access via a C++/CX coded Windows Runtime Component. C# code and any other language can then be used as normal for user applications.
2015.08.25
- RC input progress. Test app enables use of RC Input, but no GUI interaction yet. For now use the Output window of Visual Studio to see debug messages repoting decoded PPM values. They appear to be correct, but some tuning of rounding and frame error detection is required.
2015.08.14
- RC Input hardware classes done in their first untested form.
- RC Input model and preliminary view added to hardware test app, but not enabled yet.
- Minor clean-up and coding standards in other classes and projects.
2015.07.31
- Updated solution to Visual Studio 2015 RTM.
- Hardware Test App - Fixed theme/resource errors and applied "Emlid green" instead of default "IoT pink".
- SetLED - Fixed error in buffer write routine.
Comments