Blogs

I am another one of the 12,000 suckers! Oh well...

To quote Chris Anderson: "DRONING IS HARD"

THE STORY:

http://www.bbc.com/news/34787404

NVIDIA's press release states that "Jetson TX1 is the first embedded computer designed to process deep neural networks -- computer software that can learn to recognize objects or interpret information." The 3.4x2inch module includes a Tegra X1 ARM Cortex-A57 processor with 256-core NVIDIA Maxwell graphics, 4GB of LPDDR4 memory, 16GB of eMMC storage, 802.11ac WiFi and Bluetooth, and Gigabit Ethernet support.

AnandTech Article: http://www.anandtech.com/show/9779/nvidia-announces-jetson-tx1-tegra-x1-module-development-kit

The Jetson TX1 Development Kit will be available for preorder starting Nov. 12 for $599 in the United States. The kit includes the Jetson TX1 module, a carrier board (pictured below), and a 5MP camera. The stand-alone module will be available in early 2016 (for $299 in bulk).

The Jetson TK1 (not TX1) was released in 2014 to encourage the development of products based on the Tegra K1 processor. However, according to AnandTech, developers were using the Jetson TK1 outright as a production board, choosing to focus on peripheral and software development instead of system hardware development. With the new TX1, all of the I/O connectivity is provided on a carrier board, enabling rapid development on the credit-card sized TX1 module. After development is finished, the TX1 module can be directly deployed in products, such as drones. 

NVIDIA used a drone application to promote the Jetson TX1

https://twitter.com/NVIDIATegra/status/664238535096926208

I recently came across this new camera from Seek Thermal, which is the extended range version of their previous low cost system. The manufacturer claims a range of 1800 feet, which makes it interesting (in my mind) for search and rescue applications. I had previously considered the original version from Seek, but with a range that was significantly limited, I doubted any practical usefulness. For standard ground operations, the use of a cellphone would be practical, but for aerial operations, I would be interested in a smaller Android based setup that could stream video. A board computer called UDOO may be an option, though I would have to investigate further. If anyone has familiarity with either of these products, feel free to chime in with your thoughts. Here is a video by Youtube user PhantomGuyTS (I have no connection with this person) showing the original Seek Camera mounted on a UAS as a proof of concept. 

ADAS , will this be the next generation of autopilot ?

The next step toward fully autonomous  UAV systems is based on acquiring and processing in real-time, information from visual (and/or other spectrums) surrounding space around the vehicle, and  sending  steering commands to the flight control unit so that navigating across an obstructed and ever changing environment without any external intervention might be feasible.

Real-time performance of embedded vision system is  a real challenge, as there is no single hardware architecture that meets perfectly the requirement of each processing level. We can categorise the different processing levels in computer vision as; Low-level processing that is characterized by Millions of repetitive operations on pixels on every seconds; Intermediate-level, is focused on certain regions of interest that meet particular classification of Thousands of objects on every seconds;  and the High-Level on which  object recognition , sensor fusion, decision making and application control are processed at a rate of hundred of operations per second.

At the current state of development, new generations of Systems On Chip - SoC-  that are tightly integrating Arm processors with Programmable Logic are particularly well suited to meet these requirements (1)(2). Multiples camera signals can be processed in parallel and with a very low latency within the programmable logic fabric of these Soc and the Intermediate and High level can be share between the FPGA, DSP, LUT and Arm processors within the chip. High level libraries and tools -like OpenCV- can be synthesized in programmable logic to build a customized accelerator that can be implemented with both higher performance and at much lower power consumption than a similar GPU-CPU model. Other technologies for this type of processing are available.  ASICs are highly integrated chips designed and built for a specific application. They offer high performance and low power consumption but manufacturing cost makes them unaffordable for low volume application. DSPs are very attractive for embedded vision systems, their capacity to do single cycle multiply and accumulation operations, in addition to parallel processing capabilities and integrated memory blocks.

A new generation of DSP, engineered specifically  for Advanced Driver Assistance Systems - ADAS in the automotive industry are now available. These families of SoC incorporate a heterogeneous, scalable architecture that includes a mix of DSP cores, vision accelerators, ARM Cortex-A15 MPCore and dual-Cortex-M4 processors. Texas Instrument and Toshiba have just released their own set of SoCs dedicated to this emerging market(3)(4). As an example, TI TDA2x SoC incorporates a heterogeneous, scalable architecture that includes a mix of fixed and floating-point TMS320C66x digital signal processor (DSP) generation cores, Vision Acceleration Pac, ARM Cortex-A15 MPCore and dual-Cortex-M4 processors. The integration of a video accelerator for decoding multiple video streams over an Ethernet AVB network, along with graphics accelerators for rendering virtual views, enable a 3D viewing experience. And the TDA2x SoC also integrates a host of peripherals including multi-camera interfaces (both parallel and serial) for LVDS-based surround view systems, displays, CAN and Gig Ethernet.

The TI Vision Software Development ToolKit  is complete with more than 200 optimized functions for both Embedded Visual Engine and DSP libraries, providing developers with the building blocks to jump start development and reduce the time to market. Additionally, both libraries are available for low-to-mid- and high-level vision processing. Integral image, gradient, morphological operation and histograms are examples of low-level image processing functionalities; HOG, rBRIEF, ORB, Harris and optical flow are key functions as a mid-level and Kalman filtering  and Adaboost are high-level processing functions.

Future development on these platforms can be implemented with OpenVX framework(5). OpenVX is an open, royalty-free standard for cross platform acceleration of computer vision applications. OpenVX enables performance and power-optimized computer vision processing, especially important in embedded and real-time uses cases such as face, body and gesture tracking, smart video surveillance, advanced driver assistance systems (ADAS), object and scene reconstruction, augmented reality, visual inspection, robotics and more.

So, next time you’ll search for an advanced autopilot to control your UAV, take a look under the hood.

References:

(1)http://www.xilinx.com/products/silicon-devices/soc/zynq-7000/silicon-devices.html

(2)https://www.altera.com/products/soc/portfolio/cyclone-v-soc/overview.html

(3) http://www.ti.com/lit/wp/spry260/spry260.pdf

(4)http://toshiba.semicon-storage.com/ap-en/application/automotive/safety-assist/image-recognition.html

(5) https://www.khronos.org/openvx/

I am not an employee of NVIDIA or Make. :) But I am using this promo as an opportunity to see if anyone has made progress on getting the Jetson TK1 airborne. 

https://developer.nvidia.com/embedded/makejtk1

The Jetson was released over a year ago. The community support has developed nicely since then. A custom kernel provided by users, and 'JetPack' (by NVIDIA) help to accelerate the setup process. I was able to get Jetson and Pixhawk talking via MAVLink by following the "Communicating with ODroid via MAVLink" wiki entry, without too many issues. 

http://dev.ardupilot.com/wiki/odroid-via-mavlink/

I have not yet flown with the Jetson. This development board is a bit bulky: approximately twice as big and heavy as the Odroid XU4 (XU3 and Jetson pictured). However, it offers top-notch performance for computational intensive tasks such as vision processing. 

Jetson/XU4 Weight:  120g / 60g

Jetson/XU4 Dimensions:  127x127mm  /  82x58mm

*Percepto's Indiegogo campaign proposed TK1-based hardware that is more down-to-size.

It is worth mentioning that DJI has recently released a companion computer based on the Jetson for their development copter. 'Manifold' is approximately the same size/weight as the Jetson development board, but with different I/O. 

https://developer.dji.com/manifold/

(image source: http://arstechnica.com/information-technology/2015/11/dji-tempts-developers-with-new-ubuntu-computer-for-drones/)

A short video on the basic concepts of the BoxBotix designs.   We are making some good progress and should have BBCopter, BBRover and BBPlane 3D files ready for release in the next month.  Minimum Viable Product (for you Lean Startup Fans) is a different beast with hardware, since we can't easily roll out bug fixes to a built product like you can with code.  So, while BBots may not be feature complete at v1.0, they need to be solid designs.

We have spent the last few weeks tweaking our 3D print settings to find a good combo of strength to weight.  Printing in ABS and getting some pretty strong parts.  Still heavier than what we can build in EPP foam, but there are also a lot more built in features to the parts.  Still need to do more testing with these versions before we can provide any solid data.  Leaning towards using the CERN Open Hardware License once we release the files.

Enjoy!

Coby

In September 2015 Geoscan engineers together with Saint Petersburg State University glaciologists finished the second part of expedition devoted to the researches of Potanin and Alexandra glaciers of Tavan Bogd mountain range in Mongolia. Researches were held with the support of Russian Foundation for Basic Researches and Khovd State University of Mongolia.

Read the full story and view Tavan Bogd 3D model on GeoScan site: http://geoscan.aero/en/node/189

Erle Robotics has taken much from this open hardware environment that has been created around the Dronecode Foundation. There are many individuals and groups that helped or contributed in some way and among them i believe it's worth mentioning two groups:

• The PX4 team led by Lorenz Meier which has truly been an inspiration for many. Their hardware designs have had a huge impact and he PixHawk Fire Cape 2.0 has the spirit imposed by the PX4 designs.
• 3DRobotics as the enabler of this open drone reality. 

With all this in mind, I am happy to announce the PixHawk Fire Cape 2.0 (PXF 2.0): an open hardware multi-platform shield to build Linux-based drones. The naming, has been selected honouring Philip Rowse who initially designed the first PXF concept (which on his own based this work in the PixHawk itself). Although we won’t be retailing this board directly we will be offering Erle-Brain 2, a commercial solution based on this board. Sources are freely available at https://github.com/erlerobot/PXF2.

Designs are out there for people to hack and contribute back.

*** Note this Blog post was done a long time ago, this is no longer needed with the latest Solo updates. Current Solo firmware will trigger the GoPro during an auto mission correctly, and the cam trigger messages on the data flash logs can be used for geotagging the images via mission planner or directly in software like Pix4D ***

There have been a lot of questions about how to this in several forums, I posted a solution a while ago on the Facebook Solo Mod Club page, but with all the demand I think I should also post it here. 

First understand that this is a hack that modifies some files inside the Solo and that you may or may not need to do a factory reset before you upgrade to the next version of the firmware which seems it will contain something similar to this modification. So do this at your own risk and only if you know what you are doing. 

From the comments bellow, I think this explains it better:

"With the current Solo update system, user modified files will not be updated during a software update. To get the update, either a patched version of the new file will need to be manually installed (taken from a "clean" updated copter) or a "factory/settings reset" needs performed to get the copter back into a clean state before updating.

As with any software mods, it's always best to back-up the original file before modifying it (use something like "cp file.py file.py.date.back"). The backup can then be restored before a software update and then the updated file can be patched/modded again." -- Angus Peart

The Pixhawk firmware in Solo already has everything that is needed to trigger the GoPro for survey missions. It has the logic to trigger the GoPro based on distance or by using a explicit trigger waypoint. What is missing is for the companion computer inside Solo to interpret this messages and send a command to the GoPro to take a picture. This is what my mod does. Also it creates a log file for each flight where it stores the positions of any still pictures you take with the GoPro, not just during surveys, but anytime you trigger a still. 

Here are the steps:

1. Connect your computer to the Sololink WiFi network

2. Use an FTP Client to connect to Solo (root:TjSDBkAu@10.1.1.10)

3. Make a backup of /usr/bin/shotManager.py

4. Replace /usr/bin/shotManager.py with this file:

shotManager.py

5. Reboot you Solo

From now on whenever the Pixhawk sends a trigger command the Solo will trigger the GoPro and take a still. If the GoPro is in video mode it will switch it to still, take a pic and then put it back to video. Please note that everytime the GoPro takes a still you will loose video or see artifacts on the video. This is normal, and is related to how the GoPro works. If you fly too fast the GoPro may not respond to the trigger commands fast enough. Also if it has to switch between video and still it will take longer to take a picture and you may miss pics. So set the camera to still mode before starting the flight.

Once you have finished your flight you can use FTP to pull the georef log file from the solo. You should find them in /log/geoRefxx.log where xx is the number for the log and is incremented each flight. Have fun mapping with Solo.

PS. The picture above uses something similar but with the QX1 Edison Camera trigger on an earlier article I wrote. Since Solo is Pixhawk based you can use that too.

I wrote an article on how to decode MAVLink messages using a Swift based Xcode project.  This is of interest if you’re attempting to write your own ground control station software for the Mac (or iOS).

A full sample Xcode project is available from my GitHub. Screenshot of the app below.

Cheers

Michael Koukoullis

Drone aficionados, 

In what has now become a weekly update for our KickStarter campaign I'd like to show you a demo of the Easy Drone XL Pro autonomous flight using  3DR Tower app. Hope you enjoy!

By the way - we are ninety two percent funded at this point and are expecting to reach our goal in the next few days. You can check out more details on Easy Drone and the campaign here: 

The PX4 development has in the past been focused on smaller planes and wings not requiring a runway, but with lasers available for some time now it adding runway support made sense. We focused on high accuracy, as can be seen in the video. The plane is nice composite model and a Kickstarter project, the Albatross UAV.

Listening to the feedback provided recently we (at Erle Robotics) have decided to start new batch of releases about the  Debian-based operating system that our brains wears. The image includes:

• Latest APM binaries for copter, plane and rover included (service launches copter by default)
• mavros preinstalled and launched at init setting up different bridges for additional ground control stations.
• ROS Indigo preinstalled and launched at init
• Integrated camera images available directly through a ROS topic.
• Different lasers, lidars and RGB cameras supported (additional devices supported).
• WiFi hotspot mode preconfigured on wlan0 network interface with DHCP. The default SSID is erle-brain-2 (more)
• WiFi infraestructure mode preconfigured on wlan1
• Zeroconf stablished to be able to reach the brain through erle-brain-2.local from different connections (more).
• Graphical User Interface (GUI) (more)
• ROS 2.0 support (read more).

SkyFy Technologies is proud to announce a we have conquered an amazing engineering challenge for drone inspections! We we believe in capturing data without losing quality, so we worked with our partners to develop a new craft and camera combo with increased stability for stabilized 50x optical zoom. The meticulously designed craft offers increased stabilization which allows the zoomed image captured to have increased clarity. We are now able to capture distant data that is typically difficult to obtain at a very high quality.

Our ground breaking inspection technology is now available in for inspection services in Canada under our SFOC.

Further information can be found at SkyFy Technologies

Hi,

Willing to try out APM antenna tracking, I needed to procure myself with a mechanical servo based pan-tilt system.

This video is both a build log and a kind of "how-to" antenna tracker build guide for those who want to try build their own.

I logically first started to look around to purchase one; my market research basically resulted in solutions that I found way too expensive for what they really are : aren't we are just talking about two servos driving a pan and a tilt plate?

However, you'd have to spend a few hundreds dollars for a complete ready-to-run pan/tilt that is able to rotate medium size antennas (for example: 350+ dollars @servocity or 200+ dollars with required accessories and 180° servos @readymaderc - without shipping, EU sales taxes, or EU custom fees).

I found it really hard to source  a "1 turn" servo (there is only one model that I know of : GWS S125 but it does not seem to be produced anymore) or even a half-turn 180° servos. Most of them are standard 90° servos that were opened up to modify their internal potentiometer to extend their rotation to 180° (lots of tutorial videos on youtube explain how to do this by yourself). Alternatively, you could buy programmable digital servos but you will end up paying a high premium for them and, in addition, you will spend extra money on their proprietary programmer devices.

So the question is, is it possible to build your DIY tracker with parts you may have laying around the bench, for a very low cost ? Answer is yes, and the task can be greatly facilitated with the help of a few 3D printed parts.

I now can't wait to plug a pixhawk+GPS module on it and experiment with APM antenna tracking firmware, which will be the subject of another future blog.

PS : Here are the STL files of all the 3D printed parts used in the making of this tracker, to share with the community: Antennatracker.zip

Cheers,

Hugues

I have two hobbies: beekeeping and building/flying multirotors or drones. There is rarely any overlap between the two but recently I have noticed a spate of YouTube videos with titles such as:

• Bees Attack Quadcopter Blades
• Angry Swarm of Bees Attack Drone also see Angry Swarm of Bees Attack Drone
• Quadcopter Attacked by Swarm of Bees
• Quadcopter/Drone attacked by Swarm of Bees
• Swarm of Bees Attack Drone. Bees vs. Drone
• Ar Drone Bee Attack!!
• FPV Drone Attacked by Drones Swarm Africanized Killer Bees Attack Guarding Queen

Some of these videos are picked up by the media and further sensationalized. Too bad they all get the story so wrong. These bees, drones actually, are not angry. They are simply horny and they think they found a virgin queen worth dying for.

For those readers new to honey bees, I offer this quick summary of honey bee biology. Honey bees have three castes or forms: sterile females or workers, males or drones, and typically a single reproductive female or queen. A queen's job is to lay eggs. She can lay up to 1500 eggs a day for several years. But first, she needs to copulate with about 12 (plus or minus 7) drones because she will never mate again once she starts laying eggs. Drones are flying penises. They carry genetic material. That's about all they are good for. They don't even have stingers like the girls do. Most drones will never mate with a queen but when they do, they do it in the air, the drone has his gonads ripped out of his body, and he falls to his death. Satisfied, I hope. The workers handle every other task: feed the queen and growing larva, put away honey, build out wax comb, fill cracks with bee glue, take out the dead, guard the entrance, warm or cool the inside of the hive, and forage for food.

What all of these videos show are drone congregation areas or DCAs. These are areas where drones from different colonies gather in hope of mating with a queen. A DCA is typically 10-40 meters above ground with a diameter of 30-200 meters. The utility of a DCA is that it provides an efficient way for a queen to acquire genetic material from outside of her own colony. Inbreeding is bad for any species.

DCAs have been known to persist in one geographic location for 12 years. This is curious because drones do not survive the winter as workers do (the girls kick their brothers out of the hive each Fall) so there must be something intrinsic in the area itself to attract drones from multiple colonies to the same place year after year. Yet another honey bee mystery waiting to be solved.

Drone congregation areas are not rare but their discovery is rare. They are normally discovered in urban areas by observing a number of dead drones on the concrete or asphalt. Balloons and kites with suspended nets and pheromone lures have been used in the past to study DCA but perhaps multirotors could offer a better research platform, eh?

How can I be so sure that these videos are of drone congregation areas?

• If you step through frames, you will see that these bees have rounded bottoms - that is the stingless abdomen of a drone.
• Workers have no reason to congregate above tree level because there is no food there. They may fly above tree level to reach a nectar source 3 miles distant but they do not tarry nor do they travel in packs.
• I know, I know, that's not what happens in the movie "Deadly Bees" but honey bees away from their colony are not aggressive. They will defend their colony and themselves but they do not attack unprovoked. Honey bees are vegetarians, for Pete's sake.
• The buzz of a multicopter may attract the horny drones in a congregation area. But I have flown my multirotor within a few feet of three busy hives - seeking to solicit a response - but the worker bees showed no interest or aggressive behavior at all.

For more information:

• Landscape Analysis of Drone Congregation Areas of the Honey Bee, Apis mellifera
• Of course of you really want to see bees attack a drone and a news crew, there is none better than this report from CNN's Jeanne Moos.

Words fail me. But not Hackaday:

At first we thought it was awesome, then we thought it was ridiculous, and now we’re pretty much settled on “ridiculawesome”.

Bitdrones is a prototype of a human-computer interaction that uses tiny quadcopters as pixels in a 3D immersive display. That’s the super-cool part. “PixelDrones” have an LED on top. “ShapeDrones” have a gauzy cage that get illuminated by color LEDs, making them into life-size color voxels. (Cool!) Finally, a “DisplayDrone” has a touchscreen mounted to it. A computer tracks each drone’s location in the room, and they work together to create a walk-in 3D “display”. So far, so awesome.

It gets even better. Because the program that commands the drones knows where each drone is, it can tell when you’ve moved a drone around in space. That’s extremely cool, and opens up the platform to new interactions. And the DisplayDrone is like a tiny flying cellphone, so you can chat hands-free with your friends who hover around your room. Check out the video embedded below the break.

On the other hand, for a human-computer interface, we have to say that the examples they picked just aren’t a good fit. For instance, have a look in the video where the drones are used to represent files in a directory (42 seconds in). Either there are only three files in the directory, or they ran out of drones. And rotating through the three is a bit slow because the physical drones have to fly to new locations to select a file. We’re thinking of that directory with 200 photos that we just downloaded from our camera.

The section of the video where they use the three ShapeDrones to stand in for a 3D physical model (52 seconds in) is awesome again. The user positions the drones in space, and they hover there and presumably this moves around some part of a 3D model in a computer somewhere. We love it. But again they run into the difference between virtual and real; three voxels, even if they are very elegant and in RGB color, isn’t enough for any serious modeling. Even a modest real-world project is going to take a fleet of these things, which would be fantastic but incredibly expensive.

Finally, epitomizing the simultaneous awesome and head-scratching of this project, they translate the pinch gesture (to enlarge or shrink an image) from the touchscreen to the real world (1:52 into the video). That’s super cool in principle, and we love the movement. But in the video, the demo guy nearly gets hit on the shoulder by the third pixel shrinking inwards toward the other two. We’re imagining a user with long hair and a model with many more copters. The horror!

In the end, using an interaction design term, the virtual and physical worlds have different affordances, and that’s a physical fact that the project either tries to blur or ignore. Quadcopters aren’t pixels: you can’t have a million of them, and even if you could they’re slow to reconfigure and harder to manipulate. That said, something beautiful has been designed here, and we’re absolutely sure that there’s an application out there that fits it.

So, for navigating files, we’ll stick with the mouse. But we totally want a room full of flying RGB cubes!

I had quite a hard time configuring APM::Plane to only have an altitude deck so that if I fly too low, AP takes over and goes back to a safe altitude.

I think I also hit at least one small bug in the code in the process (you cannot set a minimum altitude without setting a maximum altitude too).

Either way, I documented it all here:

http://marc.merlins.org/perso/rc/post_2015-11-06_Using-Ardupilot-Geofencing-As-An-Altitude-Deck.html

Three years ago, it was the biggest campaign in Indiegogo's history, having raised $1.14 million. Today, the Robot Dragonfly project is officially dead, having never overcome technical issues. 

Most of the other crowdfunded drones are delayed, too. Hexo+ (due out in March 2015), looks on track to be about a year late. Airdog is a year and half late. Sprite is just a few months late so far, but it looks like there's a long way still to go. Etc. Drones are hard. 

As an extension of a drone based Ground Penetrating Radar (GPR) project the idea arose if it were possible to have a drone based metal detector.

I thought the idea silly at first but the initial numbers did not rule it out and extensive handheld testing with military grade detectors on real ordnance showed the idea may have some legs after all. If not for minimum metal AP mines, at least for the bigger stuff.

We settled on some standard detection electronics & coil which were customised and integrated with a H500 quadcopter testbed.  The first test flight showed we were definitely able to pick up the detections from relatively small (tennis ball size) metal objects.

Though this proves the core concept it is of course a long way away from being something that can be operationalised (if that makes sense at all), many challenges remain. In any case given the time and budget constraints it has definitely exceeded my expectations and has been a fun project so far,