I wanted to send commands to my UAV during flight. Implementing this on my ground station was not hard at all. Doing the same on my autopilot software turned out not as easy: parsing (and validating data that could be gibberish) data coming from the serial interface could potentially disturb the strict timing needed for my kalman filtering. That strict timing also prevented my from doing some other telemetry and dataprocessing stuff.
It was time to port my code to a real-time operating system. Also a good excuse to start playing with it :-)
I’m not familiar with a lot of those “free” RTOS’s on the net, so I picked up the most common one: FreeRTOS
I had read the documentation a few times before, but never got to the coding part. It turned out pretty easy! Thanks to the modular approach i used in the autopilot software, porting it to FreeRTOS was finished in about an afternoon!
Now I can add various new functionalities without worrying how to fit it in the current code.
Another advantage is “Run time statistics”. Before I thought I used about 40% of the CPU, but it turns out that I’m only using 6% of it:
TickTask 267 <1% IDLE 49058 94% 5DofTask 2098 4% ControlTask 481 <1% GpsTask 16 <1%
- TickTask: the task printing this statistic (once every 5 seconds)
- IDLE: the idle task, when nothing else is running
- 5DofTask: the task calculating the attitude (Kalman)
- ControlTalk: the task calculating the PID control algorithms (50Hz) and the navigation (5Hz)
- GpsTask: the task parsing the GPS strings (5Hz)
I’ve been working on 2 things lately (past few months, I didn’t have a lot of time in the last few weeks):
- New autopilot module
- Glass cockpit framework
This demo combines both of them:
- Simple waypoint editing in the first seconds on the video
- KML file viewing
- Uav simulation: the navigation and control is done on the autopilot module. Sensor data comes from a simulated airplane model on the PC, servo positions are sent back to the PC. In manual mode, the autopilot module forwards the inputs from my RC transmitter. In autopilot mode, it will circle the home position (I should tune it better).
This HILS (Hardware-in-the-loop simulation) idea came to my mind after seeing Jordi’s great demo.
- Microsoft Virtual Earth for the maps (I also have a class for Google maps, but Google doesn’t seem to like us ripping their tiles).
- WPF (a .NET 3.5 technology) is a graphics framework that does most of the rendering on the video hardware (not loading the CPU).
- C for the dsPic on the autopilot module
- General C#.NET for the airplane modeling
- The windows application is completely OO. The view area consists of layers, all deriving from a base layer class. All layers have a model too. When the workspace is saved, the models are persisted to disk. This pure OO approach makes serveral transitions easy. For example I can switch between a .NET autopilot or a hardware autopilot class without affecting any other code.
Today I did another flight test in very bad weather (actually my car got stuck in the mud yesterday while testing…). I also wrote a tool which makes it very easy to download the logging from the autopilot, and save it as XML (for later use) or KML (for Google Earth). The dataset viewer allows easy copying to Excel.
I finished migrating all my hardware-related code from my old autopilot to my new one. The most important new feature for me is datalogging (how could I ever live without it). Data is logged in a binary format on a dataflash chip.
The flightitself was manually and it’s only purpose was to test the datalogging feature.
It works! I was suprised to see how accurate the EB-85’s GPS height is. When I make a flight together with the barometer I’ll post a comparison between those 2 heights.