Hovercraft Wing- Control
Software Real Time Operating Systems
The most likely method of software control for the hovercraft would be controlling the craft using a real time operating system (RTOS). RT OS’ are designed to work in an environment where they must take and execute commands sequentially , i.e. “in real time”. This is ideal for the nature of flight, where the time period of a command from the point they are ordered through to execution needs to be as short as possible. The nature of a RTOS is that it has been been programmed to perform only a narrow field of commands, e.g. left, right, up, down. This is acceptable for the hovercraft as it only has six degrees of mobility. A basic procedure on a RTOS has three main stages; the Running stage i s where the CPU executes the command, the Ready stage is where the command has been executed and is ready, and the Blocked stage is if the command has been executed and is ready, but is in a queue alongside other executed commands, this happens often as RTOS usually only implement one task at a time per CPU. RTOS’ are known as either “hard” or “soft” depending on the consistency of the amount of time taken between the command being accepted and then implemented by the RTOS. A “hard” RTOS uses a deterministic algorithm; a deterministic algo rithm is very consistent, taking the same time to perform a procedure every time, so it can be guaranteed to perform as predicted within the deadlines set. A “soft” RTOS can occasionally vary slightly the amount of time taken to interpret and execute a procedure; this slight delay is known as “jitter”. For the Control of a hovercraft, a “hard” RTOS would be preferred to a “soft” RTOS use so that there would be no jitter between commands and thus the control system can be relied upon. However, the code structure for a “hard” RTOS set of commands would have to be very complex, and a much more simplistic “soft” code of commands would still be reliable and consistent enough for the flight of the
hovercraft. The easiest way to show how this could be used to control the Hoverwing is by looking at how it was done for a project that had a practical element to it, therefore actual the code was written for the RTOS and used to control the flight. The above mentioned project broke down different applications of the hovercraft into different tasks within the RTOS. There was the Sonar Task which was used for activating the two sonars on the side of the hovercraft, collecting information on distances between the hovercraft and its surroundings e.g. objects that could potentially result in a collision. There was the Gyro Task, which was used to update motor parameters and PID state parameters (PID controller parameters). The Motor Task, as mentioned previously, was used to dictate the motion of the vehicle. Finally the Radio Task was for radio transmission data debugging. Here is an excerpt from the projects projects website briefly explaining the Motor Task’s
function and the RTOS code structure written for the Motor Task :
“The task will handle the hovercraft’s motion issues: lifting, forwarding, and steering. The
functionality of this task is quite independent to the other tasks. The lifting motors should always be on. The forwarding motors have a constant duty-cycle when the hovercraft is moving straight forward. When the hovercraft is going to turn, the forwarding motors should apply a “break” to
reduce the speed, so that the hovercraft can change the direction smoothly. The steering motor stays rest until the hovercraft needs to turn to another direction.” Figure 1 is an image of the RTOS code structure for the Motor Task.
Hovercraft Wing- Control
Figure 1 : RTOS Code Structure Example for Motor Control;
http://webhome.csc.uvic.ca/~mcheng/samples/qu/SENG466_Home/Phase_3/Entries/2010/4/27_RTOS.html These tasks are pre- programmed or “scheduled” in the RTOS code to plan out the desired operation of the hovercraft. Tests are carried out to calculate what timeframe should be allocated to allow each task to be undergone effectively. A number of “ticks” are assigned to each task, a tick is the unit of time used for this RTOS, it is a length of 5 ms, and each task is assigned with a number of ticks. Figure 2 is an example of the Task Scheduling in the RTOS code of this project:
Figure 2- RTOS code structure example for Task Scheduling
The number next to each task is the amount of ticks it has been assigned. Therefore, two Sonar tasks are firstly carried out, at 2 ticks each (10ms), before a Gyro Task of 3 tic ks (15ms), the motor task is then carried out over 4 ticks (20ms), as this task generally needs the most time, generally down to the mechanical nature of the task i.e. the signal has to be converted into motion on the motor of the hovercraft. Finally, the radio task takes 2 ticks to complete the cycle. The total computation time is 65ms.
Hovercraft Wing- Control
Hardware PID Controller
The previously mentioned project used a PID controller to operate its RTOS code. Proportionalintegral-derivative controllers are the most commonly used feedback controllers in industry, and would be ideal to use to operate the RTOS when flying the Hoverwing. A PID controller algorithm uses three different terms; the proportional, the integral, a nd the derivative values. These three terms all have individual outputs and the sum of these outputs is used to adjust the process. The output result is compared to an expected value that has been calc ulated beforehand during testing. This pre set value is known as the “set point”. The difference between the output and the pre
defined set point is the error, which occurs during the input. Figure 3 is a basic block diagram of the PID process.
P
Setpoint
+ _
∑
Error
I
∑
Process
Output
D
Figure 3- PID Process Block Diagram
The output of the PID controller can be defined by the following algorithm:
( ) ∫ Where U(t) is the output, K P is the Proportional Gain, Ki is the integral gain, K D is the derivative gain, e is the error (process value minus set point), and t is the time (either time elapsed or instantaneous time). The Proportional term (P) is the multiple of the error value by the Proportional Gain K P. The larger this value, the faster the output is adjusted as the Proportional Gain is defined by the speed of change in the output. The Integral term (I) is the sum of the error value over time. This gives the system the value of accumulated errors over time, that need to be adjusted, it also defines the speed of the speed of change in the output, however it is calculated according to the accumulated error as opposed to the current error. The derivative term adjusts the output by multiplying the derivative gain by the derivative of the error. This term slows down the controller’s output when it is close to the set point.
