The project EasyBot is the continuation of the Flobo project,
which I suspended due to the problems with the Flobo prototype.
With the EasyBot I would like to show that the autonomous controlling of a model aircraft is possible by means of GPS only,
if the model is laid out dynamically stable.
Easybot in autumn 2007
After the tests with the autonomous vehicle Zonda had run satisfying in summer 2006,
I decided to enhance the control software for a model aircraft.
I selected the well known Easy Star as test platform, because it is a good-natured model for beginners, flies self-stable
and regains a horizontal flight attitude in most cases.
Due to the Elapor material it puts away moderate crashes without great damage.
In opposition to the construction manual the two fuselage halves of the Easy Star were screwed together with 4 nylon screws.
Additionally the fuselage was strengthened by fabric tape.
That way it was possible to re-open the fuselage and change the arrangement of the components later.
After some tests with the original engine and a 7 cell battery it turned out that the aircraft could hardly master the ballast of approx. 150 gram.
Thus the engine was replaced with a 480 from Jamara, a Graupner Cam SpeedProp propeller 5.5 x 4.3 and a 8 cell battery was used.
Finally the rudder was enlarged, in order to ensure good steering behaviour in tail wind and with engine switched off.
With these modifications the EasyBot quickly reaches a safety altitude,
where the first autonomous flight tests could be accomplished.
Placement of components
Trial and Error
After the software was extended to the additional third dimension, first test flights were made for data logging.
Then tests for autonomous heading-hold flights followed.
This meant, the aircraft simply had to maintain its speed, altitude and direction, whereby each dimension was steered with a separate PID control.
However those PID parameters were not known, so that the controls quickly began to oscillate and almost brought the model to a crash.
So I decided to test the parameters individually for each dimension i.e. to fly the aircraft partly autonomous (in the sequence: rudder, engine, elevator).
Further I noticed that the steering values affect each other mutually.
That seems logical - the elevator influences the effect of the rudder and the thrust again has influence on the climb rate.
Thus I introduced so-called mixers, which model this influence in software.
This way there are now more than 10 parameters in my config file which are to be co-ordinated.
In November 2006 I achieved the first autonomous flights over several 100 meters.
Apart from the challenges already described there are still some further problems,
which had to be eliminated or worked around:
- Reception problems: self-made electronics seem to disturb the reception of the R/C signals substantially.
The disturbances were alleviated by moving the receiver to the rear part of the fuselage - thanks to the
servo switch the servos are no longer connected to the receiver directly.
Additionally ferrite ring filters were brought into the signal line,
the antenna attached freely hanging and the engine cables shifted upward.
- Gaps in the logfile, which can not be explained with the software.
Cyclic flushing of the log file seems to make problem even worse.
The Linux console displays the message "FAT: Panic clusters badly computed",
however I don't believe the MMC card already is at the end of its life cycle.
The present solution is a regular "fdisk /dev/mmc/mmc0/disk".
After implementing a log buffering in software the problem nearly disappeared.
- An ultrasonic sensor (sonar), attached underneath the wing, is to supply exact elevation data during landing.
The SRF02 sensor I tried first proved to be unfeasible and was replaced by a SRF08.
This sensor is configurable in a way that it works reliable for a range from 0 to 3 meters.
At high altitude it sometimes supplies unreasonable measuring which can be filtered out by software.
- After about 100 test flights the 8-cell NiMH battery gave up.
I replaced it with a 2-cell LiPO with 2500 mAh.
This gives me the advantage to perform lots more test flights before I have to recharge.
- The update rate of the ublox GPS had to be reduced to 4 Hz since the module seemed to be overloaded with 5 Hz.
The load is apparently depending on the configured Platform Model which was changed from "3 - Automotive" to "5 - Airborne < 1g".
In the course of time I revised the EasyBot and attached additional sensors.
These are an anemometer (a hacked EA-3000), a rotational-speed sensor, as well as the ultrasonic sensor described already.
The control software was fundamentally revised: reading GPS data now has its own process,
the conversion of the flight plan commands was standardized and logging was improved.
The flight plan primarily consists of commands to fly straights and turns,
but it also has special commands for autonomous hand launch, target elevation and speed.
After another revision of the control software I accomplished the first autonomous aerodrome circling in August 2007
from hand launch to landing approach.
Autonomous Circling (in Google Earth)
The next task is to provide a planning layer to the navigation software.
The planning layer is for decomposition of complex navigation commands and flight patterns into track primitives.
This way several flight maneuvers like approaching a way point, patrolling a defined area or returning to the launch point
in consideration of runway direction will be implemented.
Sensors and control permitting the airplane shall do an autonomous touch down eventually.
Unfortunately the EasyBot had a severe crash in Oktober 2007 which destroyed the fuselage and servos.
However gumstix, GPS and other sensors are still alive.
It will take some time to rebuild a new fuselage and adjust control parameters for it.
Although separate PID control worked for single process variables (e.g. speed, elevation),
the system began to oscillate again in full autonomous mode.
The reason for this is probably the coupling of the control dimensions mentioned above,
but also a certain amount of delay of GPS and anemometer.
Therefore I decided for a conservative control scheme,
where elevation is primarily regulated by thrust instead of elevator.
To gain height, a preset value is added to the PID value of the speed control.
A mixer between throttle and elevator neutralizes the thrust depended downward movement.
The elevator is only used for turns and minimal speed control in climb or descent sections.
To prevent from oversteer, and thus to avoid a tailspin,
the track deviation is limited before passing to the PID control (+-10 degrees).
Although this pragmatic approach works, I try to systematize it, and hence make the source code easier to read.
See more pictures here.
The current version of the onboard software autofly can be found here.
Furthermore I provide logfiles of test flights.
Logfiles can also be viewed with my FlightViz software.
This program is downloaded by Java Webstart and therefor requires Java version 1.4 or higher.
I promise to provide a short description on the software as well as the logfile structure soon.