 |
Autopilot Firmware Requirements:
Now that we know how to configure Flightgear we can start to look at what our autopilot firmware needs to do. Although I will be talking about the specifics of what I implemented on PICPilot, the concepts can be applies to any autopilot. One of the main concepts I wanted to strive for while adding a Hardware in the Loop(HWITL) mode to the firmware was to keep as much of the code as possible in common with the standard operating mode. This will minimize the chances of the autopilot behaving differently between the two modes.
The first thing that needed to be added was a means of telling the autopilot what mode it was to be operating in. This is done with a system flag bit. There are already several system flags for controlling various functions in the autopilot, so it was straight forward to simply add one more to the mix. This flag is initialized to a zero or non-HWITL mode at power up. The PICPilot in always monitoring the USB interface, so I added a special HWITL packet containing a command word to it's list that would set the HWITL flag when it was received. As an added safety, I reset the HWITL flag to a zero if I don't receive a HWITL packet for more than a second. This is just in case the bit is inadvertently set during a real flight, although I can't imagine how that could happen. Better safe that sorry.
Now that we have a flag to tell us when we're in HWITL mode it's time to think about what needs to happen keeping in mind the golden rule that we want to minimize the differences between HWITL and Non-HWITL modes. The first thing we need to do is read in all the data being sent to us from Flightgear. I had already defined the HWITL packet that contained the command word. This packet also contains all the Flightgear data including body rate, body accelerations, Latitude and Longitude, altitude and speed. I simply read this data into internal variables that are analogues to the variables that contain the real sensor data. For example I have the variable GPS_Lat which contains the last Latitude value received from the GPS receiver and I have HWITL_Lat which contains the last Latitude received via the HWITL packet. Both sets of variables are completely sperate with no danger of them stomping on each other. Finally, there is a third set of variables that are the ones actually operated on by the various IMU, Navigation and stabilization functions. These have the prefix CURRENT ie CURRENT_Lat. I do my internal processing at a 50Hz rate, and just before I do the processing I copy the appropriate variables into the Current working registers depending on the state of the HWITL flag. This is done in one place in the code rather than spread out in the various functions making it easy to follow and modify.
We are now using the HWITL sensor data for IMU, Navigation and stabilization processing. All that's left is outputting the control surface and throttle commands. PICPilot does all its control surface processing including attitude and rate control, mixing and filtering on a normalized variable range meaning the variables have a range of +/-1 (in fixed point notation) indicating full deflection in the positive or negative direction. It's not until all this processing is done that the values are converted to a pulse width for driving the servos. Since Flightgear is expecting the commands in the same format, it was trivial to grab the variables after all the processing was done and pass them out via the USB interface to Flightgear. The format of the output packet is exactly what Flightgear is expecting based on our xml protocol defined previously with one exception. I added a variable at the end of the packet that defines what the current Way Point is. Since no corresponding Flightgear variable was defined in the xml file this is simply ignored by Flightgear. The value is displayed by the interface application making it easy to know where things are in the flight.
Since the processing is done at 50Hz, a new packet is sent out 50 times a second. The 50Hz processing is controlled by an internal autopilot timer. This means the output packets are completely asynchronous to the input packets. This can sometimes be an issue with real time systems, but thus far has not appeared to cause any problems.
An added bonus to the HWITL firmware mods is that a receiver can be hooked up to the autopilot and a radio can be used to control Flightgear. This makes for a great flight simulator to practice your flying.
.
|