Blogs

By Gary Mortimer

The EU continues to look forward and rapidly advance UA civilian integration, are you watching FAA?? A completely different narrative to what is currently happening in the New World (well the bit between Canada and Mexico)

View the ebook here http://ec.europa.eu/enterprise/flipbook/rpas/?goback=%2Egde_941207_member_238344699#/1/

The development of Remotely Piloted Aircraft Systems (RPAS) has opened a promising new chapter in the history of aerospace. Military exploitation of UAS has grown significantly in the recent years. However this trend has so far not been followed by the civil sector.

RPAS can offer a wide range of civil applications for the benefit of European citizens and businesses. Being remotely piloted, RPA can perform tasks that manned systems cannot perform, either for safety or for economic reasons.

RPAS are well suited for long duration monitoring tasks or risky flights into ash clouds. They can efficiently complement existing manned aircraft or satellites infrastructure used by governments in crisis management, border control or fire fighting. RPAS can also deliver profitable commercial aerial services in various areas, such as in precision agriculture and fisheries, power or gas line monitoring, infrastructure inspection, communications and broadcast services, wireless communication relay and satellite augmentation systems, natural resources monitoring, media and entertainment, digital mapping, land and wildlife management, air quality control and management.

A broad consultation on the future of civil RPAS applications in Europe

In order to examine the economic impact of this emerging technology and identify the obstacles to the development of civil RPAS applications, the European Commission conducted a broad stakeholders’ consultation. Between 2009 and 2012, three major initiatives have been launched, allowing an extensive exchange of views with the RPAS Community.

In 2009, DG Mobility and Transport conducted a Hearing on Light Unmanned Aircrafts, while in 2010 it organized together with the European Defense Agency a High-Level conference on Unmanned Aircraft Systems . The hearing report [785 KB] and the conclusions of the High Level conference [17 KB] confirmed the enormous potential of RPAS technology and the necessity for action in EU level.

Taking action in defining the way forward, DG Enterprise and DG Mobility and Transport conducted, from June 2011 to February 2012, an extensive consultation on the future of RPAS through 5 workshops, titled the UAS Panel Process (see all presentations and written contributions).

The Staff Working Document “Towards a European strategy for the development of civil applications of Remotely Piloted Aircraft Systems (RPAS) ” (SWD(2012)259) published in September 2012, reports the outcomes of this consultation. Main conclusions were:

• RPAS present an important potential for the development of innovative civil applications (commercial, corporate and governmental) in a wide variety of sectors to the benefit of European society by creating jobs and achieving useful tasks.
• To unleash this potential the first priority is to achieve a safe integration of RPAS into the European air system as soon as possible.
• This requires the development of appropriate technologies and the implementation of the necessary aviation regulation at EU and national levels. Issues like privacy and data protection or insurance must also be addressed.
• It also requires an increased coordination between all relevant actors (EASA, national Civil Aviation Authorities, EURCAE, Eurocontrol, JARUS, industry etc.) and between regulatory and technological developments.

Given the urgency to achieve RPAS safe integration into the civil airspace in view of the potential economic and social benefits of such applications, the UAS Panel called upon the European Commission to take the lead in the development of a Roadmap for safe RPAS integration into European Air System (RPAS Roadmap).

A Roadmap for the safe integration of RPAS into civil airspace

Following this call, DG Enterprise and DG Mobility and Transport steered the preparation and the implementation of the proposed Roadmap.

The RPAS Roadmap will provide a strategy for achieving RPAS integration into the European air system from 2016. It will identify the actions needed to ensure the development by the European Aviation Safety Agency (EASA) of the regulation necessary for large RPA (> 150kg) and support the development of harmonized regulation for light RPA (< 150 kg) by national Civil Aviation Authorities. It will provide a research agenda defining the required technology developments and propose measures to address the societal impact of RPAS (privacy/data protection, insurance etc.). The Roadmap will include a rolling plan that will span over 15 years.

DG Enterprise and DG Transport are currently preparing the RPAS Roadmap with the support of 3 temporary Working Groups gathering the necessary expertise around the 3 main areas covered by the Roadmap: aviation regulation, technology and societal impact.

In order to support the implementation of the Roadmap, the European Commission has set-up a European RPAS Steering Group (ERSG) gathering the organizations contributing to achieve the tasks defined in the Roadmap. The Group will endorse the Roadmap, report the progress achieved on a yearly basis and update the Roadmap when necessary. The following bodies are currently members of the Steering Group: EC, EASA, EUROCONTROL, ECAC, EUROCAE, SESAR JU, JARUS, EDA, ESA, ASD and UVSI. The composition of the Group may evolve according to the needs.

The European Commission intends to submit the first issue of the Roadmap to the European RPAS Steering Group for endorsement in spring 2013.

UAS Database

In order to facilitate the gathering and the consolidation of existing information and increase the transparency of on-going activities, DG Enterprise and Industry has set-up a public database on UAS accessible through theCIRCABC interest group on UAS (To access the documents uploaded to this group, please click on “Library” on the left-hand menu. No login or registration is required). Stakeholders are invited to contribute building-up the database. Any relevant public information can be sent to entr-uas@ec.europa.eu.

For further questions, please contact: entr-uas@ec.europa.eu.

After my quad flew itself into the side of my workshop and destroying itself, I decided to go with a hex after having bearing issues with my motors and having a motor lock up in flight. With a hex at least I have a bit more redundancy. My design I am hoping will look quite rugged and enclosed as the Colorado dust gets into everything at a low altitude. So I began the design with the main frame plates and I will go from there as they are the "backbone" to the platform. Here are a couple of pictures of them being machined on my CNC mill. I also have a 3-d printer and use it's prints for castings, I am thinking of printing a pattern for the outriggers to cast in aluminum, I have to weigh in the weight cost though.

I was getting lots of vibrations from my Hextronik DT750 even after balancing it and using balanced props. I replaced the bearings and now the motors are like new! 

The steps for DT700 and DT850 are similar

To remove the C-Clip, it would be easier if you use a snap-ring plier (unfortunatelly i don't have one hhehehe)

http://blogs.ottawacitizen.com/2013/05/05/canadian-uav-competition-tests-ability-to-locate-forest-fires/

News release from the organizers:

Alma, QC – May 3-5, 2013 – Ten university student teams from across Canada competed in the Operational Phase of the 5^thUnmanned Systems Canada UAV Student Competition hosted by Ville d’Alma at the Centre d’excellence sur les drones (UAS CE). The teams were challenged to use unmanned air vehicles (UAVs) in support of forest fire fighting.  They were tasked with automatically locating targets that would represent points of interest in an actual forest fire fighting scenario in the remote Canadian wilderness, using their own experimental unmanned aircraft flying under the control of autopilots.

Winning Teams:

Phase 1 Design Phase

1^stPlace          Team COBRA, University of New Brunswick

2^ndPlace          UTA Team, University of Toronto

3^rdPlace          Team VAMUdeS, Université de Sherbrooke

Phase 2 Operational Phase

1^stPlace          Team VAMUdeS, Université de Sherbrooke

2^ndPlace          UTA Team, University of Toronto

3^rd  Place         Team COBRA, University of New Brunswick

All teams who participated in the operational phase of the competition received a cash award; overall $12,000.00 of prize money was awarded to the teams.

“It’s incredibly satisfying to see the rapid growth in capability that these teams bring to our annual competition,” said Eric Edwards, Chairman of Unmanned Systems Canada.  “We provide a safe environment where the students can fully exercise their technical creativity, and the results are just stunning.  They are self-motivated, and they are the best of the best from their respective faculties.  The corporate sponsors of this event thoroughly enjoyed meeting each of them and seeing their potential future employees at the top of their game, under a bit of competitive stress and dealing with real-life complications.”

Participating Teams:

University of New Brunswick – Team Cobra

Université de Sherbrooke – Team VAMUdeS

École Polytechnique Montréal – Team Smartbird

École de Technologie Supérieure (ÉTS) – Team Dronolab

Université du Québec à Chicoutimi – Team UQAC

University of Alberta – Team UAARG

University of Toronto – UTA Team

University of British Columbia – Team Thunderbird

Simon Fraser University – Team GUARDIAN

Carleton University – Team Blackbird

Unmanned Systems Canada – Systèmes télécommandés Canada (USC-STC) is the not-for-profit association representing the interests of the Canadian unmanned systems sector – industry, academia, government, military, and other interested persons. It provides a single voice for advocacy and representation to government and international bodies, and jointly leads Canada’s regulatory development efforts for UVS. The organization promotes and facilitates the growth of the Canadian unmanned vehicle systems community through education, engagement of new market sectors, and exchange of ideas and technologies.

The Unmanned Aerial System Center of Excellence is a non-profit organization whose mission is to develop an international center of expertise and innovations focused on the development, applications and operations of UAS. Services are available to both private and public companies. The UASCE collaborates withTransport Canada towards the integration of unmanned aerial vehicles in the Canadian airspace. UAV flights have been conducted since March 2012 in the Alma region and the future looks promising for the Centre.

Disclaimer:- DIYDRONES does not advocate or condone any RC flights beyond LOS or above 400'AGL. Do not try this. This APM assisted FPV was supposedly attempted in Russia. Such Flights may be illegal in many parts of the  world. Members/ Diy UAV enthusiasts are advised to check with local regulations/authorities for required permits & comply. DiyDrones bears no responsibility for such action.

Link

Prototype of the compact UAV on the basis of popular model of the radio-controlled EasyStar plane

Basic characteristics of a glider:

initial look:

Material ELAPOR
Wingspan: 137 cm / 2400 quarter sm.
Loading: 3,28 kg/sq.m
Fuselage length: 86,3 cm
Weight: 680 g

Changes are made to a plane design:

Ailerons are cut through
The rudder is increased by 100%
the tail beam (3 carbonic rods 1мм at sides and a bottom) is reinforced
wings are straightened t and in this position are reinforced by three bars everyone
the niche in a tail beam under the 7-inch screw is cut out
servo are mounted near surfaces

motor 250w 2200KV
esc turnigy plush 30A
APC 7*5

This configuration  gives near 1kg pool (static measurement) that allows to provide reliable take-off.

Autopilot:

APM 2.5 flight controller
GPS external mediatek 3329 speed of updating of data 10Hz
Voltage sensor
The separate UBEC power supply for avionics

FPV equipment:

720 lines camera  with high sensitivity
Video the transmitter 5,8GHz 200mw
video receiver 5,8GHz
FatShark video glasses

Battery:

Zippy Flymax 3S 5000ma  (external  on the bottom of a fuselage)

Russian style hummer-drones laboratory

motor and esc

elevator servo and rudder size

rc receiver and self-made apm2

foam door to communication box

camera and battery

A multirotor flight is very critical: if it happens an ESC, motor, propeller, RX failure or even if you get a lot of vibrations in the flight controller, the multirotor will crash. That's why I created a parachute and attached it to the quadcopter. This was the first test I've done with a parachute for quadcopter:

It had a stick so it kept the parachute away from the propellers. The problem is that the CG is difficult to keep in the center of the quadcopter and also because if the quadcopter hits the stick on the ground when it lands it's going to break the stick.

Therefore, I positioned the parachute on the back of the quadcopter without a stick. I've done a "wind tunnel" test (lol ;D) to check if the parachute would open:

As you can see, it seems to work, so I tried it in field:

Although it didn't land well, nothing was broken because the quadcopter arms are foldable and the ground was soft (grass).

The parachute is activated with a receiver channel and a servo. So when I get in trouble I press a button in my transmitter and it will release the parachute.

Currently i'm projecting a parachute launcher with springs, so it will  be launch vertically and thus it will open faster. Another option would be using a small rocket/gunpowder to pull the parachute, but i'm still thinking on the positioning to avoid unwanted burn to the parachute and the multirotor

Cheers!

With a brushless motor and a TRex tail rotor mechanism I could assemble a simple variable pitch system. I measured and it generates 700g with the TRex 500 tail rotor blades.

I tried the Trex 250 blades from the main rotor but although they are longer the thrust is smaller, just 400g. This is probably because the motor doesn't have enough torque.

This could be used for a variable pitch quadcopter or with an airplane.

Specs:
Motor: Hextronik DT750
ESC: Plush 25A
Battery: Turnigy 2200mah 25C
Tail rotor: HK-500GT
Wood to support the tail mechanism: 38mm tall

The new APMcopter Wiki is up and running!

As you probably know, some of us have been hard at work trying to bring up a new Wiki for the copters, planes and rovers.

I have recently completed installing the vast majority of the pages from the Old ArduCopter Wiki into the new APMcopter Wiki/Manual.

And I have produced a Drop Down Menu as well as a Hyperlinked Table Of Contents (that is accessible from the top of each Wiki page).

Please look over the new APMcopter wiki here: http://copter.ardupilot.com/wiki/arducopter/

And provide feedback.

There is still some work to do repairing broken hyperlinks (they do not import correctly from WordPress and the images all need to be moved to the WordPress repository), but I am slogging through all 109 Wiki pages fixing them and performing minor reformatting.

There is an issue that I would really like you all to look at carefully.

Right now, I have constructed a Drop Down menu and Table of Contents that completely mirror each other and I think they work effectively together.

However, it is 3DR's intention to minimize or eliminate the Wikis Drop Down Menu at the very least removing the vast majority of links so that it will work better with tablets and to support their own vision of what is in the best interests of themselves and the community.

They envision a very short set of quick starts designed to get uninitiated users up and running as quickly as possible.

And while I think that is a very worthwhile pursuit, I do not think that it is appropriate to do it by applying the scarce drop down menu resource to that endeavor and removing it from the full Wiki.

I think that the current full Drop Down Menu and Table Of Contents work very well together and are an asset to our community.

Please look this over with special regard to the Drop Down Menu and the Table of Contents and Weigh in here, it may be your best chance to influence the final form of our Wiki/Manuals.

Of course, I invite 3DR to respond here as well.

This is an open community that has benefited greatly and grown considerably in no small part due to massive support from Chris and 3DR.

I'm not trying to cause a problem here, but this is a time where our feedback is really important.

3DR's Presidente meets with President Obama.

I tested the Return to Home function of the Multiwii board using the default parameters. I didn't change the P, I or D of the gyros, acc, mag or any other sensor.

As you can see, the flight is not perfect since it's not tuned and it was windy but the tricopter returns to the inital position indeed. Usually RTH is activated when the signal from the TX is lost (multirotor out of control), it's a great funcionality.

Flight controller used: Crius AIO Pro
GPS: CN-06 v2

Simplicity, ease of use, and robust capability are the three main features UAVs need to become the future. The DIY community here knows the many complex problems, software and hardware, that continually need to be solved to operate a UAV. Two distinct markets are present in the UAV industry, defense and civilian. Products in both these markets share the same problems. Current solutions are difficult to use, require extensive training and technical maintenance, and are laughable in price. 

Why don't we build a system anyone can use, for a reasonable cost that can address the needs of both the defense and civilian markets?

Bird Aerospace LLC is a small company (3 people) founded on that idea. We are currently working to build a small canister launched UAV for use in both defense and civilian markets.  Key features of the system include:

• Simplicity- While existing small-scale UAVs require time-consuming assembly, Bird’s Eye arrives in 100% ready-to-fly condition. A single button activates the launch sequence and puts the system in the air, directly from the shipping container.
• Durability- Housed in a 1ft diameter, 2ft long carbon fiber tube, the system is protected from harsh military and industrial environments until the moment it is safely airborne.
• Versatility- Existing drone systems require cumbersome pneumatic launch ramps and large open areas for takeoff. Bird’s Eye needs only a clear path to the sky. This allows for deployment in dense forests, crowded urban environments, from moving vehicles, and other locations that are currently inaccessible to UAVs.
• Speed- With a setup and deployment time of less than thirty seconds and a top speed of 120mph, Bird’s Eye is on the scene faster than any other small UAV to date.
• Maneuverability- Aggressive control surfaces and a sleek airframe allow for tight turns and evasive action – a necessity for precise high-speed navigation and swarm combat applications.
• Capability- With a fully customizable sensor payload, Bird’s Eye can be tailored to the specific needs of the client.

I am reaching out to the community here for a few reasons. One I think that DIY Drones is a great resource full of some very smart people. As we try and establish our company advice from more experienced people has been invaluable. We are looking for help both in man power and financing. If you are interested in either PM me or reach me at trevor@birduas.com

Thanks for looking!

This is the wing condor 78 "equipped with autopilot APM 2.5 and  firmware 2.72 with take off weight of 10.3 lbs.

2.72 firmware improvements are very good at navigation, I have tested the x5 and the condor with excellent results, thanks to the development team for this development.

For more information visit

http://www.makedrones.com

My TMR-FC Flight Controller

- Frame 

- Controller

- Introductions

    1. User Guide :

        TMR_FC_UM_V1_120730.pdf

    2. Sechematic :

        TMR_FC_HW_V1_120830.pdf

    3. Gerber :

        TMRFC_GB_V1_120930.rar

    4. Software :

         The software is Porting from "PX4".

         https://github.com/cctsao1008/TMR

- Hardware Features

    1. MCU : 

          STM32f405RG

    2. AHRS :

          MPU6050, HMC5883, MS5611

    3. Features :

          12 channels PWM output, one PPM input and one Futaba S.BUS input,

          Built-in 10 DOF, 5 LEDs ( controlled by PCA9533/9536), GPS port ( UART / I2C),

          Auxiliary SPI and  GPIO, RF port (APC230 or BT), LiPo Voltage measure via ADC,

          Beeper for tone alarm, SWD port, SONAR, USB VCP and MSC, Micro SD ( can be read via USB),

          Light Bar LED control, Internal FLASH EEPROM emulation using sector 1, 2 and 3 ( 16KB x 3 ),

          RTC ( power keep by 3V CR1220 )

          ....... etc

    4. Stress Test VB scripts :

          Auto re-boot loop test, tone alarm loop test, ..... etc

    5. Support PX4 Qupgrade tool :

- Tests :

---------------------------------------

- Boot Log :

---------------------------------------

reboot
ABCDF
nsh_romfsetc: nsh > romfs_img_len 0xFF52F09C 
nsh_romfsetc: nsh > Mounting ROMFS filesystem at target=/etc with source=/dev/ram0
[boot] Initializing (HRT) 1...
[boot] Initializing (CPU) 2...
[boot] Initializing (DMA) 3...
[boot] Initializing pca953x driver
[PCA953X] on I2C bus 2 at 0x62
[TMRFC_LED] led_off, led = 0x338 
[TMRFC_LED] led_off, led = 0x332 
[TMRFC_LED] led_on, led = 0x334 
[boot] Initializing soft SPI for the MMC/SD slot
[boot] Successfully initialized soft SPI for the MMC/SD slot
[boot] Binding soft SPI device to MMC/SD slot 0
[boot] Successfuly bound Soft SPI device to MMC/SD slot 0
[boot] Initializing SPI3
[init] MODE = autostart 
[init] Looking for microSD... 
[init] Card mounted at /fs/microsd 
[init] tone_alarm start 
[init] Reading /fs/microsd/etc/rc.txt 
Detecting on board sensors on I2C bus(I2C2) ......

( 0x62 ) Have PCA9533DP
( 0x41 ) Have PCA9536DP
( 0x69 ) Have MPU6050

  Set MPU6050 auxiliary I2C bus to bypass mode......

  Detecting sensors on MPU6050 auxiliary I2C bus......

  ( 0x1e ) Have HMC5883L
  ( 0x77 ) Have MS5611

i2c: Done

[init] Start the ORB 
[uorb] ready
ramtron: RAMTRON not enabled, skipping.
param: selected parameter default file /fs/microsd/params
[init] param load /fs/microsd/params 
param: end of parameters
[init] Start mavlink ( 57600  /dev/ttyS1 ) 
mavlink: MAVLink v1.0 serial interface starting...
mavlink: DOWNLINK MODE
mavlink: UART is /dev/ttyS1, baudrate is 57600

[init] Start commander 
commander: starting
commander: No RGB LED found
[fcservo] default PWM output device
<fcservo> MODE_NONE
[fcservo] starting
<fcservo> adjusted actuator update interval to 100ms
FC driver (no PWM) started 
[init] Start sensors >> need to implement 
[init] Start one of the estimators ( attitude_estimator_ekf ) >> wait for MPU6050 driver ready !! 
[init] Start GPS >> need to implement 

NuttShell (NSH)
nsh> eeprom test
---------------------------------------------------------------------------------------
RM0090 Table 5. Flash module organization (STM32F40x and STM32F41x)            
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x08000000, SE = 0x08003FFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (986):Check_Sector_Erased 0  (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x08004000, SE = 0x08007FFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (988):Check_Sector_Erased 1  (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x08008000, SE = 0x0800BFFF, COUNT = 0x00004000  
[DEBUG]internal_flash_test (990):Check_Sector_Erased 2  (ERASED)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x0800C000, SE = 0x0800FFFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (992):Check_Sector_Erased 3  (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x08010000, SE = 0x0801FFFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (994):Check_Sector_Erased 4  (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x08020000, SE = 0x0803FFFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (996):Check_Sector_Erased 5  (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x08040000, SE = 0x0805FFFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (998):Check_Sector_Erased 6  (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x08060000, SE = 0x0807FFFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (1000):Check_Sector_Erased 7  (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x08080000, SE = 0x0809FFFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (1002):Check_Sector_Erased 8  (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x080A0000, SE = 0x080BFFFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (1004):Check_Sector_Erased 9  (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x080C0000, SE = 0x080DFFFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (1006):Check_Sector_Erased 10 (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]Check_Sector_Erased (845):SS = 0x080E0000, SE = 0x080FFFFF, COUNT = 0x00000001  
[DEBUG]internal_flash_test (1008):Check_Sector_Erased 11 (DATA)     
---------------------------------------------------------------------------------------
[DEBUG]internal_flash_test (1011):Warning !! This test will destroy the data stored on sector 1 and 2 ! 
[DEBUG]internal_flash_test (1014):1)sched_lock.... 
[DEBUG]internal_flash_test (1018):2)FLASH_Unlock.... 
[DEBUG]internal_flash_test (1022):3)EE_Init.... 
[DEBUG]EE_Init (146):EE_Init 
[DEBUG]EE_Init (330):EE_Init >> VALID_PAGE 
[DEBUG]EE_Init (345):EE_Init >> ERASED 
[DEBUG]EE_Init (347):EE_Init >> FLASH_EraseSector 1 
[DEBUG]Check_Sector_Erased (845):SS = 0x08008000, SE = 0x0800BFFF, COUNT = 0x00004000  
[DEBUG]EE_Init (355):Page 1 blank, skip to erase it. 
[DEBUG]internal_flash_test (1025):4)FLASH_Lock.... 
[DEBUG]internal_flash_test (1029):5)sched_unlock.... 
nsh>

---------------------------------------

-log for DJI F450 :

---------------------------------------

ABCDF
nsh_romfsetc: nsh > romfs_img_len 0x80B7DC8
nsh_romfsetc: nsh > Mounting ROMFS filesystem at target=/etc with source=/dev/ram0
[boot] Initializing HRT Callout Interface
[boot] Initializing CPU Load Estimation
[boot] Initializing Serial DMA
[boot] Initializing PCA9533 and PCA9536
[PCA953X] on I2C bus 2 at 0x62
[TMRFC_LED] led_off, led = 0x338
[TMRFC_LED] led_off, led = 0x332
[TMRFC_LED] led_on, led = 0x334
[boot] Initializing soft SPI for the MMC/SD slot
[boot] Successfully initialized soft SPI for the MMC/SD slot
[boot] Binding soft SPI device to MMC/SD slot 0
[boot] Successfuly bound Soft SPI device to MMC/SD slot 0
[boot] Initializing SPI3
[init] MODE = autostart
[init] Looking for microSD...
[init] Card mounted at /fs/microsd
[init] tone_alarm start
[init] Reading /fs/microsd/etc/rc.txt
sercon: Registering CDC/ACM serial driver
uart_register: Registering /dev/ttyACM0
sercon: Successfully registered the CDC/ACM serial driver
[init] eeprom
eeprom: mounted EEPROM at /eeprom
param: end of parameters
sercon:: ERROR: Already connected
[init] Start the ORB
[uorb] ready
param: selected parameter default file /fs/microsd/params
[init] param load /fs/microsd/params
param: end of parameters
Try to get an USB console
nshterm [12:100]
11: + SYS_AUTOSTART: equal
Load .. 11_dji_f450
[init] TMRFC v1 on DJI F450
MAV_TYPE: curr: 1 -> new: 2
nsh: px4io: command not found
mavlink: MAVLink v1.0 serial interface starting...
mavlink: DOWNLINK MODE
mavlink: UART is /dev/ttyS2, baudrate is 57600

[fcservo] default PWM output device
<fcservo> MODE_12PWM
<fcservo> set_pwm_rate 0 50 50
[fcservo] starting
<fcservo> adjusted actuator update interval to 20ms
<fcservo> MIXERIOCRESET

<fcservo> MIXERIOCLOADBUF

<fcservo> new MixerGroup

<fcservo> set_pwm_rate 0 50 400
<fcservo> set_pwm_rate fff 50 400
<fcservo> adjusted actuator update interval to 2ms
[uorb] already loaded
uORB started
ADC
<adc> init done
[MPU6050] on I2C bus 2 at 0x69
[MPU6050] Ready.
[HMC5883] on I2C bus 2 at 0x1e
[HMC5883] Ready.
[MS5611_I2C] on I2C bus 2 at 0x77
[MS5611] Ready.
[sensors] Initializing..
sensors_task: using system accel
sensors_task: using system gyro
sensors_task: mag cal status changed
preflight_check [38:100]
commander: starting
commander: No RGB LED found
sdlog2: logging to directory: /fs/microsd/sess003
sdlog2: log buffer size: 16384 bytes.
[gps] starting
[gps] failed to open serial port: /dev/ttyS3 err: 2
Extended Kalman Filter Attitude Estimator initialized..

position_estimator_inav: started.
multirotor_att_control: starting
multirotor_pos_control: start
multirotor_pos_control: started
sdlog2: start logging.
sdlog2_writer: logging to: /fs/microsd/sess003/log001.bin.
position_estimator_inav: init baro: alt = 45.242
position_estimator_inav: main loop started.

From GizMag (hawk attack is at 1:50 in the above video):

Researchers from the University of Maryland have built a new micro air vehicle dubbed Robo Raven that's such a convincing flyer, it's been attacked by a local hawk during testing. Though numerous other robotic birds have successfully taken to the skies in recent years, including Festo's visually stunning SmartBird, this featherless mechanical marvel is capable of impressive complex aerobatic maneuvers thanks to completely programmable wings that can flap independently of each other.

Dr. Satyandra K Gupta says that if eight years of building experimental robot flappers has taught him anything, it's that "designing and building robotic birds is hard, despite the apparent simplicity of the idea – flap wings to generate thrust to propel forward and use the moving air to generate lift to stay afloat."

The professor of mechanical engineering at the University of Maryland's A. James Clark School of Engineering had his first flight success in 2007, in collaboration with faculty colleague Dr. Hugh Bruck and a team of students. Three more models were built in the years that followed, including one called Big Bird that had jointed wings. The last one carried a video camera to document its flight and was launched from a modified ARL Lynchbot ground vehicle. It was robust enough to fly in winds up to 10 mph (16 km/h).

A lack of simulation tools meant that the researchers had to rely on trial and error testing, and what looked promising on paper didn't always make for a good flyer. Design flaws came at a high price and often ended in catastrophic crashes, with team members literally having to pick up the pieces and start again. Even successes brought their own problems to the table, in the shape of a local hawk that felt convinced enough (or at least threatened enough) to attack the robotic birds while they were in the air, and tear them to shreds.

Though Gupta and Bruck were able to build machines that could fly, only simple flapping motions were achieved due to both wings being driven by a single motor. An attempt to recreate the kind of precision wing control that makes their real-world feathered cousins such compelling viewing for everyone from curious children to dedicated twitchers was not successful, and the project was shelved.

This time last year, the researchers decided to try again. As the end of April 2013 approached, students Eli Barnett, John Gerdes, Johannes Kempny, Ariel Perez-Rosado, and Luke Roberts made a breakthrough.

Robo Raven uses two programmable actuators that can be electronically synchronized to coordinate motion between the two wings. The new design required more power to operate, though, and a microcontroller had to be added. This resulted in a heavier bird, and one that proved too weighty for flight. The design team laser cut and 3D printed lightweight polymer components in an effort to get weight down, but it was still not light enough. The answer was threefold.

First, numerous motion profiles were created so that the wings always achieved an optimal lift and thrust balance. Then a method of measuring aerodynamic forces during the flapping cycle was developed that allowed for rapid evaluation of various wing designs, before finally selecting the best fit for the job. Lastly, the system was optimized to make sure that everything worked together as efficiently as possible.

As well as sporting wings that can beat independently of each other, Robo Raven can be programmed with any number of motion patterns, allowing it to perform impressive aerobatics like back flips, dives and rolls, and breathtaking turns.

In fact, the robotic bird proved so realistic that not only did it get attacked by a territorial hawk (at 1:49 in the video below), but other birds began to follow as it motored round the test site.

Gupta says that much study and many developments lie ahead, and he hopes Robo Raven will inspire others to choose robotic bird creation as their hobby.

By Gary Mortimer

OppiKoppi beer drone technology v1.1: This is the sort of ordnance drones should really deliver all over the world.
More updates to follow, but you will be able to order beers from your phone to the District 9 campsite in 2013.
At the moment it is hand guided, but it will eventually fly on a gps grid. We will send word.

Music by The Black Cat Bones: Ol’ Pappa Joe

Concept by Oppikoppi/Hilltop Live – info@Hilltoplive.co.za

Besides the issues of dropping nothing without approval from an aircraft other than water or finely divided sand and the flight over crowds… The folks at Darkwing Aerials have created a video that’s going viral. The folks at Oppikoppi must be very happy with the press they are getting.

I recently acquired some new prop adapters from 3DR. see http://store.3drobotics.com/products/propeller-fastener-and-shaft-kit-for-blue-moto-1 

They require you to replace the motor drive shaft which is simple but not uncomplicated task. To help anybody who wants to do the same I have created an Instructable (see http://www.instructables.com/id/How-to-change-the-drive-shaft-on-your-Quadcopter-R/ ) with the use of minimal tools.

I look forward to comments on how I can improve it.

Thanks :-)

Here is a short video presentation of my Skywalker X8 UAV using 3g broadband internet for video and telemetry.

Onboard my X8 i have this ZTE MF60 3g/Wifi router which handles the communication for the APM2.5 and the Raspberry Pi model B. I didn't wanna use the Dronecell because i will place the load away from the APM2.5. I could have put a 3g USB adapter in my Raspberry Pi as well, but the Pi have more than enough to do transcoding the video-stream, so i use a Cisco Wifi USB adapter in my Pi to communicate with the 3g router and GCS.

The telemetry from my APM2.5 is sent to a Serial 2 Wifi converter which then is connected via Wifi to the 3g router. I then connect to my APM2.5 using TCP from Mission Planner.

The Raspberry Pi are using VLC Player for Linux to transcode the videostream from the Microsoft Lifecam webcamera to a resolution of 352x288 at 500kbit/s and 10 fps. If you want to use the same solution just change the hostname and port to you needs in the command below. I use Dynamic DNS (client configured in my Raspbery Pi) since mye 3g router gets a dynamic IP adress on every new connection.

Command in the Pi for starting videostream:

"sudo -u pi vlc-wrapper -I dummy -vvv v4l2:///dev/video0 :v4l2-width=352 :v4l2-height=288 :v4l2-fps=10 :sout='#transcode{vcodec=MJPG,vb=500,fps=10,scale=1,width=352,height=288,acodec=none}:std{mux=ts,access=udp{ttl=10},dst=mydyndnshostname.domain.no:2000}' :sout-all :sout-keep"

At my GCS i start VLC using this command in a .CMD file to recieve the video from the X8 and re-stream it to the Mission Planner:

"C:\Program Files (x86)\VideoLAN\VLC\vlc.exe" udp://@226.0.1.150:2000 --sout=#transcode{vcodec=MJPG,vb=500,fps=10,scale=1,width=352,height=288,acodec=none}:duplicate{dst=http{mux=mpjpeg,dst=:8080/},dst=display} :sout-all :sout-keep

In Mission Planner you just enter "http://localhost:8080" in the "SET MJPEG Source" when right-clicking the Hud. I have a 6GB per month dataplan in my 3g router and my calculations says that this can give me more than 52 hours of videostream. My sim card is a non-firewalled APN.

For now everything is powered from a MaxAmps 11000mah LIPO  This is a high capasity battery and the weight is only 825gram. My plan is to have 2 of those in my X8 for a really long range flight.

Right now i'm using a Sanwa 35mHz radio, but i waiting for my Turnigy 9XR and 433mHz modules from Hobbyking. I don't use 2.4gHz because of the 2.4gHz in my 3g router.

Very profound:

Links to articles:

9-inch copter lands in arms of Ohio court statue

&

Drone stuck in the arms of Lady Justice

By James Holloway

NASA's autonomous, solar-powered explorer GROVER has been kitted out with ground-penetrating radar to take to Greenland's ice sheet on Friday. There the robot will spend a month analyzing the accumulation of snow and how this contributes to the ice sheet over time. The scientists involved hope to identify a new layer of ice that has formed since summer 2012, an unusually warm summer which saw melting across 97 percent of the area of the ice sheet. During that time, an iceberg twice the size of Manhattan calved from the Petermann Glacier, part of the ice sheet.

NASA hopes it can offset its ice accumulation data against summer melt to gauge net loss.

Though ice sheet may sound modest next to the word glacier, it is actually reserved for only the largest contiguous chunks of ice. While any sheet more than 50,000 sq km (19,000 sq miles) qualifies, the only two sheets existent today surpass that threshold by a country mile. Greenland's ice sheet covers 1.7 million sq km of the country's land area (almost all of it in other words). The Antarctic ice sheet is much larger again, covering 14 million sq km.

GROVER stands for both Greenland Rover and Goddard Remotely Operated Vehicle for Exploration and Research. The explorer came about as a result of two summer engineering bootcamps held at NASA's Goddard Space Flight Center in 2010 and 2011. Students pitched the idea of a solar-powered rover to Goddard glaciologist Lora Koenig, who became an adviser to the GROVER project. Equipping GROVER with radar was Koenig's idea; an alternative to using manned snow-going vehicles or aircraft which are more expensive to operate.

With solar panels attached, GROVER stands 6 feet (1.8 m) tall, and weighs in at 800 pounds (360 kg). Though the steep angle the PV panels are mounted at would compromise efficiency in most environments, on the snowy ice sheet, the high reflectance of the ground means this is much less of an issue. Because energy is at a premium, a low-power radar system has been used, and GROVER will trundle along at an average of 2 km/h (1.2 mph). Despite this modest speed (actually, not so bad given its working environment), it's thought that GROVER will be capable of gathering more data than a besnowmobiled human, thanks to the sun shining all day at these latitudes during the summer months.

Initially GROVER will stay within a 3-mile range of base camp where it will communicate with the research team over Wi-Fi. Once it's confirmed that all systems are GROVER, the robot will be let off the leash and its data recovered at the end of the summer. In the future, though, the researchers hope that GROVER will be able to report data in real time via satellite. Though capable of functioning autonomously, a satellite link would allow researchers to take control of GROVER remotely.

Source: NASA

A thoughtful piece from Slate, pointing out that much of the fevered imagination about domestic drones (I'm as guilty of that as anyone) mirrors what was predicted about helicopters when they were introduced in the 1940s.

The only place where I would disagree with the author is in his conclusion, where he seems to fail to realize that because drones are unmanned, they are essentially computers in the sky and thus are falling in price at Moore's Law. Helicopters, by dint of their pilots and the safety and mechanical systems required to carry humans, never got cheap. Drones are already cheap and will get cheaper yet. 

Excerpt:

In some ways the current fever over drones resembles discussions of the helicopter in the middle of World War II. Early helicopters had been built before the war, but the technology came of age when Igor Sikorsky began building large numbers of them for the American military during the war. As Samuel Solomon, the president of Northeast Airlines, told the Associated Press in 1943, “The helicopter has tremendous possibilities.” Solomon prophesied air taxi services in which helicopters picked up businessmen on a rooftop in Boston and dropped them off “on the roof of an office in downtown New York.” Helicopters would also be used for express air-mail services, he said.

Of course, none of this came to pass, for one simple reason: Helicopters could do all of these things, but they could not do them cheaply or efficiently enough to displace other technologies. In war zones, where getting from place to place is dangerous and moving quickly is necessary, helicopters have become ubiquitous. Similarly, drones are widely used on battlefields (overt and covert) because of the unique capabilities they bring. But these capabilities are not cheap.

The analogy to helicopters appears to break down at one crucial point: It is possible, today and in the near future, to make small, cheap drones. But these small drones have more in common with model aircraft, which have thrived as a niche hobby for years, than they do with the Predators of Afghanistan and Yemen.