Featured Posts (7)

Sort by

V2 proyect

 Building and testing platform for transport and recovery sensors in sensitive area, remember, this is only a game!


This project was born from the need to provide my aircraft with a RF system
transmission autonomous to identify their location in emergency condition,
this condition must be remote and connected only failure all the systems on board.
The area where I work does not allow to rely on the GPS system,the signal of this
is not sufficient in a large area when the aircraft is grounded.
For this reason I decided to develop a low cost Beacon that allows me to
identify the exact point of transmission to more than 2km from the starting position
in the worst condition, for example the source transmission located in dense forest.
The natural history of this project required me to build a system
economical to transport this system in a point of 2km away and not accurate position.
so I decided to build a replica of the V2 missile with release system parachute
assisted with barometric system.
The platform used for transportation is a Aeroplane, the model is FunCub Multiplex.



Design and construction of the beacon system :

 The important objectives of this system is:
 1) Reliable
 2) Light
 3) Resistant to mechanical stress
 4) Significant autonomy
 5) Powerful
 6) Must not interfere with the avionics of the model


 I tested many different MCU and RF modules to minimize consumption.

 Some photos of the construction phase ...




Power system used was composed of 3 cell Li-Po with a capacity of 150 mA / h for a verified autonomy of 12 h
from the beginning of the RF transmission.

The total weight of battery unit is 12g.


Assembled battery pack.






The MCU is a PIC16F88, a microcontroller that I had in my lab.
You can use a wide variety of MCU depending on what resources
are required and available in your laboratory. The main problem is to reduce
consumption, which is essential use a proper method of programming.
In my case, the MCU is used to analyze the condition of aircraft avionic
and in case there is an emergency condition after a certain time enables the transmission of the RF module.
On board of the V2 the MCU ( Atmega ) communicates with the MCU beacon system
and generates the control signals. The unusual construction technique ensures a low weight Hardware

and a high resistance to mechanical stress. The box is constructed of a Depron multilayer material.




In the other side is located the modulated AM Aurel RF module also decided about this for low power

and wide range of supply voltage. The complete system weighs only 22g with battery and has

transmission capacity for 12h at 50mW RF power.





The complete system on the balance.






The directional antenna is derived from this project : http://www.missilistica.it/laserteam/yagi1.htm This antenna is homemade and designed originally for use with radio localization systems therefore suitable.
Is compact, robust and with proper RF band. I use a scanner ICOM as a receiver but also in this case

depends what comes in the laboratory. Certainly there are reception systems with greater sensitivity.

I consider it very convenient to use the internal system of RF attenuation and the frequency shift

when close to the source. This allows me to find the source, starting from several kilometers and approach until a few meters with correct direction.


Construction of the V2 :


The following pictures of the various phases of construction, the materials used are

balsa wood and paper to the tube of the parachute containment.

































V2 completed ready for testing on the air.












The realization of the parachute requested further study and testing to verify the falling speed calculated and the components used.


Following the graphs recorded by the logger in the first launch without using system of expulsion.

- Time Vs. Altitude


- Time Vs. Speed




The video of the first test and second test with ejection system with barometric control :




The barometric ejection system is very important to reach the ground in the shortest time possible

without drift due to wind, the falling speed is calculated 1.5mt/sec.


The section rx assembled and ready.




The full retail platform ready for mission.






The final video in the laboratory :




Day of the mission :
For the mission I identified suitable area and made several expeditions.

The target area was guarded by my two friends to prevent access by unauthorized parties. Was prepared a list of tasks and controls to be performed to leave nothing to chance!
Any problems would abort the mission!

My friends were ordered to keep clear of the area and tell me order of release

when the aircraft was flying so as to avoid any mistake on my part evaluation in an instrumental. After release and landing these were to go to a meeting area where I met after the rescue mission,
this is the only support at my mission.

Video of the Day :




Luckily I prepared a list of checks to execute before the flight!!!

Some photo of damage after the rescue mission :






I like the results of the mission, the V2 is now repaired and working perfectly!

Some photos are seen previously after repair of V2.

Thanks for your attention and sorry for my bad English!


Read more…


The project is about controlling digital cameras remotely using USB PTP commands and adding telemetry and camera feedback data to the video signal coming from the controlled camera. The main purpose is to be applied on UAV projects, otherwise, it can be used on every kind of camera remote controlling and shooting.

The hardware used here allows some nice extrapolations of the project. Let's say you could use the USB Host to attach another kind of peripheral like a video-game Bluetooth to control a rover or you could add a USB HID compliant touch-panel to a custom display to interact with OSD data and so on. It's a great DIY hardware.

You can read all the details and the history of the project by clicking here.

Welcome to the ArduCam OSD Project!

Sandro Benigno.

Read more…

In this video you can see the first flight doing with Virtual Robotix IMU , in the test i only check the sensor board , Gyro and Accelerometer , in the next test i check navy and input output functionality.


Today was a windy day , after solve with Randy a problem on the YAW control .. i doing the preflight check , all seem to work fine and so decide to going in the sky.


I'm using the same PID used with oilpan , there're not significant difference ... In the next day i try to use 300 °/s gyro ADXL 610 to check the difference respect of Inversense.

I think that the new board will be available in the next week for the people that are interest to evaluate it .



70867809?profile=RESIZE_480x480This board is an upgrade of original Oilpan board , it's compatibile at 80 % with the original dirver , my idea was to improve it and put my experience on gps and uav on it. I add some feature as subsystem power control , gps battery backup , improve temperature compensation on gyro , add gyro that i used on MP8 the same of mikrokopter.

In these days i doing small upgrade to adc driver and to the code .. i think that tomorrow i can doing a first flight for test it , On Artificial horizon yet is ok .. i need to upgrade the driver of compass .. and right projection.

My idea is to have only one board put on MP32 or APM without , cable to or header to connect the device togheter .. if you need can disconnect the sensor imu and put it where you want and can connect it by cable to navy board.

Do you like VR IMU ? This is tech info :


Preliminary VR IMU 1.0 (Dominate the Sky) Technical specification:


Imu Sensor :

  • 1 Gyro Z : Inversense ISZ500 500 °/s resolution 1 axis.
  • 1 Gyro XY : Inversense IDG500 500 °/s resolution 2 axis.
  • 3 Gyro ADXL 610 300°/s resolution same used on Mikrokopter (option).
  • 1 ACC ADXL 335 3G resolution.
  • 1 Magnetometer 3 Axis HMC5883 compass functionality.
  • 1 ADC 12 BIT ADS7844 8 channel. 2 channel used for temp compensation.
  • 1 FET for ON / OFF subsystems.
  • Possible to disconnect the Imu sensor and connect to Navi by a cable.

Navi Sensor:

  • Barometer : BMP085
  • GPS Mediatek all in one (Default) protocol MTK16 10 Hz update integrated Aerial.
  • Locosys GPS (optional).
  • UBlox GPS (optional).
  • GPS Battery Backup.
  • 1 FET for ON / OFF subsystems.

Input Output:

  • 6 12 Bit analog input available for Board Setup or for interconnect accessories.
  • 4 Digital Output
  • 3 Status Led available
  • Differential pressure sensor for air speed. ( possible to disconnect from in-out board and connect it by cable)

Product page : http://www.virtualrobotix.com/page/vr-imu-10

Best Roberto

Read more…

ACM at the AVC (Jason Diydrones)


Image: 1st Run


AVC was great fun and even though I went for broke on the last run and lost my copter, it was well worth it. I learned a lot about copter navigation. The latest code includes all of the updates, which is being tested now by Jack Dunkle.


Run 1 went really well. In turn 1 you can see the copter overshot the waypoint. Crosstrack error pulled the copter back to the desired path and kept it from being blown into the building from the high winds. The sonar altitude hold was working really well. Later the wind would pick up and make the copter go higher than sonar, which made it susceptible to an altitude hold bug. More on that later...

Each waypoint was hit perfectly, even though the copter tended to go too fast (17mph) and overshoot. At Turn 4 the copter buzzed the crowd at about 6 feet. Thankfully everyone ducked. Then the copter went to position hold for 4 seconds to settle down before going to land. Unfortunately this area was really windy and the copter was blown towards a tree. I had to abort by popping the copter up by 50 feet.


At that point I thought I would try and finish the mission by landing in Auto. Unfortunately, I had set the mission to reset on entering Auto. It began to re-fly the mission at about 100ft now. It hit turn 1, then a gust of wind grabbed it on the way to turn 2. That wind was 50MPH.


70866588?profile=RESIZE_1024x1024I was able to recover the copter this time. But the next two runs were not so lucky.




Run 2 went bad quickly. The wind shifted and lifted the copter above sonar range almost immediately. The baro alt hold bug kept it from coming back down properly. The wind above the building was gusty and blew the copter to the front of the building. Then a loose battery fell out of the copter... Because the motors were now free spinning, it auto_rotated to an upright landing from > 100 ft. The landing gear - plastic heli skids were partially broken, but it was otherwise in perfect shape. I should've taken the hint and called it a day, but run three was my last chance to finish.


Run 3:

It looked identical to run 2, except the copter kept climbing and the high winds just swept it away.



Anyway, much learned and code updated. I am trying a rate limited version of waypoint navigation. The idea is that the copter will want to travel at a certain speed towards the waypoint. This enables it to fight high winds by flying steep angles. It will also make overruns more predictable.


Once these new updates are tested, I'll open up the code to a public beta.



Some photos posted by Mark Grennen:



Love this one:

70866773?profile=RESIZE_1024x1024Original post : http://www.diydrones.com/profiles/blogs/acm-at-the-avc


Read more…

ARM based quadcopter


Here is a picture of my quadcopter in its current setup.


I just signed up for an account on this page. Roberto has asked me to write a bit about my quadcopter project and perhaps help out with some of the ChibiOS related aspects of his MP32 project. I have written about this on DIYDrones in the past, but I will try and highlight some of the main aspects here.

The hardware setup is as follows:

  • Homemade aluminium frame consisting of u-channels and a CF base plate with bent wire hangers as landing gear
  • Alpha 370 size motors (HobbyPartz), bolted directly to the frame
  • Salvaged 6dof sensor board from a Walkera XUFO 5 (4?) OR homemade sensor board made of unsoldered HobbyKing HBK401(sp?) gyros and a Sparkfun 3-axis accelerometer
  • 2-axis magnetometer (I know, 3 axes would make my life a little easier)
  • Maxbotix sonar range finder for low-altitude hold
  • Locosys LS20031 GPS or DIYDrones Mediatek GPS
  • Modified ADNS2620 optical mouse sensor for low-altitude position-hold
  • 72Mhz RC gear (Futaba TX, generic RX)
  • XBee telemetry downlink
  • Oh, yes: taped on keychain-camera for onboard video ;-)

The electronics setup consists of an ETT STM32 stamp module (Futurlec) which runs custom flight software written in C. The board contains an ARM Cortex M3 microcontroller with 64K of RAM and 512K of flash rom. The board itself runs at 3.3V, but the inputs are 5V tolerant. Here is a picture of the chaotic electronics setup:


The flight software makes use of ChibiOS for setting up the hardware and implementing multithreaded control and navigation tasks. In particular, the current version runs 4 threads concurrently:

  • A high priority thread which runs the main loop generating the attitude estimates from gyro, accelerometer and magnetometer readings and generates the PID controls. The inner loop runs at ~400Hz - this is with a 2ms sleep cycle included (i.e. it could run at most @500Hz)
  • A lower priority task which reads and parses GPS data (NMEA for the Locosys GPS, binary for the Mediatek unit) and generates high level navigational commands for the main loop
  • A lower priority task which reads serial data from my custom-built mouse-sensor optical flow detector - this also generates navigational commands for the main loop
  • A lower priority task that reads pressure data from an I2C based BMP085 barometric pressure sensor

The attitude estimation is done using quaternions and a DCM-like algorithm for drift compensation (it is not exactly DCM  - there is no cosine matrix with the quaternion approach; the underlying idea for drift compensation is similar, however). Other things that happen concurrently (in a preemptive sense) with the 4 threads above, but which are not implemented as ChibiOS threads, are:

  • Gyros, accelerometers and magnetometer are sampled via the ARM's ADC circuitry. The readings are filled into a circular buffer via DMA (this is easy to set up with ChibiOS) and averaged over in the main loop as a crude low-pass filter
  • The RC receiver pulses are read via pin-change interrupts to measure the PWM pulse lengths (I am using a bit of a hack here by reading 6 channels with only 4 pins - this relies on the fact that the pulses of most RC receivers are spaced concurrently in time, so one can infer every other pulse, e.g. number 2,  by looking at the end of, e.g. pulse 1 and the beginning of pulse 3)
  • The sonar readings are also read as PWM via a pin-change interrupt.
  • The PWM outputs for the 4 motors are hardware-generated (the ARM core can generate up to 4 independent PWM outputs per timer) - this is also set up via ChibiOS.

The way in which the 3 navigational threads communicate with the main loop thread is rather crude at the moment by setting global variables for pitch and roll of the quad. Most of this code is more of proof-of-concept quality rather than trying to make a generic code framework. The code itself is developed under Linux using a gcc cross-compiler toolchain compiled from sources. I also wrote a very simple graphical ground station software in Perl/Tk which displays a 3D model of the quadcopter and some other debugging info. The telemetry link at this point is a downlink only, in order to change anything the quadcopter has to be plugged in and a new firmware has to be uploaded.

Here is a video of the quad flying, demonstrating the position-hold capability via the mouse optical-flow sensor:


Anyways, that's all for now, let me know if you have any thoughts/questions.


Read more…
Hi ,
this is the first video of early test doing on Hexafox that using my branch of Arducopter firmware .
The hardware is MultiBoard because I'm waiting APM from Chris .. ;) Now I'm implemented Matrixtable , I2C Bl-ctr and a RPC server for sharing the sensor on Multisensor Board .

The main board control, Multipilot Board :
  • Gyro.
  • Accelerometer.
  • Radio RX.
The second board interface the sensor :
  • 4 Ir-sensor.
  • 1 Sonar.
  • 1 GPS.
  • 1 Magnetometer.
The comunication between the board using RPC protocol with binary payload and CRC control.

all the code is avaible update daily on my repository : http://code.google.com/p/lnmultipilot10/source/browse/#svn/branches/Redfox74

or on arducopter repository : http://code.google.com/p/arducopter/source/browse/#svn/branches/Redfox74

Some news and update about the status of project is on my blog here : https://diycyborg.ning.com/profiles/blogs/some-news-on-multi-pilot-amp and on this thread on Diydrones.

I need more help to set the PID ;)

In the next day I start to test GPS Hold and Sonar automatic altitude . That's function is yet implemented in the code .

Roberto (FOXTEAM ArduCopter DEVTEAM)
Read more…
A photo of successful flight as seen in Google Earth and X-plane:

This article is take from DiyDrones Post , original article Posted by Michal B on February 1, 2009 at 2:00pm
Here is another ArduPilot simulation inspired by Jordi's

My simulation requires minimum additional hardware, all you need is
ArduPilot connected by FTDI cable to PC.
Actual simulation runs in X-plane simulator. ArduPilot get simulated GPS
data over serial, and it returns back proposed servo positions back
over serial as part of telemetry info (servos can also move physically).
ArduPilot also reports bunch of variables - lat/lot/alt, next waypoint,
distance to it, etc.

What you need to repeat the simulation:
- Modified ArduPilot code from this
blog post

- X-plane 9 demo
(buy full version if you wish, but demo works just perfect, it only
ignores joystick input after 10 minutes, but we control it other way so
it really doesn't limit us)
- Google Earth
- ArduSimulator ArduSim_20090211.zip
(developed by me), which is simple application that does following:
1) Connects to ArduPilot over serial for sending/receiving data
2) Connects to X-plane on localhost (same PC)
3) Reads data from X-plane (lat/lon/alt/course), sending these to
ArduPilot as GPS sentences
4) Simulating FMA copilot stabilization on ailerons/elevator
5) Reads and displays telemetry and servo positions from ArduPilot
6) Sends servo positions to X-plane to control throttle and rudder
7) Records fly path and sends it to Google Earth to display

Here's how to repeat the simulation:
- Start X-plane, go to Menu->Settings->Net Connections, select tab
Inet 3 and enable "IP of data receiver", change IP address to
and port to 49001. It looks like this:

- Select Aircraft from folder Aircraft\Radio Control\GP_PT_60 (yes, we
want to fly RC plane which has ail/elv/rud/thr controll)
- Select airport Innsbruck
- You can open this KML path: Innsbruck.kmz
in Google Earth, which was my testing fly plan configured in ArduPilot;
this will show you the waypoints
- upload compiled ArduPilot code to the board and leave it running; LOCK
LED should keep flashing
- start ArduSim.exe (simulator tool); it will connect to serial port and
X-plane; if it can't connect to serial, specify correct port and
baudrate and press Start button
- click [Google Earth] button in ArduSim to make connection with GE
- hit B in X-plane to release brakes, and try keys A/W/C to choose
various views
Now simulation should be running if everything is connected
successfully, and you should see plane in X-plane to fly and
visualization path & icon in Google Earth to move. Don't control
plane in X-plane! ArduPilot will take-off and fly on its own.

Here's video how it all looks in action:

And complete flight path visualization for Google Earth: Flight.kmz
You can see original waypoints in white, and real fly path in yellow.
And also final circulation over start point when all waypoints were

Now about problems and future tasks:
- I have strong impression that controlling altitude by throttle with
use of copilot stabilization doesn't work properly, this simulation
showed me that plane didn't want to drop altitude from high point to
lower one... see results in above flight path in GE. I'm not sure how
real plane behaves (didn't went out to real world with this yet), we'll
- For this reason I plan to start playing with complete stabilization in
ArduPilot, and controlling both elevator+throttle to get desired
- You can play with dozen of various parameters to control behavior,
most obvious are PID settings for throttle/rudder in ArduPilot, but also
PID values in stabilization (which is here provided by simulator tool,
in real world it is FMA Copilot which you can control by its sensitivity
setting). Then you can change maximal servo rotation for ArduPilot to
work with. All these values make the plane fly smoother, make more
precise turns, etc etc. And the settings seem to depend on actual
aircraft and its physical behavior. So there won't be single settings
working for everyone.
- It's somehow cumbersome to specify different altitude for various
waypoints; while I converted waypoints from KML file out of Google
Earth, I had to specify individual altitudes manually in waypoints.h
file in ArduPilot code.

After all, I'm pretty happy to see the plane flying in simulator and
doing the task! Note that it's ArduPilot doing the navigation work. And
in a real airplane, this simulation allows to reuse the ArduSim
application as a base station, getting telemetry from plane over Xbee
and displaying what it does as well as showing path in Google
Read more…

Blog Topics by Tags

Monthly Archives