Blogs

First images from the sky of the Bamboo House and new research facility at the Jama-Coaque Ecological Reserve.

The Pacific Equatorial Forest at 0° latitude in costal Ecuador encompass a diversity of forest types within close proximity to each other, including tropical rainforest, moist evergreen forest, premontane forest, and tropical deciduous forest. It is part of the Tumbes-Chocó-Magdalena biodiversity hotspot and is considered the most threatened tropical forest in the world with approximately 2% of the original forest remaining. High rates of endemism combined with the massive forest loss in the region has resulted in organizations like the Centro de Investigación de Bosques Tropicales (Tropical Forest Research Center) reporting that the loss of this habitat “over the past 50 years represents one of the greatest species extinction events in history.” Primary threats in the region are the conversion of forest into cattle pasture, African palm plantations, and other agricultural operations. The Third Millennium Alliance (TMA) is working to preserve the last remnants of the Pacific Equatorial Forest with its flagship project the Jama-Coaque Ecological Reserve that now protects almost 500 hectares of the Jama-Coaque Coastal Mountain Range. TMA focuses their efforts on reforestation, conservation, and community outreach programs, creating a three-pronged approach to preservation.

Trying to get first flight in between rains.

Ryan Lynch, Executive Director of TMA, contacted me in mid-2014 to ask about using a drone to acquire high-resolution imagery of the Jama-Coaque Reserve (JCR). Ryan and I had met the year before at a meeting in Ecuador discussing the Yasuní Biosphere Reserve in Amazonia and I had mentioned my initial work with drones in the region. They had been trying to find decent satellite imagery but most of the time the majority of the area is shrouded in cloud cover. I told Ryan I had an extra multirotor copter I was bringing down to Ecuador with me at the end of the year for some work. I said we could work something out so I could head to JCR to show them how it worked and I would leave it with them if it seemed feasible. Well, some of my scheduling didn’t work out but things did work out with Ryan and I left for JCR after the first of the year.

When I arrived at JCR and got a firsthand look at the terrain I knew it was going to be a challenge. I brought a hexacopter made up of my own CNC’d parts as well as other mainstream manufacturers bits and pieces with the excellent FrSky Taranis TX/RX. After several years of different flight controllers I have now settled on the Pixhawk system using Arducopter. I had picked up a used Canon SX260 and loaded it with CHDK hack firmware, and built a Pixhawk to USB cable interface trigger following the excellent instructions at Flight Riot. I had pre-cached the area in Mission Planner with Google Earth imagery but soon realized the imagery seemed to not match the SRTM elevation data and was overall poor quality. What were stream valleys on GE had the highest elevations of the area in Mission Planner. We had no internet and just had to work with what we had (see below right: GE screenshot showing the low quality satellite imagery we had to use, regardless of the fact that the elevation data also appears to be shifted by up to ~100m.). I decided to trust the elevation data and not the imagery to fly by and setup a mission that maintained 150m above each waypoint. It was either going to fly the mission and come home or slam into the treetops on the mountainside opposite us. Twelve minutes later the hexacopter parked at the home position and I brought it down for a landing. Landing in about a 1m square area on the side of a mountain proved challenging to say the least. We eventually devised a plan that would require at least a few 2x3m takeoff and landing areas on the mountaintops for running the required missions to map all of the reserve. Wouter Hantson, TMA GIS expert, is also going to create a better basemap to load into Mission Planner for the future mapping efforts. This will greatly increase our confidence in mission development. Dodging rains at the start of the rainy season and dealing with some power issues to keep everything charged we managed to get several more flights in and work out the rest of the strategy for mapping the entire reserve.

Initial mapping mission image results over Jama-Coaque.

To my knowledge, TMA is the first organization in Ecuador to implement drone technology for its utility as a powerful new tool to assist their conservation efforts. Initial plans for the data are to use it for monitoring the area for illegal logging activities within the reserve on regular basis. Other more ecological based projects include identifying historic, small agroforestry plots that occur throughout the reserve that may not have already been found on foot. One of the major projects is going to be monitoring reforestation efforts and the harvesting of a balsa wood plantation that will be reforested. This is just the start of what should be a great collaborative partnership between TMA and myself as a researcher at Texas State University in the use of drone technology; in an effort to support conservation and ecological research in a biodiversity hotspot that needs our help protecting it.

Clear contrast of balsa wood plantation (lower left) and intact forest.

If you are looking for an excellent conservation organization to support then the Third Millennium Alliance is one you should consider. A big help in our efforts would be a camera capable of multispectral imagery acquisition. Even one of the modded cameras like an NGB converted Canon SX260 would help. Additionally, I am looking for a highly motivated and GIS experienced individual who would be interested in working with this data on some of these projects as a graduate student. Please contact me for more information: Shawn McCracken (frocga@gmail.com).

Facebook: https://www.facebook.com/tmalliance

Additional links:

http://tmalliance.org/

http://www.globalforestwatch.org/stories/122

http://www.amphibians.org/news/my-life-in-ecuador-and-the-amphibians-of-the-jama-coaque-reserve/

http://v-c-a.org/areas/ec/jama-coaque

Initial mosaic of approximately 8 hectares with trails overlaid:

Below: A short video from when we were taking imagery of a balsa wood plantation that is to be harvested and reforested with native trees.

Jama-Coaque Reserve property flight from Shawn McCracken on Vimeo.

Forget about the FAA - drones controversy. Now the FAA claims the control over the Moon landings.

The U.S. Federal Aviation Administration has caused a bit of stir by hinting that it plans to expand its authority to include exploration of the moon and the use of its resources. News agency Reuters has reported that it has obtained a copy of a letter composed by officials with the agency and sent to U.S. based Bigelow Airspace—in it, the agency said it plans to leverage its launching authority by adding licensing authority of moon assets—all to encourage private companies to invest in such activities. The reason such a move has caused a stir, of course, is because it appears that the U.S. agency is attempting to expand its oversight into an area where it does not have the authority to do so.

Read more at: FAA control of moon landings

One year after the T3 contest, here are some works from this year and a review of the new tools that we learn to use.

I am still working with Canon S100 and dronemapper intervallometer script, all multirotors are now controled by Pixhawks, the flying wing is controled by an APM 2.5.2

New open sources tools for DEM visualisation :

Visit 2.8.2  (above)

You can get it here :

https://wci.llnl.gov/simulation/computer-codes/visit/

Really good for generate colored shaders and contours and for very-micro-reliefs analyses

Relief visualisation toolbox

RVT from Dr. Žiga Kokalj - 2014

Research Centre of the Slovenian Academy of Sciences and Arts (ZRC SAZU)
Centre of Excellence for Space Sciences and Technologies (Space-Si)

Get it here :

http://iaps.zrc-sazu.si/node/67731#v

Here is an exemple of multiple-direction shader (16 directions) at Commes (France) for CNRS and INRAP :

Somes works from this year :

Jardeheu (France), 5cm resolution :

Fleury-sur-orne (France), INRAP

Medium neolithic necropolis, 4cm resolution :

Detail of a small neolithic Tertre, 1cm resolution :

Orthophoto and DEM of a very big Tertre, 1cm resolution :

Others news works here :

http://panormandic.com/travaux-recents

Just a few days ago we had the first flight with Ubuntu Snappy Core with our Linux autopilot Erle-Brain (video  link).

As announced in a previous blog post, together with Canonical and the OSRF we aim to bring an app store for drones based on ROS and the simple "snaps". A new packaging system that Canonical just introduced (something similar to a "zip" file).

Soon we hope to release a microSD image that would allow everyone with a PXF and/or Erle-Brain play with Snappy and start creating drone applications.

We've just wrapped up an incredible week at the first ever Drones for Good Challenge. Not only was this the first event of its kind in Dubai, it was the first ever such event in the world. I was thus hugely honored to both keynote this outstanding celebration of technologies for good and to also serve on the judging panel for the finalists. Some 800 teams from nearly 60 countries around the world submitted their "Drones for Good" ideas. Only 5 made it to the very final round today. I lived-tweeted the event and curated the  list of tweets below as a summary (all original tweets available here). My head is still spinning from all the possibilities, ideas and the incredible innovators that I had the good fortune to meet in person. I'll absolutely be following up with a number of them for several Humanitarian UAV projects I am working on. In the meantime, huge thanks to the organizing event team for their very kind invitation and friendship!

I'm excited to explore the above possibility with a number of key individuals who I met and spoke with whilst in Dubai.

We have a standing policy here at DIY Drones of no discussion of weaponizing drones, but the White House incident was so important and this Wired article so illuminating that I'm going to make an exception this time. From Wired:

If you want to understand why the government freaked out when a $400 remote-controlled quadcopter landed on the White House grounds last week, you need to look four miles away, to a small briefing room in Arlington, Virginia. There, just 10 days earlier, officials from the US military, the Department of Homeland Security, and the FAA gathered for a DHS “summit” on a danger that had been consuming them privately for years: the potential use of hobbyist drones as weapons of terror or assassination.

The conference was open to civilians, but explicitly closed to the press. One attendee described it as an eye-opener. The officials played videos of low-cost drones firing semi-automatic weapons, revealed that Syrian rebels are importing consumer-grade drones to launch attacks, and flashed photos from an exercise that pitted $5,000 worth of drones against a convoy of armored vehicles. (The drones won.) But the most striking visual aid was on an exhibit table outside the auditorium, where a buffet of low-cost drones had been converted into simulated flying bombs. One quadcopter, strapped to 3 pounds of inert explosive, was a DJI Phantom 2, a newer version of the very drone that would land at the White House the next week.

Attendee Daniel Herbert snapped a photo and posted it to his website along with detailed notes from the conference. The day after the White House incident, he says, DHS phoned him and politely asked him to remove the entire post. He complied. “I’m not going to be the one to challenge Homeland Security and cause more contention,” says Herbert, who runs a small drone shop in Delaware called Skygear Solutions.

Read the rest here

Excerpt below from How Uber’s Autonomous Cars Will Destroy 10 Million Jobs And Reshape The Economy by 2025

"I have spent quite a bit of time lately thinking about autonomous cars, and I wanted to summarize my current thoughts and predictions. Most people – experts included – seem to think that the transition to driverless vehicles will come slowly over the coming few decades, and that large hurdles exist for widespread adoption. I believe that this is significant underestimation. Autonomous cars will be commonplace by 2025 and have a near monopoly by 2030, and the sweeping change they bring will eclipse every other innovation our society has experienced."

The ardupilot development team is proud to announce the release of version 3.2.1 of APM:Plane. This is primarily intended as a bugfix release, but does have some new features.

The major changes in this release are:

• fixed a mission handling bug that could cause a crash if jump commands form an infinite loop (thanks to Dellarb for reporting this bug)
• improved support for in-kernel SPI handling on Linux (thanks to John Williams)
• support UAVCAN based ESCs and GPS modules on Pixhawk (thanks to Pavel, Holger and and PX4 dev team)
• Multiple updates for the NavIO+ cape on RaspberryPi (thanks to Emlid)
• multiple automatic landing fixes, including improvements in flare detection, glide slope calculation and lag handling
• fixed a bug that could cause a change altitude MAVLink command from causing a sudden descent
• re-enable CLI on non-APM1/APM2 boards
• Lots of EKF changes, including reducing impact of ground magnetic interference, reducing the impact of a GPS outage and integrating optical flow support
• added initial support for the PX4 optical flow sensor. Just logging for this release.
• added support for MAVLink packet routing
• added detection and recovery from faulty gyro and accel sensors
• improved arming checks code to detect a lot more error conditions, and change the ARMING_CHECK default value to check all error conditions.
• added support for BBBMini Linux port
• increased number of AVR input channels from 8 to 11
• auto-set system clock based on GPS in Linux ports
• added SBUS FrSky telemetry support (thanks to Mathias)

IMU Failure detection

Perhaps the most important change for this release is the improvement to the detection and recovery of bad IMUs. We have had a number of reports of bad IMU data in flight from both the mpu6000 and lsm303d. Where possible the drivers how try to detect the failing sensor and reset it. Sometimes it can't be reset, in which case it will be locked out and the other IMU will be used, unless it is the last available IMU, in which case it will still be used. In either case the user is notified of the failure via the GCS so they can land.

UAVCAN support

The main new feature in this release is support for UAVCAN ESCs, GPS modules, compasses and barometers. Note that while support is in for UAVCAN ESCs and I have been flying with a UAVCAN ESC on my test plane for a few weeks very successfully, support for configuring the ESC is still fairly basic. You will need a debug cable to connect to the ESC to configure it as per the http://uavcan.org website. We hope to add MAVLink enabled configuration soon.

Many thanks to everyone who contributed so much to this release with bug reports, patches and suggestions. My apologies that we didn't get everything done that we wanted to get done. We have pushed some things out to the next release to prevent the release date sliding back any further.

Happy flying!

Cemeteries use paper and old school spreadsheets to manage their land and know where to dig. But these outdated systems can lead to errors and expensive lawsuits when graves are dug in the wrong place and someone’s Rest In Peace is disturbed. PlotBox offers a SAAS for cemeteries and crematoria that helps them manage their land and bookings. The startup can use drones to quickly scan cemeteries for free plots much faster than traditional methods. It scanned a 50 acre cemetery via drone in 30 minutes when it would have taken 100 hours normally. PlotBox has $280,000 in closed sales already, and is hoping to kill the old cemetery management systems to bring technology to a $3 billion US market.

source:

http://techcrunch.com/2015/02/04/niche-to-win/

Plotbox website:

http://plotbox.io

We've just updated the ardupilot.com wikis with a brand new skin! We think you will find it easer to read, navigate, and contribute to.

Some of its benefits include:

• Faster to the content: The top banner is thinner so you can get to the content much faster. More of the article is visible before you need to scroll.
• A pleasure to read: The new theme is based on the wordpress twentyfourteen theme, and gains from its attractive fonts and excellent visual design.
• Mobile friendly: The theme changes layout for mobile devices, pushing the menus below the content. You can test this by shrinking the width of your desktop browser.

• Easier to contribute: Contributors can now concentrate on writing because almost all the "boilerplate" in the old theme is now part of the skin.

Of course no matter how pretty the theme is, the most important thing is the content! We're working hard to improve that too. If you have expertise that you'd like to share, then please email me to get access to the wiki ( hamish at 3DRobotics dot com ).

The skin will continue to evolve with better support for organising and managing the content. Let me know what you think of our efforts so far, and feel free to share your suggestions for improvement on the forums.

Hi guys,

We would like to share with you very simple find we did during our operations. Making reusable Ground Control Points (GCPs) for aerial photography and photogrammetry.

We spend a lot of time testing and tuning our Universal Ground Control Software U[g]CS in a real world scenarios.

For aerial photography and photogrammetry you can rely on modern software like Pix4D, Acute 3D and other to produce good results without ground control points. If good is not enough and accurate 3D model or digital map needs to be rendered you always need GCPs.

We started from “classic” crosses made from painted plates of cardboard, wood and plastic, but they proved not to be practical in every situation and all weather conditions we encountered.

And finally we found that best material for small GCPs is simple ceramic tiles:

For each GCP you need 2 black and 2 white tiles with mat surface. Glossy has reflections and does not work well.

They are absolutely water (rain/snow), wind and mud resistant. Can be easily transported in car and reused almost forever. Until human error takes its toll and you drop them on rocks or hit hard against a car.

Tiles with 40X40 cm size proved good for making shots from up to 100 meters.

This is a shot taken from approx. 50 meter altitude with GoPro:

Zoomed in part of the frame above:

Good luck and safe flights,

UgCS team

video link:

http://youtu.be/pEHXDaxDr3Q

So apparently, PKP - Polish Railways are testing drones to capture coal thieves. It's hard to believe, that they captured an actual footage of steeling during the tests, looks more like PR move, but that's what they say. PKP claim to have plans of implementing the system for automated drone patrolling in near future.  

I think they could use some zoom gimbal camera ;)

It's been a week that the ground station survey is online and it received 82 responses. Not a whole lot for a forum like diydrones, but most companies only manage to interview 5-10 people. So the results of this survey should be considered a valuable resource.

In this analysis, I won't highlight the points that seem inconclusive, because they didn't get convincing results. Convincing is when there's more than 20% difference between disagreement and agreement. Before you complain about these definitions, the full data is publicly available at this link, so you can reinterpret the data any way you wish:

https://docs.google.com/forms/d/1h0LPVE2wBQ9M2ggtfrSf1tVHnUgg5ygf1msSuElUdyc/viewanalytics

https://docs.google.com/spreadsheets/d/1mSGOxo_MCRRILa5vDh2Ppu9JKFlt9FmepD8_BWBsQWo/edit#gid=119881673

1. 52% states they use the GCS as a backup mechanism for controlling the aircraft. 26% controls the aircraft mostly through the ground station and 25% does something different.
2. 76% says that their ground station allows them to do what they need.
3. 56% vs. 30% says you need training to be able to use a ground station.
4. 61% vs. 19% says that they are impacted by unreadable screens in sunny weather.
5. 30% vs. 15% thinks the PFD is indispensible, but 60% is neutral. This could indicate people do not really care about the PFD being on screen during flight?  Some people would probably complain here, because when you're in the plane you can be subject to loss of orientation and this would therefore require the PFD to be installed?  Except for uav's, where the IMU doesn't get confused like humans do. In the case it *does* get confused, the reading is not reliable anyway, so you can't really use it then. For multirotors the results will be catastrophic, for fixedwings you need to be a good model pilot. So it's an interesting question to be asked that perhaps PFD's are only sensible in the config and setup stage to confirm correct IMU sensing?
6. 65% vs. 10% says that speech and audible functions are indispensable. That is a convincing majority and this makes sense, given that a large number of users are both pilots and gcs operators or a mix thereof.
7. 59% vs. 13% thinks that they shouldn't be forced to move the waypoints individually, but somehow do this at a higher level of conception.

Then some interesting statistics:

1. 40% operates their uav as a one-man show and about 50% is a 2+ team. 16% claims to have rigidly defines roles.
2. In the control question asking how the roles are defined, we see the 40% plus another 20% ( of the 2+ people teams ), where the pilot seems to get the entire say and control over the GCS. That comes close to the expectation.
3. 45% is happy with the way how their GCS is supporting in all phases of flight. 21% needs to learn about these options more and 34% thinks there's room for improvement.
4. In cases of events that their craft needs to go out of the way, 43% claims to be able to do this between 2-30 seconds. 20% takes over manually instead. 37% says they either don't need it, will take too long or haven't tested this in practice.
5. About 80% has ever only controlled 1 UAV by the GCS at the same time. 10% 2, 8% 3, and 4% 4-6. This is however a bit tricky to analyze, because this type of swarm control is an active area of research and not all GCS's allow for more than one uav at the same time to be controlled.
6. 40% plans the flight with the customer indoors prior to the flight. 24% does this in the field in detail and 35% does most of the planning themselves, sometimes with a bit of gesturing by the customer. None of these styles listed are considered "best" by the way, because they highly depend on the industry area you're active.

Then, to find out a bit more about respondents:

• 30% has 2-4 years in total related to modeling, uav's, aviation or the entire field.
• 34% has less than 2 years experience.
• 34% has more than 4 years experience.

Then the open question, where people can complain, add, or write some additional notes about the use of GCS's in general. Reducing them categorically:

• General complaints about use in the field: screen readability, portability and making things easier for non-technical users, clipping on transmitter, dust on touch-screens, bulky mouse/pc, etc.
• Switching tools depending on the environment: MP for inside, DP for outside, AP not used.
• Permission settings on which GCS or user can control what.
• The ability to keep mission-related stuff together, including cached maps, logs, etc.
• User customization of screen elements (make them larger? placement, etc. ) and saving those customizations. Saving the last-known context, so you go straight back into the last thing you were doing.
• Different views in the GCS for different roles: pilot, engineer, payload operator. Implies more instances.
• POI, ROI and Follow me functions using flight data (specify less, better defaults?)
• Run the GCS without having the uav connected yet, so less dependent on having the actual connection to the uav and being more agnostic on establishing the actual connection ( craft discovery? USB event trapping? fixing baud rates? or trying most likely baud rate and then if failure occurs, allow user to modify it? )
• GCS should be inspired by game designers and figure out what's really needed on screen. More flexibility in defining the display.
• GCS should be usable on iOS and touch-input devices with care taken about incorrect touches ("are you sure y/n?")
• More (scripted?) automation on events. Think HDOP < x, battery (already there), etc.
• Better payload and auxiliary control through GCS.
• interfaces in 3D, better visualization for planning missions and landings.
• Integration with R/C controls.
• Make it easier to use for crash analysis and to figure out what went wrong.
• Pre-flight check including parameter verification. Sounds like people actually want a "good" file on the GCS and then prior to flight verify the settings on the device are actually those ones. Peace of mind!
• Manually constructing the landing procedure is too difficult.
• Slow startup on more limited hardware in the field. Should be faster.

One comment attracted my interest, so I'll post it here in full:

GCS is broad term. I will speak specifically to DroidPlanner 2 and Mission Planner respectively. The fist offers limited functionality with regards to critical pilot info. ie HDOP. It seems like a tool built for the newbs to enjoy playing with technology rather than understanding the dynamics of UAV flights. Don't get me wrong it's a beautiful fluid interface, just wish I had full parameter control (w/o bugginess) and the ability to add certain reads to the display. MP is a robust toolbox that I bring out to the field because I trust it 100%. My wish is that UI/UX would be rethought. For example, I like to verify parameters before flight. At the moment this is too many clicks away and buried under heavy mouse behavior. If I could, I would integrate a customizable pre-flight check function into MP that would bring up in series specific parts of MP that give me peace of mind prior to take off. Dronedeploy is thinking about this with their system, but in a bit too controlled manner with not enough info. I've voiced some of these things to a local crew here who's developing and browser GCS. http://www.flyroutinely.com/

So these are the results of the survey... thanks all for participating, they did give me some interesting insights into what lives in the mind of the uav operators. I hope this survey contributes to making existing ground stations better, so we can make future flights safer and make our operators better informed about the status and intention of our aircrafts.

Hi,

As promised, more details are now available. NVIDIA is our technological partner and Percepto is powered by the Tegra K1 SoC.

Thanks a lot for your feedback and interest in Percepto.

After getting many repeated questions I have decided to answer some of them here to clarify some things.

What exactly is Percepto?

Percepto is a drone add-on. Meaning it’s a device (about the size of a deck of cards) and a small camera that you connect to your existing drone. Percepto enables new features you didn’t have before. It enables your drone to use the power of computer vision in real time. With computer vision drones can “see” and understand the environment better than with todays sensors.

What exactly can I do with it?

You can develop and use computer vision based applications for your drone. By using our drone control API and pre-accelerated computer vision primitives, you can focus on your application, and get results a lot faster.

For example, let’s say you want to control your drone using hand gestures. With Percepto, you already got the hardware ready, so you can either write your own code or use Percepto’s core hand recognition primitive, as well as our APIs to easily direct the drone’s movement. Now all you need to do is decide what the drone should do after each gesture, and write a simple code that describes just that. After connecting Percepto, you’ll have a hand gestured controlled drone.

I am not a developer, is Percepto for me too?

Absolutely. Developers will only be motivated to create new applications if users will be there to appreciate and enjoy them.

Also, we will ship Percepto with a few applications of our own, like: .

Our filming app (Name ideas are welcomed)

Using your smartphone, mark any object and have the drone follow it, circle it or create any filming maneuver you desire with a click of a button. Since Percepto works onboard and in high rates it is very responsive and can create filming maneuvers in higher speeds and smoothness than todays GPS based features. We are constantly working with professional aerial photographers to improve Percepto’s filming capabilities.There is also a mode where Percepto controls the gimbal alone, leaving the drone control in your hands.

OSD (On Screen Dispaly) app (Again name ideas are welcomed)

A customizable heads up display, driven by our computer vision algorithms which can produce smart alerts such as obstacle advisory, object searching or even locations of additional Percepto powered drones flying nearby (We use it like a radar when we drone “dogfight” ;).

Percepto will constantly update with applications developed by us, as well as applications developed by our community. So, if you’ll own a Percepto, you will be able to experience any new exciting application released.

Does Percepto include a flight controller?

No, it integrates with existing flight controllers like 3DR Pixhawk and DJI Naza. After considering safety issues, ease of development, processing resources and the commercial drones ecosystem benefits, we came to the conclusion that the computer vision unit should be set apart from the flight controller.

How do I physically connect it to my drone?

Percepto connects to your drone the same way a camera gimbal, an FPV transmitter or DJI Lightbridge connects to your drone. It needs power from the drone battery, and a connection to the drone’s flight controller. All cables will be included.

Which drones can I connect it to?

We’ve already tested Percepto with 3DR Pixhawk and DJI Naza controllers, so, every drone that uses one of these controllers is compatible, but basically, you can connect it to every drone that has a PPM input in its flight controller.  Also, the drone can’t be too small, as it has to carry Percepto, which will weigh around 5 ounces (140 grams).

How is Percepto different from other development platforms?

Percepto is a state of the art processing platform tailored specifically for drones. The connectivity is designed for this specific use. The camera we’re shipping with Percepto is focused on frame rate and minimal distortion. Above all, our computer vision primitives are accelerated on Percepto’s CPU/GPU (NVIDIA Tegra K1) and our APIs make it easy to translate software decisions to drone flight maneuvers.

How will Percepto control the drone?

Depending on the application and the flight controller in use, Percepto can control the drone through PPM (just like an R/C receiver), or it can communicate with the flight controller through a digital connection (MAVLink, for example). Percepto can also be set to control only part of the control channels, leaving the others for manual control.

Percepto itself can be controlled either by your RC remote, or with your smart device through WiFi.

For some features, “follow me” for example, Percepto might fly the drone completely autonomously. In other cases, such as obstacle avoidance, Percepto might only intervene partly with the drones flight route or manual control.

Another option is to use Percepto for completely different tasks like augmented reality FPV or performance monitoring.

When will it be available?

We will start shipping Percepto to selected beta testers in July 2015. It will become publicly available by September.

How much will it cost?

We are now finalizing mass production costs with our different suppliers. This is why we have decided to launch our product in a crowdfunding campaign soon. I know it’s already became a cliche but it’s true, the more products we will have pre-booked and the more demand we will see for the product the lower we can make the cost.

Again thanks a lot for your interest!

We would really like to hear any thoughts, questions, remarks or expectations you have from Percepto

Please don't hesitate to contact us with any issue.

If you are interested in learning more please subscribe on www.percepto.co.

All the best

Raviv

From Gizmodo:

You may have heard about the Federal Aviation Administration (FAA) quietly declaring that this year's Super Bowl will be a "no drone zone." You may not have heard just how big that no drone zone will be. It's 60 miles wide. The no drone zone is larger than the city of Phoenix. Seems a little bit absurd, huh?

That's because it's totally absurd.

The FAA is establishing what's called a temporary flight restriction that consists of several circles around the University of Phoenix stadium, where Sunday's big game is going down. The firsthas a 10-mile radius "in which general aviation aircraft, media, banner towers, blimps and unmanned aircraft will be prohibited." The second ring's radius extends 30 miles from the stadium and prohibits all aircraft that don't have a set flight plan, transponders on board, or two-way communication with air traffic control. Drones of any shape or size won't be allowed in either ring.

Just in case you were wondering what that 30-mile radius would look like in Phoenix:

By the way, there are already some no-fly zones in the Phoenix area, including two airports and an Air Force base. Those zones are teeny tiny compared to the Super Bowl's no drone zone, though:

And for context, this is what a 30-mile radius would look like in Washington DC, where DJI recently grounded its drones after a drunk government employee flew his Phantom onto the White House lawn. The zone would reach almost all the way to Baltimore:

Obviously, there are a lot of major safety concerns surrounding the Super Bowl. The FAA is not wrong for banning flying robots at such a high profile event, one that will be attended by tens of thousands and watched live by millions more. But imposing such a strict ban sends a message that the FAA is content to blow drone-related rules entirely out of proportion. This is disconcerting as the agency finalizes regulations on commercial drones, regulations that are reportedly pretty harsh and would require drone operators to get pilot licenses.

Nobody wants anything to go wrong at the Super Bowl. But if you really think about it, the FAA is setting a precedent that it will shut down the skies to even the smallest aircraft whenever it wants. Some Average Joe in Scottsdale—which is miles and miles away from the stadium—who decides to take his Parrot Bebop for a spin during Super Bowl stands to get in deep trouble for violating the FAA's absurdly large flight restriction.

The Super Bowl is a great American tradition. But this excessive ban doesn't sound very American at all. [FAA]

Not only are they the safest, quickest method of quickly taking a snapshot of an entire highly dynamic site, they significantly reduce surveying costs. Adding powerful structure from motion (SfM) software and virtual survey tools to the equation means no boots on the ground and no need for interrupting any operations.

Greetings!

Some time ago we’ve released a new version of our Linux autopilot - Navio+. Main new feature is that Navio+ supports HAT standard and is compatible with Raspberry Pi models A+,B+ and also with… Odroid-C1. It is a new board from Hardkernel powered by quadcore 1.5GHz CPU with 1GB of RAM. Odroid-C1 sets a new standard for performance - it is fast, 10 times faster than Raspberry Pi and faster than most of the single-board computers on the market. It also features EMMC storage for high performance memory operations. Another benefit of Odroid C1 is that you can build APM on it in just 45 seconds.  

Here are the benchmark results for Raspberry Pi B+ and Odroid-C1 made by intorobotics.com:

The full comparison article is here.

Besides DMIPS, very important improved metrics are system call overhead and context switching that will positively affect real-time capabilities.

We’ve added support for Navio+ and Odroid-C1 combo in APM. The porting was mostly straightforward thanks to the APM’s HAL and as we already had the drivers for Navio+. As Odroid-C1 is a new board, not all required system features were implemented and we had to do some tuning. Luckily, Hardkernel team is very responsive and great in communication and helped us solve the problems as we found them.

Most of the features are implemented for C1 such as toolchain configuration, build target, IMU, baro, GPIO driver, RGB LED etc.

But we won’t be kept without work, a couple of things are still left to do:

1. RT_PREEMPT kernel. The real-time patch doesn’t apply as smoothly as on Raspberry Pi’s Linux, so we’ll have to deal with that by manually applying the failed hunks.

2. RCInput. This is a tricky part on Linux, but on Raspberry Pi it was solved by using DMA. We can go that way too, but Amlogic S805 has quite a few other peripherals we can use - unlike BCM2835 it’s got a lot of spare timers that can generate 1us interrupts. Datasheet was only released a couple of days ago and we’re currently exploring the possibilities.

APM’s port for Odroid-C1 is available here:

https://github.com/emlid/ardupilot/commits/navio-odroid-c1

For now our main goal is to take Odroid-C1 into the air and we believe that many exciting projects will follow that will take advantage of incredible processing power.

Emlid team

emlid.com

From Postcapes: