Aviation Stack Exchange is a question and answer site for aircraft pilots, mechanics, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I would like to develop my own guidance, navigation and control (GN&C) flight software on a Raspberry Pi, for a small hobby fixed-wing UAV. From a physical standpoint, what is the minimum set of sensors/inputs needed to implement plain old GPS waypoint-following?
I understand I have a lot of math to learn, but what is the minimum set of inputs for that math? I have experience with embedded C++ for vehicle entertainment systems, but no knowledge in the aviation realm.
The absolute minimum for a generalized vehicle that needs to know its position and attitude (orientation) in space is one per degree of freedom. This can be reduced if we have information about the natural modes of the system and their stability.
For simplicity, let's assume a vehicle moving in 3 dimensions, that means a total of 6 DoF:
The simplest way to meet these requirements are accelerometers for the XYZ coordinates and gyroscopes for the angles, and these are often packaged together into an IMU. Technically you don't even need an actual GPS as long as you know the coordinates of the starting location, as you can just integrate from it to know your position. This is known as dead reckoning via inertial navigation and it works this way (let's use coordinate $x$ as an example):
Of course this has multiple shortcomings. Real-world accelerometers have noise, gyroscopes have drift, your starting location is probably inaccurate, your vehicle likely needs more data than that to operate and the whole systems I just described had no way of finding itself if it resets in-mission.
For a realistic barebones project like you described you will need:
Further data sources are desirable but greatly complicate the FCS architecture, since you need to properly weight the data, after all, you don't want the aircraft to trust the magnetometer more than the gyros and show you a little trick it learned when passing near a magnetic anomaly.
In particular, a Pitot probe is good to have know your airspeed as opposed to your ground speed. An alpha vane is a bit of a luxury and not needed unless you are pushing the flight envelope.
Any ground-watching sensor with sufficient update rate, range and accuracy (IR, laser, LiDAR, acoustic, etc) will allow you to smooth your landings, and which one you pick should depend on your design and budget; they all have pros and cons.
From the coding standpoint, if you are serious about doing this by yourself from scratch, you should look into real time systems, Kalman filters and the vast field of sensor fusion. Also learn some aerodynamics while at it, so that the airframe itself is not a black box to you. You can run an FCS on an Arduino, even for quadcopters, if you are content with just a basic SAS.
There is a large community of hobby UAV builders online that can provide you with an almost off the shelf solution for your FCS (Ardupilot), if you prefer that approach. I personally often find their documentation lacking, so I suggest you at least learn the basics behind what you are doing, to help you navigate the inevitable gaps in the manual. Also, since it is an open source project, you can then fill in those gaps.
It's probably possible with only the GPS receiver, but it wouldn't be easy and you might have to make some compromises on the airframe design to achieve the necessary passive stability.
The traditional set of sensors for this kind of application are, roughly in order of priority:
Since this is your first UAV, I would strongly recommend having the first 4 sensors and probably #5 and/or #6 (but maybe use those for diagnostics and analysis rather than control, since they can be a bit tricky with nonlinearities and reliability).
If you just want your UAV to fly to a waypoint, you could do it with a GPS sensor alone, if it was based on a very stable aircraft like a "Gentle Lady" or "Radian" r.c. sailplane, as long as you weren't flying it in very strong wind where there was the possibility of the aircraft going backwards over the ground when pointing into the wind and flying at trim speed. I suppose you would probably want an altitude sensor as well, unless you just want to apply enough power that the aircraft is slowly climbing throughout the autonomous portion of the flight. Of course, you could just get the altitude information from the GPS sensor.
If you decided to add a 1-axis yaw rate gyro, this would allow for smoother control. But in the context of a very stable aircraft as your basic platform, you really don't need any more than that, if your basic goal is to keep it simple.
Speaking from the viewpoint of one who has successfully controlled an ultralight aircraft in cloud using only a 1-axis electronic turn rate indicator, GPS, and wet compass-- and the compass was spinning backwards half the time. Control in specific limited circumstances (i.e. smooth air, not attempting constant circling in thermal updraft, making only very low-rate turns) was possible without the turn rate indicator, and a robot would surely do a better job of this than a human.
Just do sufficient testing to be sure the aircraft isn't prone to severe pitch "phugoid" oscillations at the CG you are using.
These inputs sufficed for an autonomous chain-of-waypoints transatlantic flight sixteen years ago.
Perhaps a summary introduction in control theory could help you. From a control point of view, your aircraft is a dynamic system, which can be described by a state and a dynamic model.
The state is simply a collection of variables of where the aircraft is in each point of time. For a full description, you would have the position and attitude in space, as well as their first derivatives. Any other inertia may also have their own state variable; for example, the propeller speed.
The state equations describe how the state evolves in time. From these equations (especially in linearized form), we can distill a number of (eigen)modes. These modes describe a certain behaviour of the system, and come in two forms: stable and unstable modes. A stable mode is a system dynamic that, for a finite input (perturbation), does not lead to any state variable going to infinity. Note that this does not mean that the state variables go back to some constant value: a bounded oscillation can still be considered stable! An unstable mode is a dynamic that for finite input leads to unbounded growth of some state variable.
To see how many sensors you need, you will want a few things. First of all, you want your system to be stable. Obviously, this means that you want to have a set of sensors that can measure any unstable mode (detectability), and a set of actuators that can control unstable modes (stabilizability). There are a number of (possibly) unstable modes, the most important of wich is spiral divergence. Many fixed-wing aircraft have no inherent roll stability, so you will want to be able to sense your roll angle (a yaw rate or heading sensor could work too, due to the roll/yaw coupling). Furthermore, there is simply your linear motion, which is also unstable (this may seem counter-intuitive, but all it means that you can get infinitely far from your initial point by travelling in a straight line). For this, you will want some kind of position sensor (most likely, a GPS).
All other dynamic modes are not inherently unstable in a fixed-wing aircraft, although your particular design may have some additional instabilities, like an unstable phugoid motion, for which you want to be able to measure and control the pitch motion.
So, the absolute minimum is two to three sensors (latitude and longitude and probably roll or yaw), and use feed-forward for all other variables (set trim and power based on desired altitude and speed, and just go for it). In practice, nobody would build an UAV with just three sensors. There are two reasons for this,
For a hobby UAV, it typically turns out that sensors are relatively cheap, thanks to MEMS. You would typically use a 3-axis accelerometer, 3-axis (roll rate) gyroscope and 3-axis magnetometer (compass), and why not have a barometer and thermometer as well? And since you use a GPS, you might as well use its altitude data. If you use a brushless DC motor, it should be no effort to measure the prop speed. I think you will find it a lot easier to make a working UAV with these off-the-shelf components (and open-source software that is typically written for these sensors) than finding a single-axis gyroscope sensor and writing your own software.
Furthermore, using more sensors significantly simplifies your observability. This is the notion of being able to infer the state of the system from the outputs. In theory, if your model is sufficiently complex, you need very few sensors to estimate the current state (dead reckoning). However, if you can actually measure your states, your model is no longer as important, and your UAV will be able to respond much better and be less sensitive to changes in the environment or the UAV itself.
The ArduPilot project has probably already done a lot of the work for you, if you're more interested in the end result than in the process of creating it for yourself. Even if you choose not to use their software, there's probably good information regarding which sensors and how many are necessary.
