Blogs

From PoliceOne.com: an article on how to prepare for the new career of Police UAV Pilot. Includes advice from Curtis Sprague, a retired SWAT Officer and former Federal Air Marshal who now serves as director of the aviation division for a company called Tactical Electronics. TE offer a vertical take-off and landing (VTOL) system known as Remote Aerial Platform/Tactical Reconnaissance (RAPTR; shown). Sample:

“First, inform thyself,” Sprague explained. “There is a lot of information to sift through on the subject of unmanned aircraft systems. Subjects range from types of UAS, how to fly, cost, FAA regulations, law enforcement applications, peripheral equipment, training... the list goes on.”

The best way to gain this information, Sprague said, is to get involved in hobby flying RC aircraft. Although this hobby “can be addictive and expensive,” it is the best way to quickly educate yourself in the UAV/UAS operations.

Click on the photo to view

Western Australian companies COPTERCAM & Pixelcase team up to produce an Aerial 360 of Perth in just 60 minutes

COPTERCAM is Perth's only licenced UAV aerial photography company.  www.coptercam.com.au

Pixelcase is Australia's premium virtual tour company.

www.pixelcase.com.au

Finally managed to get everything together in reasonably working order. Lucky for me, the weather has been mostly perfect as well. The video is taken at about 9:30 pm, with plenty of sunlight to spare. Gotta love Alaska!

I figured the parking garage at the UAA campus would be a decent place to fly around. Not many people, no wind, good view - a good way to get some FPV experience. I'm not sure the seagull was too keen on the idea though...

This is just a good journalistic summary by IEEE Spectrum on the research posted here earlier today. (Note that the aircraft already has the map preprogrammed; it's not doing SLAM and learning the space as it flies. But still: super impressive!): Excerpt:

Two weeks ago, we posted about quadrotors that were able to autonomously navigate outdoors, relying solely on IMUs and simple vision systems. What we found notable was that the robots didn’t need either GPS or a motion tracking system, implying that they could go out and do their thing in what some people like to call “the real world.” At ICRA 2012 yesterday, MIT’s Adam Bry presented a paper (and video!) demonstrating a micro air vehicle capable of the same sort of self-contained navigation, but indoors and impressively fast.

The background here is that whenever we see “aggressivemaneuvering” by an aerial vehicle, there’s almost always a motion tracking system involved to provide constant feedback as to the exact location of said vehicle. There’s nothing reallywrong with that (besides that it’s sort of cheating), but practical applications are limited since you’ll never get it to work outside of your lab. On the other hand, when you get autonomous aircraft navigating around outside on their own, they’re either moving very slowly, or their owners have taken care to set them loose as far away as possible from anything that they might accidentally smash into.

Researchers at MIT CSAIL have decided that slow and obstacle-free flight is boring, so they’ve come up with a way to get MAVs navigating at high speed, indoors, around obstacles, without needing motion tracking or GPS or beacons or any of that nonsense. All they need is a little aircraft that can carry a planar laser rangefinder, an IMU, and a pre-existing 3D occupancy map that the MAV can localize itself in, and you get results like this (the good bits are towards the end):

More from the MIT group here.

Hope one didn't get away from Sparkfun HQ!

http://www.9news.com/news/article/268207/188/Mystery-object-nearly-causes-mid-air-collision

As a huge follower of Fabio and his excellent FreeIMU I thought it time to post an update. I am looking forward to playing with the final release. For those who don't already know Fabio, he is a pioneer and well worth following.

Extract from the blog...

First flights of FreeIMU v0.4

Read more of Fabios blog here

The video from our recent experiments with state estimation in GPS-Denied environments. 

The vehicle is localizing against a known map using a MEMs IMU and a 2D lidar scanner.

There are more details in our paper: http://groups.csail.mit.edu/rrg/index.php?n=Publications.Conf2012

Getting ready for the start of our next live podcast in a couple of hours time (you can download it later) 10:00 PST about 17:00 GMT I think (could very well be wrong)

The show link here

http://www.blogtalkradio.com/suasnews

Should also tell you what time it starts local to you.

If you have any questions for the airframe and autopilot designers, Jimmy Prouty and Chris Mc Nair then please send them to patrick@suasnews or tweet them at @sUASNews and if he can he will put them to them.

In this installment, we will discuss the role sUAS plays in assisting the Sea Shepherd in their ongoing endeavor to help safeguard the inhabitants of our delicate ocean ecosystems. Sure to be an exciting and informative dialogue, with all that had to be overcome operating an unmanned system from the high seas. We look forward to finding out more about this admirable example of what can be accomplished with a low risk, low cost solution.

Whilst not a aerial drone.. it still must be one of the coolest!

The links are below:

http://www.spaceflightnow.com/news/n1205/10rovertest/

http://www.reuters.com/news/pictures/slideshow?articleId=USRTR31W10

http://www.kcet.org/updaily/socal_focus/technology/mars-rover-piece.html

This is a simulation I'm working on to improve the Loiter control laws and discover optimal gains. I have identical code from Arducopter running in Flash as OO Javascript so I can ensure the behavior is the same as the real thing. I tested the MTEK GPS to find the actual latency and accuracy and then modeled it in code. This allows me to test PIDs and other coding ideas to see how the copter will behave in real life. The copter itself is a simple physics equation and should be fairly accurate. To better tune the SIM, I can compare AC Flash Logs from real flights side-by-side with the SIM flights which also output the same text based logs.

I've already found many areas for improvement in the Loiter code which i've just checked in to the GIT repository. 

Hopefully this tool will serve as a great PID introduction as well. I know I've learned a lot by comparing plots with small changes in the gains. 

Jason

Ok, I can honestly say, that I would never even attempt this with Arducopter.

Check out the AeroQuad website, if you're interested in learning more.

The Sparkfun Autonomous Vehicle Competition is on June 16th, just a month away! Once again the DIY Drones teams will be well represented, with at least 15 people from the APM team alone coming and competing. There will be the usual barbecue at Doug Weibel's house on Friday night, so if you're coming the competition and would like to join us, please give us your name in the comments below, so we can get a headcount.  

This year only airplanes (and rovers, of course) are allowed in the official Sparkfun competition on Saturday, so we're going to run our own DIY Drones Multicopter Competition on Sunday, with a location to be announced near the Sparkfun headquarters in Boulder.  So although Sparkfun doesn't want them, bring your multicopters (and traditional helis) anyway and stick around to Sunday for an all-copter competition, with cool prizes and good fun. Please give your name in the comments below if you'd like to enter in the Sunday competition, so we can plan accordingly.

Looking forward to seeing everyone in Boulder!

Hello everyone:

I don't know where to begin! This last 4 months has been amazing and very challenging. :) I couldn't have made it this far without the help the beta testers, Pteryx UAV (Krzysztof Bosak), Jeff Taylor, Irvin Stafford, Michael Oborne, Martin R and others. Thank you guys. As of now, we have a full feature set for the launch of the site around June 1st (maybe sooner). I don't have GCP support yet, but that is coming when I can get some additional time and maybe some development funds. I am pretty back logged processing flights and I am happy to report we've passed the 5000 imagery mark. Pretty cool! :D

I have been working with various companies to verify accuracy/resolution and result generation. It has been invaluable. I have to say that I am utterly amazed at the quality and consistency of the Pteryx UAV platform!

Here is an example of the worldfile results for a recently process Mikrokopter job. This job result was DEM 3cm/px with smooth/blending and Orthomosaic at 1.8cm/px.

0.0180503004230558872
0.0
0.0
-0.0180503004230558872
455529.862196518574
5569638.87532691658

(above image is SenseFly UAV Quarry Sample Imagery via DroneMapper)

Still lots of work to be done, bugs to fix and features to add. I am hoping to get some additional help with DroneMapper soon. 

Cheers and many thanks Pteryx UAV

JP Stoermer

This is a schematic of my wiring of the ArduIMU v3. I hope to be able to use this soon as my own personal and custom RTH and 'stabilized mode' solution with some extra benefits highlighted below. One extra analog pin will be used in the future to read out the RSSI level from the attached RC receiver.

This setup demonstrates how far you can push this remarkable board. The W5100 chip provides 30Hz telemetry over wifi to the ground (just make sure to use the sparkfun one, I've seen other implementations with a hardware bug that only allow that SPI device on the bus). It requires a wifi AP specifically designed for long-range connections that allows you to set some specific parameters for your intended range, up to 50km. I still need to see how this performs in the field though, but theoretically it should work nicely.

I'm using this setup in combination with an HD IP camera for a 720p video feed that has 150-200ms latency. The weight of that cam is 160g, so about the same as a gopro+analogcam. The two IP devices onboard are then connected to the onboard LR wifi station by a stripped down ethernet hub I found that fit the requirements. Regular, non-shielded, ethernet cables are stripped down (2x twisted pairs without grey insulation), which over these short distances and bitrate aren't any problem (20-40cm). All in all, it's about 100g heavier than a full analog setup on the same platform (2.3kg).

The benefit of digital over analog is that it's much easier to integrate both the vehicle and sensors into more complex ground station applications. The tasks for piloting, navigation and mission execution for example can be cleanly separated in either machines or persons.This opens up a range of possibilities of how people with different responsibilities interact with the platform or how they use the data that the plane is sending down at high bitrates.

I hope this ignites interest a bit in higher speed datalinks. Although I did manage to find the electronics for connecting stuff together, the hubs and other fairly simple electronics leave many things to be desired. Hopefully more people will consider adding a magjack instead of a serial port on their boards. The advantage of connecting everything on the plane on a single databus is that you can recalibrate *everything* in the air. This opens up ways to use resources more effectively and redirect resources depending on the context within which they are needed. There's something to say for one databus connection that everything is connected to. This facilitates integration and makes interoperability a lot easier.

From Hackaday:

Check out this video footage of this LED-adorned RC helicopter flying on a dark night. But this isn’t an art project. Analyzing the long-exposure photography turns out to be a great way of clearing up some of the physics of flight which otherwise are not at all intuitive. The helicopter used here has different colored lights on the nose and tail, as well as lights on the rotors.

Depending on how the aircraft is moving, different 3D spirography is captured by the camera. When you zoom in on part of the flight path it becomes clear that there are wider arcs on one side of the fuselage than there are on the other. This has to do with the forward progress of the aircraft and the rotation of the blades. The phenomenon is well known by helicopter enthusiasts, and accounted for in the design. But what we didn’t realize is that it actually translates to a theoretical speed limit for the aircraft. Our childhood love of Airwolf – the TV helicopter that could outrun jets — has been deflated.

You should remember the helicopter physics videos featured here last month. 

Jordi is one of MIT Tech Review's top ten innovators under 35 in Mexico! From the award annoucement: 

A 21-year old Mexican immigrant faces another day of tedious confinement in his apartment in Riverside, California, waiting to get his green card that would allow him to study, seek work or take out a driver’s license in the US.

Flashback to March 2007 and Jordi Muñoz, a passionate computer man dreaming of becoming a pilot, has just moved with his wife across the border while leaving his engineering studies hanging at the Center for Higher Technical Education of Baja California. “I was mega-bored at home so I started playing with chips and controllers, spent hours experimenting with Arduino (an open source electronic platform) code, browsing and reading on the computer,” said Muñoz.

Thus Muñoz discovered DIY Drones, a forum where thousands of hobbyists who build their own unmanned aerial vehicles share their experiences, code libraries that they develop and adapted to and plans for electronic components with other like-minded individuals.

Immersed in this sea of knowledge, Muñoz not only improved as a developer but he also  inherited the open and collaborative philosophy upon which he has based his career as an entrepreneur and made important contacts. His home experiments attracted the attention of Chris Anderson, Wiredmagazine’s editor, who saw Muñoz’s video of an autonomous helicopter flying using Arduino and a repurposed Wii controller.

Impressed, Anderson gave Muñoz a small amount of funding to manually produce 40 control boards. “They sold the same day and then we realized that here was a business,” explained Muñoz. Lo and behold, 3D Robotics, a company that employs 20 people and according to his estimates, was born. The company expects to generate $4.8 million profit by the end of the year [Editor's note: the translator confused revenue with profit. 3D Robotics is managed to generate no profit, and reinvests all earning into R&D].

This company, of which Muñoz is executive director, sells electronic accessories to hobbyists who build drones in their garage and university professors who want their students to learn engineering via robot design. The most popular product is ArduPilot system, a low-cost and easy to use autopilot. “For less than $200, builders are offered a high-tech system that would cost thousands,” says Muñoz. “Also, as its open source, they can ‘play’ with it and see real-time changes to their modifications.”

Along with teaching applications, these drones (or parts thereof) have proven useful for many other purposes. Using a small drone instead of chartering a helicopter saves a lot of money during surveillance missions, the monitoring of migratory animals or the inspection of archaeological sites.

In 2011, Munoz asked his friend William Romero to found a sister company to 3D Robotics based in Tijuana called Udrones. It is meant to serve the international market and has sent orders to customers requesting fully-assembled and ready-to-fly aircraft to places such as Germany and Australia. Although the manufacturing is done in Mexico with US technological development, the goal is to generate a technical training incubator for Mexican professionals whose skills Muñoz believes will soon be comparable to American engineers. “If the nature of my business was not open-source, I would just open an assembly line in Mexico and the workers would simply put together parts; there would not be a transfer of knowledge,” he explained.

For John Janas, president of the company Janas International Enterprises and TR35 Mexico awards judge, Muñoz’s key value lies precisely “in promoting the ideology of open source and Creative Commons researchers, students and others” who a share the details of their hardware and software. “This sharing of knowledge accelerates the development of innovative technology applications for aerial robots.”

The Dev Team has now pushed a maintenance update to both ArduCopter (2.5.5) and ArduPlane (2.34) that all APM 2 users should upgrade to (it also includes some nice improvements for APM 1).  It fixes both the APM 2 reset issue (you sometimes need to press the reset button to start the board under battery power) and an issue with some APM2s that have a slightly different version of the MPU-6000 sensor with a different accelerometer scaling factor (this is now auto-detected by the code).

Both of these are now in the Mission Planner so everyone can easily upgrade.

Tridge describes some of the changes to ArduPlane in this post:

This release includes one very important update for APM2 users, and a few other minor updates.

The main reason for the release is to fix a bug in the scaling of the MPU6000 accelerometers. We discovered that the MPU6000 on the most recently shipped APM2 boards had different accelerometer scaling than earlier boards. This resulted in bad attitude calculations which would get worse during flight (as the DCM code interpreted the conflicting information between the gyroscope and accelerometers as gyro drift). We now query the product ID of the MPU6000 on startup, and fix the scaling according to whether it is a RevC or RevD version of the chip.

If you use an APM2 with ArduPlane then it is strongly recommended that you update to the 2.34 release.

Other less critical changes in this release include:

• fixes for building ArduPlane with the MAVLink 1.0 protocol (we currently use the 0.9 protocol). In a future release this will be the default once all other components are ready
• expose a new parameter AHRS_YAW_P to control how fast the compass controls the heading. The default is 0.2, which should be good for most users (this was mostly added for ArduCopter users)
• fixed the reporting of the raw servo output value in the MAVLink logs. Previously if you uses a mission element to set a servo value (for example, for a bottle drop) the log would not reflect the servo change. The logged value is now obtained directly from the servo library so will always be accurate
• changed the default I terms for navigation roll and pitch to 0.1. It is very common to need a small I value for navigation, so a 0.1 default is better than 0
• make it possible to use UART2 for Telemetry. The APM2 has a otherwise unused UART2 port, which you can connect to the telemetry connector via a solder bridge. This adds a TELEMETRY_UART2 build option to configure the code to use this port. This is mostly useful if you have an onboard computer connecting to the APM2 via USB at the same time as you connect a radio to the telemetry port, and you want both telemetry streams active

For ArduCopter, here's the short form of the some of the changes, thanks to Randy and Marco:

1. MPU6000 accelerometer scaling fix (affected APM2s shipped from early May)
2. "Retro Loiter" by Adam Rivera (uses ground speed directly from GPS instead of calculating from lon/lat position). Improves Loiter performance
3. "AutoApproach" function by Marco Robustini, developed by Adam Rivera
4. APM2 support for Optical Flow
5. bug fix for needing to push reset before motors will arm
6. compass reversal problem (actually same root cause as #5)
7. Fix for Tri tail servo reverse issue as reported during testing.

  All frame types were updated in the planner including the TradHeli and Y6.  We figured for the Y6, even though the TB_Ratio (top/bottom motor speed ratio) has temporarily gone missing (but will be back in 2.6), it's more important to get this scaling issue fix out there.

Now the ArduCopter dev team will return to their focus on 2.6, which is all about performance (fine-tuning Loiter and Navigation accuracy)

Spent some time in the Alps with a friend. Lots of hiking and lots of flying.

Nice design by hardik allows you to use regular aluminum or carbon fiber tubes. Just 3D print the motor mounts and center plate clamps. All files on Thingiverse here. 

So my buddy Shad and I headed out to my flying spot to fly the Skywalker.

This time around I used my new roof-top antenna mount, with VTR and Planner PC mounted inside the SUV in the back seat.  I found a mount designed for an iPad which worked to hold the ASUS tablet behind the passenger seat headrest.  Worked perfectly.  I set the VTR on the console between the driver seat and passenger seat with the screen tilted so that I could see the video output.  While I have two video cameras sending video to the transmitter, I haven't yet recieved my video switch, not have I cracked exactly how to activate the switch, so I just hard wired the side looking camera in to see how mounting angle and field of view were.  Besides, the idea is to record the forward view in HD with the Contour camera, right?

Before we left for the field I also finished up my pre-flight checklist.  I have a terrible memory, and have forgotten to complete important steps before flight before (set home) so I wanted to establish a more repeatable procedure.

Once at the site we got all setup, mounted the antennas and pre-flighted.  Of course, my memory being what it is, I forgot to use the checklist.  Well, we used the checklist, but actually just to stabilize the wing of the plane as we calibrated the gyro...  I'm a knucklehead.

During the pre-flight, all was good except that when in FBW-A and STAB modes the lelevator seemed to have very very little control authority.  The servo pitch gain (P) was set to 300. Thats higher than the what others seem to be using, but I doubled it to 600... it was an improvement though still provided less deflection that the other surfaces seemed to have.  I need to look at the control horns and servo arm to see if perhaps I have set it up improperly.

After a brief mis-start Shad launched the plane and started recording with his iPhone.  I remembered this time to start the VTR to capture video from the flight... but although I turned the ContourHD camera on, I entirely forgot to set it to "record".  Crap.

So this time I was able get the plane into the air and gain altitude. I flew for 2-3 minutes, initially on manual then in FBW-A and STAB.  All worked very well, though the wind picked up and I was seeing some effects on the plane.  Once I was confident, I threw the switch to auto and the APM took over.  I was very happy, it flw in a very stable manner.  I had defined a very basic square shaped course.  I'm not sure that I'd say it followed the course, I'm still looking at the log data, having trouble developing an overlay so that I can see it output on google earth.  The telemetry data is showing me history that doesn't strongly suggest the waypoints were followed.  I seem to have lost telemetry at a certain point prior to "landing" as the kml terminates way prior to the "landing".  I'll post those files.

When the plane was at it's furthest point, I got worried that it was wandering off out of control, so I started nudging it home. Things were ok for a bit, then I noticed I was having less influence, it wasn't responding well to the TX.    Then shortly thereafter it started heading in, in a spin.  I gave it full up-elev, but it dropped below bush-tree level and that was it. 

Shad and I identified an azimuth to the plane and hopped into the SUV and drove over the the site - or tried to.   The terrain was too dense with bushes, we tried for 45 minutes or so to get to the site without scratching the hell out of the SUV, but couldn't find it , even after dismounting and seraching on foot.  The telemetry had halted and I didn't trust the indicated last position.  I haven't been able to build a kmz using the logs pulled from the APM, just from the tlogs.  I'm actively working this - any help????

We ended up heading back to the launch site, regained the azimuth to the "landing" site and started walking.  Found the plane just a few minutes later, we had been searching in the right direction, but too far from launch.

The plane was in surprisingly good shape when we found it. I would never have believed it.  I was able to identify the impact point (below). It hit the ground somewhat hard, but was upright, wings level and could not have had more that a 15 degree nose down attitude.

The wooden camera pod was damaged, more from the CountourHD (not recording) being popped from it's mounts and the safety wire shearing through the wooden from.  The telemetry unit looks to be toast.  The high mass of the 900mHz antenna wrenched the RP-SMA connector off the circuit board.  I think it is repairable, but not by me.  I'm seriously considering dropping the whip antenna and picking up a 900mHz cloverleaf antenna from ReadyMadeRC.com.  I've very happy with the 1.3GHz cloverleafe I use for video.I'll give it a shot at resoldering, but I'll have to do the work under a microscope and I think I'll have one shot at it.  That was a shame, of all the parts of this plane, the XBee's have been the most difficult to get.  I finally gave up on 3DR and bought directly from Digikey.  Maybe this is a good excuse to go with the new 3DR radios...

The vertical stab is torn a bit, but thats an easy fix.

Overall, after only 6 minutes of flight I'm still very happy to have another success.  Every time I have flown, even for the shortest flights, I have learned something.  I'm a big believer of lessons learned. 

I still haven't been able to download the video from the VTR, I have no Firewire capability, gotta get an adapter.  When Shad sends me the iPhone vid I'll edit and post.

Here's the YouTube video...

http://youtu.be/X1J39n79lts