Drone News & Drone Directory

DIY Drones Blog

Aerial Survey in Uganda

Mark Wijnberg Land Surveyors recently completed an aerial survey of a river valley in a remote section of Western Uganda. The area is found on the Eastern slopes of the Rwenzori Mountains, close to the Congolese border. The purpose of the survey was to determine the feasibility of the construction of a hydro-power plant and its environmental and social implications. The survey area dimensions were approximately 7km by 3km and the altitude varied over 350m. Other specifications included orthoimagery, DTM of 0.25m spacing, 0.5m contours, a hydrographic survey of the river profile, installation of various benchmarks and all data represented on an AutoCAD drawing.


The terrain is very mountainous. It seemed to rain nearly every day which made climbing up steep muddy slopes exhausting. The jungle consisted of thick vines and dense vegetation. Much of the site is under cultivation of plantain, coffee and cassava. Many, if not all of the residents, had not encountered a white person before and many of the forest dwellers had never crossed the river to "civilization". There is no electricity, piped water nor sewerage for 100km.


Upon arrival in Uganda, we obtained permissions from the relevant authorities to gain access to the region. Without this permission, we were warned that if caught on this land, we would be assaulted by the army and questions asked only after we were dead! We sought council from local surveyors as to the best method of operation. Our first job was to establish a control coordinate system. As the closest markers giving a global reference system were approximately 2

00km away from the site over very rugged terrain, we decided to post process raw GPS data, collected at 10 second intervals over an 8 hour period. This task was done with a Leica GPS1200 receiver and then uploaded to Trimble RTX post processing option to derive an ITRF2008 coordinate. The results achieved were at 99% confidence level which was suitable for our survey. The coordinate system was also check against OPUS base stations over 3000km away which agreed to within a few centimeters. The orthometric levels were calculated using the EGM2008 geoid model. Once we had determined "where we were in the world", we could begin with the placing of the control benchmarks and measuring them as accurately as

 0.005m in all dimensions. The benchmarks consisted of 25 control points equally spaced over the site. These were time consuming to construct as our client insisted that they be 0.3m x 0.3m x 0.3m concrete blocks with a 0.5m iron bar inserted though the center. This necessitated us to hire local laborers to carry the 100kg of cement, aggregate and iron bars by foot though steep, slippery jungle. These benchmarks were also adopted for GCP for the aerial survey by placing whitewashed stones around the marks in a "T" fashion. A further 80 spot checks were made to check against the final product.


The client also required a survey of the river basin. The river averages 1m deep and flowed fairly fast. Over the 7km length, the total drop was 280m. These points were measured with GPS manually and we not only did a measurement of the channel depth at 15m intervals but we showed the channel sides and banks. This was a job that unfortunately the UAV could not measure as all points were under water. Areas that were densely vegetated we also surveyed manually as we needed to indicate the natural ground level. This required a lot of manual labor to cover this type of terrain. It is estimated that a total of 25km a day was walked with 1km vertically gained.


During the ground survey, a suitable site was searched for to launch and monitor the drone for the aerial survey. A school ground was found to be best suited for launch and landing. It also aligned well with the prevailing winds. It was noted that the winds blew every day from a South Easterly direction. The wind formed in strong gusts of 5 minutes followed by 20 minutes of calm. This is attributed to air rising of the Crater Lakes area rising up towards the Rwenzori Mountains. It was decided to do the survey early in the morning before the winds began. On the day of the flight, cool, calm and overcast conditions were experienced. The overcast conditions were appreciated as this reduced the contrasting effect of having strong sunlight causing shadows from elevated features. The residents of the valley were also asked to refrain from burning to reduce the smoke and haze during the proposed survey dates.


The UAV used is a 1.8m fixed wing, 2014 Skywalker frame with 2.6 APM, RFD900 long range radios, 10ah 4s battery. The camera used is a Canon S100 with an intervalometer script set to record a frame every 3 seconds. This was all kindly supplied by the gentlemen at event38.com. The flight plan was designed to accommodate a 75% sidelap and a 93% frontlap. The reasoning behind such a high sidelap was due to such large changes in elevation in the terrain. This was decided to best cover the location. The high front lap provided redundancy against those images that could not be used due to high rolling, blurring and banking shots. The total flight distance was 56km and the time taken from launch to landing was 1.3 hours. Landing was not as easy as previously thought as a large crowd had gathered shortly after the launch and refused to leave the landing strip upon the return of the UAV from its mission. The landing could best be described as "crowd surfing!"


A total of 1700 images were recorded. A few of these were discarded due to poor quality or non-vertical orientation. Despite the encountered haze, clear images were obtained. A brief overview of the images indicated that extra areas required manual survey to obtain a ground level for the clients final DTM. The images were processed using Agisoft Photoscan and then referenced using the control points previously recorded. These control marks appeared very clearly in the imagery and due to good planning, an even spread of control over the site strengthened the final image block. The maximum residual was found to be 0.03m over a 7km by 3km area. The spot checks manually measured compared very well to those reconstructed by photogrammetric means.


The final processing of the imagery to produce a 0.06m pixel orthophoto and a 0.2m DEM took an Intel i7 processor with 16GB of RAM 11 hours to render. The final image was cut into 500m x 500m blocks to reduce the images size for the client. The DEM was imported to ArcGIS. This allowed us to remove those points manually that did not fall part of the ground level and also those from the river surface. The manually surveyed GPS points were then inserted into the edited DEM and triangulated. This filled the DEM to give and smooth, seamless coverage of the site. Contours were generated to the required interval and checked against the imagery as a backdrop. The other features that formed part of the topographic survey such as dwellings, footpaths, limits of agriculture were digitized from the imagery and exported to CAD format with the contour information. From the measurements taken from the river, cross sections at certain strategic locations could be drawn as well as long sections detailing the fall over distance of the river.


In summary, this project combined both old and new worlds in terms of survey. The Ugandan surveyors that assisted us come from very challenging conditions where electricity is a luxury, and transport is dangerous if not impossible at the best of times. From comparing their typewriters to our laptops, their bicycles to our 4x4 vehicles, from their theodolite to our GPS, the usage of UAV must seem like something out of science fiction movie. The surveyors that we encountered and employed (often very well educated and experienced) were very excited by this new technology and were attracted especially by its seemingly affordability and ease of use. We estimate that this project would have taken us 0.5% of the time it would have taken to manually survey the entire region to the required detail. And even if traditional aerial survey methods were employed, it would push the cost far beyond the reaches of a simple feasibility study. The total time taken to produce the final goods has shocked our client who was expecting the final delivery to take place 3 months from the date of instruction. We managed to finish the project in 29 days. The UAV has again proved itself a very valuable and accurate weapon in the surveyor’s arsenal.

Read Full Story

An AutoPilot in the Clouds – part 1

In our RC world, autopilots are typically some kind of software/hardware combination that is physically located on the craft flying/driving/sailing etc.. This has some disadvantages since autopilots are expensive and singular, meaning that they only know them selves and have no interaction capabilities with other autopilots.

As an example, a friend once asked me what it would take to make a drone that could analyse a large field of crops taking samples of soil were the vegetation was less eager to grow. My reply was “Two drones!” - one fixed wing to fly over the field, doing a flir/nir analysis - and one copter type to fly out, land, take samples and return them.

The operation had to be coordinated somehow - so the copter would know were to land etc…

In short - some problems are not solved using one single type of drone, but rather a combination of drones with different capabilities.

In the dungeons of my cellar, pilled with winter clothes, umbrellas, broken china and old lamps, I’ve been working on a universal autopilot system, that has a central computer system that is capable of guiding several drones and coordinate their activities. The main software can be executed on a very small computer ie. a raspberry pi or similar, or a laptop. The drones run a modified version of multiwii 2.2., that sends very compact telemetry data several times each second as well as being able to receive commands from the autopilot on the ground.

The idea is to keep the autopilot on the ground (or on a mother drone), and keep track, issuing flight directions using short and efficient telemetry data between drone and main computer. Several crafts can be controlled by the software at once, making multi drone missions possible and coordinating that drones do not collide.

Each drone uses a XRF (www.ciseco.co.uk) radio module to send back telemetry as well as receive orders on direction, speed, altitude etc… The XRF modules are great, very easy to use and setup and have a range up to 1.8 miles. Most serial transceivers are however usable.  

Each drone uses a multiwii board for stabilisation and serial communication, and a gps module so the central computer knows were the drones are at all times.

The autopilot software (running on the central computer) is controlled by a state machine, meaning that a system is making sure that everything happens in the correct order. For instance, that auto land is only possible after takeoff. Or that takeoff is not possible if the preflight sequence was unsuccessful or GPS lock has not been achieved. The state machine also makes sure that transitions between states are carried out correctly - ie. going from autopilot to manual flight makes the state machine automatically pause the autopilot function and set the craft on a straight path before control is set to manual.

The system is easy to extend for different craft types as well as different hardware.

The guidance part is based on the USAV project described some decades ago (so it seems) here.

Currently I have a simple system working, with one fixed wing, called the UTV-3, based on the Z84 from Zeta Science.

I’ve implemented some simple maneuvers as auto takeoff, auto land and simple waypoint navigation. Simple stuff that I use to test the system with. Once everything is stable, I’ll be implementing the multi drone hub, needed to coordinate the works of several drones. Although I work a lot in my dungeon, I’m also lucky to live close to a field for RC enthusiasts were practical testing can be done. Videos to come.

Read Full Story

My company is producing a ground station

It Is a mini itx amd quadcore with a high bright lcd a solid state harddrive 2 front mounted usb built in 3dr radio dual video  RX with diversity video input for the onscreen HUD an additional 7" lcd with Output for your fpv googles it has 10ah of battery witch will run everything for around 3 hrs systems will be customizable and built to order here are some pictures of our prototype we are looking for feedback and suggestions

Read Full Story

Coordinated docking of copter and rover

The two robots communicate their positions, converge to a common docking location and the dock successfully, both indoors and out.

From Robohub:

The video above demonstrates the use of a coordinated control strategy for autonomous docking of a Aeryon Scout UAV onto a skid-steer UGV (Unmanned Ground Vehicle) from Clearpath Robotics. The controller handles the nonlinearities inherent in the motions of the two vehicles, and is stable in the face of multi-second time delays, allowing unreliable wifi communication to be used in the landing. Both indoor and outdoor experiments demonstrate the validity of the approach, and also reveal the major disturbance caused by the ground effect when hovering over the ground vehicle.

For more information, you can read the paper Coordinated landing of a quadrotor on a skid-steered ground vehicle in the presence of time delays (John M. Daly, Yan Ma, Steven L. Waslander, Autonomous Robots – Springer US, July 2014) or ask questions below!

Read Full Story

A Fully Automated Taranis OpenTX SAPI5 Voice Pack Generator

Hey fellow OpenTX users!

I've been procrastinating whilst writing up my thesis, at the end of finishing up a rather long Matlab script I thought wouldn't it be great to be able to use Matlab to generate and save SAPI5 voice packs for my favorite TX, the FrSky Taranis.

Starting off with an Excel spreadsheet containing a list of the text to be read, the directory structure and the file name, this was imported into Matlab 2010 x32 (yep, it is the 32bit version, I have only been able to find a x32 version of the dll required for this script to work, I simply don't have enough time to procrastinate long enough to write my own x64 version). Then set up a few variables and a small looping script to take the text, file name and directory, read out the text in your favourite voice flavour then save the files into a new folder.

The  script is as follows: 

% Set up the initial parameters

clear all;close all;

Fs   = 32000;
N     = 228;
R     = 2;
Voice = 3;
FileName = 2;
Directory = 1;
Speed = 0; %range goes from -5 to 5
Nbits = 16;

% Extract all words, file paths and file names

for R = 2:N
% the first one is a string
if R == 1
VoiceList{R-1,Voice} = cellstr(textdata(R,Voice)); % use this for cells that contain 'strings'
VoiceList{R-1,FileName} = cellstr(textdata(R,FileName)); 
VoiceList{R-1,Directory} = cellstr(textdata(R,Directory)); 
% the next 2 to 110 are numbers
if R >= 2
if R <= 110
VoiceList{R-1,Voice} = num2str(textdata{R,Voice}); % use this for cells that contain numbers
VoiceList{R-1,FileName} = num2str(textdata{R,FileName}); 
VoiceList{R-1,Directory} = num2str(textdata{R,Directory}); 
elseif R > 110
VoiceList{R-1,Voice} = num2str(textdata{R,Voice}); % use this for cells that contain numbers
VoiceList{R-1,FileName} = num2str(textdata{R,FileName}); 
VoiceList{R-1,Directory} = num2str(textdata{R,Directory}); 

%% Now to convert the text into speech and save
for Y=1:N
if Y==227
VoiceTemp = VoiceList(Y,3);
w = tts(char(VoiceTemp),'VW Kate',Speed,Fs);

currentPath = pwd; % Get the current working directory
[~,~,~] = mkdir(strcat(currentPath,'SOUNDS'),'EN'); % make a new directory to store the files in ../EN & ../EN/SYSTEM
[~,~,~] = mkdir(strcat(currentPath,'SOUNDSEN'),'SYSTEM'); % make a new directory to store the files in ../EN & ../EN/SYSTEM

currentPath = strcat(currentPath,'',VoiceList{Y,Directory},'',VoiceList{Y,FileName}); % get the full file path
SaveToHere = currentPath; % store full file path in temp variable
% Save the file
Y %counter to monitor progress


The files are available here:

TaranisVoiceData.mat                     <- The data file which contains the filenames, paths and spoken text

taranis_voiceGen.m                         <- The Matlab file (REQ x32 version of Matlab, I used R2010B) RUN THIS ONE

Taranis%20HQ%20SOUNDS.rar  <- The outputs from the script

tts.m                                                     <- The TTS conversion script (REQUIRED)

Thanks to Siyi Dend who wrote the initial TTS script used in this release.


One last thing, to get a list of all the voices that you have available on your computer system just open up Matlab, open the working directory where you have saved the files downloaded from the section above, then in the console type in:


Matlab will print out a list of all available voices on your PC. You can see in the script file I have used the 'VW Kate' SAPI5 voice pack, if you remove the 'VW Kate' and make it like this: 

w = tts(char(VoiceTemp),'',Speed,Fs);

the script will use the default terrible Microsoft Mike or Anna voice, which is rather deplorable, so jump online and Google free SAPI5 voices, there are plenty to be found. See the figure below for an example list.

So with all of that out of the way, I hope that this script may become of use to someone in the community.

Let me know if there are any bugs and I'll try to fix them when I get another opportunity to procrastinate =)

Cheers & happy flying,


Read Full Story

Page 834 of 843« First...102030...832833834835836...840...Last »