Blogs

 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 :

https://www.youtube.com/watch?v=EbsQHrNRASs&list=UUrnWHoLed2O112VUSQ8XhxA&index=1&feature=plcp

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 :

https://www.youtube.com/watch?v=1Jp04Df8z4s

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 :

https://www.youtube.com/watch?v=mgAZF4FNwuk

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!

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.

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 .

This 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

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.

I 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.

Jason

Some photos posted by Mark Grennen:

Love this one:

Original post : http://www.diydrones.com/profiles/blogs/acm-at-the-avc

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

Hi,

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.

Marko