Blogs

I thought I'd share the following video with you.  After spending several months trying to replicate the rock solid loiter videos, I've finally suceeded - and the only thing that I needed to do (other than vibration dampening) was to raise the GPS several inches above the top plate and keep the wires away from interference sources.  The HDOP has dropped from 1.9-5 to 1.3-1.6.

Additionally, I've add LED strips to the arms which are controlled by the ArduCopter board using some custom code. When armed it oscillates around like shown.  When disarmed, the arms flash when a GPS lock is absent, and are solid when there is a GPS lock.  Giving a clear indication when its safe to fly.

You can find the code for my leds.pde file at:

https://github.com/drgowen/ardupilot/commit/d5df7fce01731d5b27c3b1e83e2d09f1e719fb64#ArduCopter/leds.pde

It's fairly easy to modify, the update_copter_leds() function gets called at regular intervals, you just have to decide what to do - in my case I check the armed status and GPS state.

Here are some close-ups of the arms and legs. They are made from DuPont Zytel®, very strong and resilient in a wide range of temperatures.

Guillermo had some break force testing done, the results were impressive:

In the center it takes 204 lb (92.5 kg),  and at the tip  772 lb  (350 kg).

Sliding dovetail and set-screw retains the legs, allowing for easy replacement if needed. Picatinny rail mounting system integrated into the bottom of the arms provides endless mounting options for accessories. 

Motor wires are protected, but not buried. Quick release clips keep things tidy.

A few months back there was a story that PETA had acquired some drones and were planning on spying on farmers.  Many users of this technology might have been concerned that this questionable use might cause farmers to "shoot down" innocent drones operating near their properties.

Instead, farmers have embraced this technology and produced their own drone video.

As a follow-up to the rover drops #1 and #2 I spent a day with Assistant Professor Nagatani-san of Tohoku university in Japan (and his students) and Izu-san of EnRoute (a company that specialises in Industrial use multicopters and hobby use RC vehicles here in Japan and China) at Karuizawa's Mt Asama attempting to autonomously drop a 2.5kg rover from a large (4kg+) EnRoute "ZionPro" hexacopter.

The flight was completely autonomous including activating the servo release which held the rover to the hexacopter (we used the camera shutter release).  After being released the rover was "lowered" on a 30m wire wound around a brushless motor which was meant to slow it's descent (with mixed results).  If you've never heard of this mechanism before, it seems if you connect the bullet connectors of a brushless motor together it resists being turned.  If you attach a resistor between the bullet connectors it will resist less strongly.  In this way we could somewhat adjust the speed at which the rover descended at.

A couple of things that we learned from this test in case you try something similar:

• the altitude reported by a Ublox GPS (i.e. APM/PX4) vs a hand held GPS can vary by 10m.
• the altitude reported in google maps (and thus the mission planner) can vary by 20m from reality because they only provide the average altitude for the area.  I'm not sure how big that area is but we found that google maps altitudes could be high or low from reality depending upon where you were on the slope.
• trying to drop from a wire is tough!  we need a more reliable system for the next test.  Maybe use a range finder to get the copter closer to the surface without hitting it or perhaps measure the motor output to determine when the dangling rover has reached the ground.
• the hexacopter and battery were more than sufficient to carry the rover the 600m covered in this test.  At least twice that distance would have been possible.
• AC3.0.1 is very capable of the accuracy required for this mission.  It was a thing of beauty.

There will be one more attempt within the next 2 months which should be pretty much the same except the distance will be further and the dropping mechanism will be improved!

Thanks and all comments, input welcome!

For my own rover, Data Bus, I've been working on a board that converts Sharp range sensors to I2C.

I ran out of analog ports and had to prototype an I2C solution for my obstacle detection. I have this problem on all my robots. Pokey has too few analog ports. And I want to run a few of these on my RPi tele-rover.

They'll work with any Sharp ranger. For that matter, with any analog sensor (ideally at 3.3V or 5V). I plan to test a Maxbotix Sonar module soon.

Up to 27 of these on an I2C bus without re-programming the base address.

The firmware's oversampling, decimation and low pass filtering increases resolution and lowers noise floor. The analog anti-alias filter helps too. Performance is really good. Here's a pseudo-theremin demo:

They're running ATtiny44As. 6-pin AVRISP header doubles as I2C interface -- SPI and Serial on the newer revision is possible; I break out an ~SS pin. I also break out 2 GPIOs for the heck of it. I'm testing out SOIC and QFN versions.

If there's anyone who's building a project using analog rangers (Sonar, Sharp, other) and wants to try these let me know.

I have example code for Arduino, mbed, Raspberry Pi, and Propeller so far.

From the University of Texas in Austin, Texas, USA    

# note that there is a glimpse of architectural art piece in this video by James Turrell, Skyspace, 2013,  courtesy of Landmarks
I originally solicited other construction company users as to their ideas about using drones in the industry and to heat there experiences. This might not be the right venue for that, instead I got responses that mostly was about legalities and professionalism etc.

I just want to mention that I had knowledge and consent from the owner to publish this video, which meets the "non Applicability Sec 423.002 (6) which says it is lawful to capture images with the consent of the owner.  I have full consent from the owner, the Texas State University. And, I am just a employee of a construction company with a simple qaud copter and by no means a professional, so the video is not done to a professional standard. I found it to be quite a challenge to fly FPV in a crowded airspace without losing LOS and still trying to "get the shot"  with FPV sometimes you have to look where you are flying, and not at the subject that you are trying to film. Perhaps that is why there are often many cuts in some pro videos.
     

     The Quad Copter I used on these video's is a DJI Flamewheel,450 with a NAZA-M controller with the GPS.  I use a EZ-OSD for basic flight info, and I use a Sony CCD wide FOV camera for FPV, transmitted to the ground with a Immersion 600 MW Video Xmitter.

      It is using a 5500 MAH 30C LIPO, and I have the FPV camera rigged to a servo so I can "look" down. I receive the video both on a Fatshark video google and also an immersion DUO receiver that is attached to a 9" LCD monitor that is handheld by my spotter. There is also a Japan FPV DVR for recording the OSD and Flying camera imagery.

     All this is set up to be powered by a 3s LIP0. More info on the video ground station is here   

     The Camera doing the video is a GoPro Hero 3 Black Edition and is not using any gimble for stabilization. It is just attached to the frame firmly with without vibration damping. It seems pretty free of jitter, but of course it doesn't track level. I plan to add a gimbal soon. I have a nice brushless gimbal, but it looks like it might fit better on my Ardu Copter.

    So far the owners of the projects I've heard from really like to get the videos and stills because it gives them a much more complete picture than they get just visiting the construction site. Also, its just cool. I haven't found anyone who has prohibited using drones on the site, however as the drone operator, I focus a high level of attention to details in checking out the equipment before and after flights and and awareness of bystanders and subject the entire  process to a critical review of the flight plan, equipment condition and all safety considerations.   I think we have to be our own inspectors and make our own safety rules, we absolutely don't want an accident to mar our record of being a responsible group that can bring value to the construction industry.

note#   comments are turned off, but you can send them to my profile..  Thanks!

   Here are a couple of my flyovers...

And check this story on Constructech.com  

    http://constructech.com/news/articles/article.aspx?article_id=9763&SECTION=1

RE
------------

Since I first posted here about this competition last October, we've been pretty busy.  NASA selected Development Projects Inc. (DPI) of Dayton, OH to be our partner and run the contest.  We've selected Camp Atterbury, Indiana (in the restricted airspace around Himsel Army Air Field) to be the location, and we're working on putting everything in place so we can stage the competition in mid-May, 2014.

We've made quite a few changes based upon feedback we received from everyone and assembled a new set of Draft Rules and a draft Team Agreement for you to look over and give us your feedback. We're trying to cast a wide net and run a contest that will be open and fair to any group that plans to work professionally with unmanned aircraft in the U.S. National Airspace System.

A big part of our preparation is putting together a "Traffic Squadron" of unmanned aircraft that can create the air traffic for the competition. We're using some large scale RC planes and outfitting them with Ardupilots and ADS-B transceivers.

DPI has has put up an initial web site and they have posted the new drafts of the rules and the team agreement on this page:

    http://www.uasaoc.org/rulesreview.html

You can also sign up for the competition mailing list on this page to be informed of future developments:

    http://www.uasaoc.org/contactus.html

I look forward to your comments!

Garry

Reporting to the Vice President (VP) of Sales and Marketing, the Editorial Director will set and guide the strategy and creation of all internal and external communications, website content, and public relations messages to consistently articulate the mission of 3D Robotics. 

I've just wrapped up a new design based upon a lot of ideas I stole found on this site.

I've posted full details of the build and more pictures on my website:

Composite Folding H-Quad

We begin the tour of Iris' guts by looking at the new 4-in-1 ESC/Power Module. Each ESC is rated at 20amps capacity and is running the SImonK firmware for enhanced response and stability. The onboard Power Module provides regulated power to the flight control board, in addition to voltage and current monitoring.

An aluminum heatsink is attached to the power handling transistors

This 4-in-1 represents an elimination of 110 grams when compared to four individual ESCs, Power Module, and Power Distribution Board.

Garmin jumps into the actions cam market with the VIRB.  Specs, video and details can be found HERE

I've been working on an accessory-cage based quadcopter design to have a modular way of adding and removing components. The intent is to avoid the rubber-band and tape method of attaching components to the airframe. The accessory cage is comprised of four vertically-oriented carbon tubes and is meant to hold everything but the motors. There's a 3D-printed stage for each component; the flight controller, battery, ESCs, etc. each sit in their own carriers that slip on and off and can be repositioned as one sees fit. I have a basic "starting point" CAD model for an accessory stage, and I modify it as needed for whatever component I want to add.

The design needs some refinement: I'm going to implement a better thermal break between the motors and the [low-melting temperature] PLA airframe. It also has underside LED lighting (not visible in the pictures) that I would like to make removable for wiring access in the next version. I designed and printed prop guards but haven't installed them because I don't want to mess with the aesthetic and add too much weight, so instead I have minimalist stainless spring-wire prop guards in mind for v2.

Once I'm really happy with it my hope is to upload the files to the Thingiverse for those with a 3D printer, if anyone is interested. I'll also include the "starting point" file for the accessory stages, as well as the Inventor part files (2009) for anyone with access to that program.

You'll note in the pics that the flight controller is simply supported in its stage, so I should also work out an isolation web for it (maybe something like a shock mount for those old-timey microphones).

We would like to present you our first artistic video about how to build a flone for flying a smartphone:

 
Sorry, there is only one sentence in the video and is in spanish, but don't worry finally the drone knows what to do ;)

I have made a test of a NEX5 brushless gimbal used on my X8 Arducopter platform.

The video is raw and has not been post-processed.

For the more technical among you:

-Arducopter APM2.5 platform, firmware V3.0.1

-2-axis (tilt/roll) Brushless gimbal for Sony NEX5 from altigator.com (it is in fact a (re)labeled RC timer aluminium gimbal), using white labeled GBM5010 brushless motors (150 turns, able to hold 500gr cameras) 

-Sony NEX5R with 16-50mm objective. This big sensor compact camera delivers 50 frames/sec video and 16 mios pixels pictures. It can be radio remote controlled through APM and a IR trigger (i used stratosnapper)

It is a second episode of the X8 series of Summer Flights in France and will soon be continued with a third...

I wrote a feature for ArduPlane that allows the home position to be somewhere else than where the APM was started. This is useful for flight under "flying line" rules or if you want to ready your plane in one place and fly it from another.

The feature was requested and discussed in this thread and here. My modified code is here.

The original APM behavior: Home position is set to one of the first positions the GPS reports after powerup. Even if you desired another position as home. The position is written into waypoint 0 too, so you will see the home position by (re)loading the mission into MP.

Modified behavior: There is a new parameter STICKYHOME_RAD, in meters. If the GPS position is nearer than this from waypoint 0, home will be se to waypoint 0. Otherwise it will remain unchanged and the controls will wiggle 3 times. This allows one to set an alternative home position without risking a flyaway of more than STICKYHOME_RAD meters. In this version, I have removed the servo wiggling at normal startup because I find it unnecessary and it makes my planes rock'n'roll at gyro calibration. Wiggling = something was not as expected.

Waypoint 0 is only overwritten if it was previously undefined. Reading the mission, the waypoint 0 read is the one last written. Any reason to change that?

There are a few console messages too. It appears that not all get though because they come in a too rapid succession. See init_home() in commands.pde.

The home altitude may be quite inaccurate too, because GPS takes some time to get altitude right. If you fly with pure baro altimeter (ALT_MIX=1) and you use relative-altitude waypoints, you will not be affected. Funny enough, this is default. I fly in hilly terrain and need to check my missions carefully against Google Earth etc. and therefore need absolute altitude. I often get home altitudes that are 100s of feet off, potentially disastrous if not rejected.

To try solve that problem, the altitude of waypoint 0 is also used. If the horizontal distance to waypoint 0 was OK, the GPS altitude is compared to the waypoint 0 ditto. If off by less than STICKYHOME_MAD (Max Altitude Deviation), the altitude of waypoint 0 is used for home. Else, the controls will wiggle 5 times.

So all in all

No wiggles: Waypoint 0 was undefined at startup, or both position and altitude were within bounds of waypoint 0
3 wiggles: Position was not within bounds of waypoint 0. GPS position and altitude were used for home3 wiggles:
5 wiggles: Position was within bounds of waypoint 0 but not altitude. GPS altitude was used for home. Recommended action if using absolute altitude: Wait a few minutes, try reset APM.

For consideration: When reading the mission, should the EEPROM stored waypoint 0 be returned as waypoint 0, or should the actually used home position (which is the same if within bounds)?

If postion is OK but altitude is off, should the APM go into a wait loop until altitude is OK?

From Techcrunch:

An Indian startup, Social Drones, is using its home-grown arsenal of bi, quad, and octo-copters to survey the effects of a recent natural disaster which claimed 580 lives, and is planning to courier medicines and foods to isolated victims. Drones don’t have the best reputation on the subcontinent and in the Indian state of Uttarakhand, sandwiched between war-torn countries of Pakistan, Kashmir, and Nepal, villagers no doubt harbour suspicions of the remote-controlled flying beasts infamous for dropping bombs. Social Drones hopes to change that perception.

The startup has joined forces with ten other Indian startups to form the Rise Uttarakhand campaign, where entrepreneurs will build apps and use their products to assist with the recovery effort in Uttarakhand, which was devastated by floods and landslides on June 16 and 17. There are still 5,100 people missing, including 300 foreign nationals.

After the floods struck, Mane sent two of his staff and two of his $8,000 quadcopter drones to survey the damage from up to 300 metres in the air. These images and videos are being given to organisation Help India 2013, a group of over mountaineers delivering food, water, and medical supplies to over 200 villages. Mane said the drones, which are 100% Indian-made, are operating in the areas between Uttarkashi and Gangotri, where about 5,000 local villagers have been stranded in makeshift camps since the floods completely wiped out the local infrastructure, including the 100km road that connects the two towns.

“The government didn’t make any footage available to the public because they couldn’t capture it so we thought, let’s go film the disaster and the volunteers, who are the real heroes,” Mane said.

After seeing the mountaineers trek over 20 kilometres each day through the unstable mountainous terrain, Mane saw an opportunity to lighten the load by having his airforce deliver the goods. The four-blade quadcopters couldn’t navigate the disaster conditions when the floods first struck a month ago but it’s a different story now that the fierce conditions have subsided. After running some early tests he is confident of making the first deliveries starting from next Monday, and they’re also organising a crowdfunding campaign to raise money for medicines, fruits and even portable water purifiers.

“A month ago the disaster management was there and they were recovering people and finding people but right now the majority of that work has been completed,” Mane said. “However, there are still people in various camps scattered across Uttarakhand and there are no linkages or channels to connect them. There’s no co-ordination with the government, which is mainly repairing popular tourist regions.”

Mane believes drones are the answer,  and is working alongside Dutch weather forecasting firmAeolis, which is providing real-time satellite information to military and volunteers. Also Weekend Ventures recently organised hackathons in Mumbai, Bangalore, and Delhi, where one team developed a phone-based version of the Google person finder app.

“We think the aerial delivery would be the best option, as well as developing applications to co-ordinate all the volunteers. We’ve already designed those and are in talks with companies to deploy web and mobile apps to these areas.”

I made this video to show a typical easy set-up on a DJI Phantom but the concept is the same for any multirotor.

From Signal magazine:

The Defense Advanced Research Projects Agency (DARPA) program is known as High-Assurance Cyber Military Systems, or HACMS. Kathleen Fisher, HACMS program manager, says the program is aiming to produce software that is “functionally correct and satisfying safety and security policies.

“It’s not just that you’re proving the absence of a particular bad property from the security perspective,” she explains. “You’re actually positively proving that the software has the correct behavior.”

Fisher points out that with unmanned systems, an attacker can reach the relevant software remotely. Until a few years ago, cyber-physical systems such as automobiles had their own built-in security because they were not networked. But, automobiles increasingly are likely to have network connections, especially those that automatically provide for emergency response in the event of an accident. “The fact that pretty much all of these systems are networked means that the kind of vulnerabilities we’ve seen on desktop and traditional computing systems for the past 20 to 30 years now carry over directly to these kinds of cyber-physical systems, such as vehicles,” she says.

...

One target platform is an ArduCopter, which Fisher describes as a hobbyist unmanned aerial vehicle. The code in this relatively small system is readily available, so developers should be able to replace the code completely. Developers already have built a domain-specific language called Ivory that would generate flight control types of code. Half of the original control system code has been replaced by the new high-assurance version—enough that the helicopter can be flown using this new code, she posits.

This effort is paired with a helicopter being produced by Boeing that can be manned or unmanned, so the ArduCopter’s architecture is being adjusted to match that of the Boeing helicopter. This will allow for easy transfer of the software developed for the ArduCopter to the Boeing craft. Fisher points out that the Boeing helicopter effort does have specific software replacement goals for each phase, unlike the other vehicles.

I did some more flights on the weekend to test out my branch of Arducopter 3.0.1 -THdev and wanted to show what it's like from on-board the heli in a reasonably high-speed run.  This run used 12 waypoints to form a rectangular pattern with rounded corners around the flying field, trying to achieve a nice smooth flight path.  I still haven't been completely successful as it's a bit jerky.  This was using WP Acceleration of 200 cm/s/s, and WP Speed of 25 m/s, but this was not achieved on this flight.  It did hit 20 m/s, and I'm happy to see that it's very very smooth.  With settings of 20 m/s and 100 cm/s/s acceleration it's much smoother but takes too much room to accelerate. This was also using the Yaw Look Ahead mode which causes the yaw to automatically look into the direction of flight.  The flight ends with an RTL which causes the yaw to return to the original orientation on the final descent.

Overall, I'm very happy with the performance, but I really anxiously await the Spline Nav feature! :)

The heli itself is still a work in progress.  Obviously the camera vibration damping is completely unacceptable and I'm redesigning that.  But other than that, it's going well.  The Direct Drive Tail is brilliant, and really simplifies the mechanics.

I am getting about 12 minutes flight time, including a 3 lb payload (yes, I'm using steel blocks as ballast), and this is with a battery load smaller than a 700 typically has.  Normally they run 12S 5000 mAh, and I've only got 8S 5000 right now.  But I plan to run a total of 8S 10,000 which should give better than 20 minute flight times.  

Once I'm comfortable with the reliability, I'll be stretching it's legs on longer runs.  I'd like to have this capable of at least 100 km/h flight with a camera on-board.  What I envisage building is a compact high-speed aerial filming platform capable of chasing race cars, etc.  Ultimately I will build a completely custom frame but for now I'm just hacking on this 550 frame stretched to 700.

This is a summer flight video of my "Mr. Red" Arducopter, configured as an X8.

Although the arducopter X8 setup is the least efficient in terms of number of motors/lifting power ratio, it is a super stable platform for aerial photography and aerial filming.

For the more technical:

-APM 2.5 running v3.0.1

-Tiger motors 3110-17 (700Kv)

-3DR 20 amps ESCs

-Smaller props on top motors: 11x4,7

-Bigger props on bottom motors : 12x3,8

-Frame built based on 3DR, VulcanUAV and other home built/exotic parts

I will soon post a second episode showing filming results you can get with this platform together with a brushless gimbal embarking a NEX5 camera.