Hein is a long time friend on DIY Drones.

Just want to show his work to you.

Hein.... I did not finished my Skywalker but obviously you did.

These pictures are awesome. Thank you!

-Eric

From TTRobotics

Hydrodynamic Design
With professional hydrodynamic design, SEADRAGON can be freely in the water, underwater hover or free exploration can be easily implemented. The main compartment is airtight and cylindrically designed to protect important electronic equipment from moisture. Built-in huge capacity of battery offers longer run time (external power source as option).

Live 1080p HD Camera
SEADRAGON uses CUDA cores for real time vision and sensor fusion. You can use on-board cameras to do real-time HD video streaming of the underwater adventure.

Ideally Unlimited Control Distance (4G application)
SEADRAGON offers wired or 4G / LTE signal control. Provides end-to-end encryption with mutual certificate-based authentication and Video streaming function from multiple on-board cameras. You can control your SEADRAGON directly from your browser in any location.

Underwater Thruster Designed Specifically for Marine Robotics
Main tank body can adjust the counterweight to different environment of sea and fresh water. The brushless electric thruster system allows SEADRAGON to move quickly and quietly with a maximum forward speed of up to 2 knots.

High Scalability and Programmability
SEADRAGON uses Pixhawk autopilot chip, which can be programmed in Python (w/OpenCV) language. High compatibility and high scalability, you can customize the way you use SEADRAGON and build your own automated applications.

Tanizon Tech, a Chinese company focused on UAV solutions for photogrammetry and precise agriculture, was established in 2016 by a group of scientists as well as drone zealots.

Their 3-step vision is to promote civilian drone to become:

• Carrier of high-spatial/temporal resolution data service;
• Efficient first/last mile logistics solution; 
• Eco-friendly medium-to-short distance PATS (Personal Airborne Transportation System).

Tanizon targets the high-end photogrammetry market with rigorous requirements on both accuracy and efficiency in the current phase of their vision. Their recent announcement of the 5kg-payload-capacity/1-hour-flight-time hexacopter has precisely fulfilled the market demand of efficient, multipurpose, reliable and affordable multi-copter platform. 

Meanwhile, Tanizon also announced a 5-lens camera system, featuring with 120 MP, USB 3.0 data transmission, high-speed shutter, and many more for the most rigorous requirement of tilt-photogrammetry or aerial 3D-modeling.

By integrating one of the most efficient UAV platform and Tanizon 5-lens camera system with RTK GPS and high-precision IMU. Tanizon brought an astounding aerial photogrammetry solution to the market. Here are some modeling results they has achieved so far for their Chinese mainland customers.

For more product information, business collaboration, or investment, please visit  www.tanizon.com

or contact sales@tanizon.com

Product Description

LEAD TIME: 60 days (due to post-CES orders peak) + 2 days international shipping

REDUX: same as BASE1 Rover, but reduced computing performance.

BASE 1 STACK

BASE 1 is an advanced and complete stack to remotely control unmanned vehicles. By elevating control capabilities to an higher base, it’s a solid starting point to create new services, projects and applications.

• Cloud Station Gateway (for browser-based control, connect your vehicle here)
  • Remote commands (e.g: GoTo, Takeoff, Dive, Set Mode)
  • Remote file transfer (including: Neural Networks, Groud Truth, Python Scripts, MAV Mission Files)
  • Remote triggers (Neural Networks, Python Scripts, Auto Missions)
• Languages: Python (w/ OpenCV)
• Self-Driving-Rover Sample Neural Network
• Deep Learning Frameworks: Caffe, Tensorflow
• Gstreamer, MavProxy, MavLink
• Ubuntu 14.04 LTS

BASE 1 HARDWARE

• Main BOARD:
  • ODROID XU4 OCTA CORE
  • 4G/LTE External Modem
  • 16 GB eMMC
• All wired, turnkey.

TT-ROBOTIX ROVER VEHICLE

• Weight:  8.1kg
• Dimensions:  531mm x 418mm x 321mm
• Maximum Payload:  15kg
• Max Speed:  18km
• User Power:  AC 110V, 5V, 12V
• Runtime:  2 hours with 4s Batteries
• Modular structures – perfect for development, simple for production
• Precise actuators – for smooth movements in small spaces
• Wide case – for agile sensors / boards placement; batteries for long travels and more
• Network Technology:  4G/LTE and Wifi ready
• Independent Power Source for Electronics and Motors
• Translucent front glass, for visual inspections
• Modular roof, with several sensors-mount possibilities (including cameras)
• Pixhawk (or any other ArduRover autopilot)
• Logitech HD 1080 Pixel camera (h.264 native, Zeiss lens, autofocus).

PERFORMANCE VIDEO

Hi guys, let me introduce the final version of my 3D printed FPV racer. Since the last blog entry I made some further small modifications according to my experiences. All files can be downloaded from the project GrabCAD page.

Since there is still some CG issues because of the banked motors, I suggest to use 2-blade props on front and 3-blade props on back motors. Flight characteristics is excellent with this setup.

The final version is printed of Polymaker Polymax PLA, it has similar mechanical properties than ABS but can be printed without hazardous vapour exposition and also heated bed not required when BUILDTAK is used. 

This is the parts list of my final build:

• BeeRotor ZoeFPV 1806 2900 KV motor + 4" props
• BeeRotor 20A ESC (or similar, max. dimension: 24x13x6 mm)
• BeeRotor F3 Flicht Controller (any FC can be used with 30x30 mm hole spacing, but maybe USB port will be covered by frame)
• BeeRotor PDB V2.0
• G-Top FGPMMOPA6B 10Hz GPS Module (for lost model finding through HOTT telemetry)
• 200 mW Aomway 5.8 GHz Video TX + antenna 
• miniature transmitter RX (I use naked HOTT GR-12
• HS1177 camera
• Lipo battery - 1300 mA 4S 75C TATTU and Wellpower
• 12 mm of diameter, 5V buzzer
• led stripe

I used this printer setup for Polymax PLA:

• 3 layers all around (top/bottom and perimeter)
• 40% infill (3D honeycomb)
• 215 C print temperature
• 0,2mm layer height
• Manual Support

I wish you Happy New Year with plenty of succesful landings!!!

Regards,
Adrian

PS.: as always, use my design on your own risk!!!
If you think my work useful and would like to support the prototype building, you can donate by paypal (nhadrian@gmail.com) or any of the components listed above are wellcome.

*****UPDATE*****

A friend of mine asked me to do a variation with flat motors and 25 degrees camera angle.
I uploaded the STL files here.

Great news from Don Lake

Announcing the release of QGroundControl V3.1. Notable changes in this release:
- Survey mission support
- GeoFence Support in Plan View
- Rally Point support in Plan View (ArduPilot only)
- ArduPilot onboard compass calibration
- Parameter editor search will now search as you type for quicker access
- Parameter display now supports unit conversion
- GeoTag images from log files (PX4 only)
- System health in instrument panel
- Mavlink 2.0 support (no signing yet)

Updated docs and install instructions are here: https://donlakeflyer.gitbooks.io/qgroundcontrol-user-guide/content/11

It is the beginning of 2017 and drones, and their related technology, are coming off an explosive year of growth in both popularity and innovation.  The FAA estimates that 2.5 million consumer drones were unwrapped during the past holiday season.  To further prove the popularity growth, the FAA also announced that there are currently more drones registered through their registration program than there are registered manned aircraft!  Today’s consumer drones are now capable of capturing images that are equivalent in quality to DSLR camera systems and include sensors that allow for active collision avoidance. 

Because of the rise of the consumer drone, more people are beginning to realize the endless practical uses for this technology.  However, while that is indeed true, there are people and companies in the industry who pioneered the technology.  Long before companies like DJI or 3D Robotics had even formed, there were individuals building versions of what is available now at your local Wal-Mart.

One of those companies is Advanced Aerials Inc., based in northern Virginia.  Advanced Aerials was founded in 1994 by Bert Wagner.  That is almost twenty years before the release of the first DJI Phantom!  Bert founded Advanced Aerials because he recognized the need for a more affordable method to photograph properties from the air.  With that goal in mind, he set to work building his first aircraft which  consisted of a gas powered RC helicopter and a 35mm film camera.  There were no programmed flight controllers and the radio used operated on the FM band.   The entire setup was hand built and required some serious skill to operate.

Advanced Aerials went on to provide aerial images for many customers.  They were the first company to work hand in hand with the Metropolitan Washington Airports Authority and photograph Dulles International while it was operating.  Yes, while planes were taking off and landing.  They provided aerial surveys for construction companies as well as property developers.  As the component technology improved, so did Advanced Aerials aircraft.  With the improvement in available components, Bert began to envision his aircraft being used for more than providing pretty pictures.  He wanted to make a difference, contribute something meaningful.

That leads us to Advanced Aerials today.  Bert and his team have become a leader in rapid prototyping UAV technology for a customer whom they have served for more than fifteen years.  Working with their customer, Advanced Aerials are working hard to design products that will save lives.  Much of what they work on cannot be described here.  Suffice it to say that the range of products they have built so far will be put into use by soldiers and first responders and will result in many lives saved.

Advanced Aerials is an example of a company using today’s technology to provide innovative, easy to use systems for more than photographs or fun flying.  They, and companies like them, are the future of drone technology.  With their help, we will see a myriad of products that will secure and enrich our lives.

Do you have an idea that you would like to see in working form?  Advanced Aerials welcomes all inquiries from potential customers who want to see their ideas come to life.  They can be reached via their website, www.a2usa.com

 Parrot/Pix4D Climate Innovation Grant Deadline of Jan. 31st

Grant Guidelines

To submit you application, go to at edu.parrot.com/climate 

Background – The overarching goal of this grant program is to foster innovation in our understanding and mitigation of the impacts of global climate change. The award will consist of drone hardware and software for field research. Competitive proposals should include an aerial geographical/mapping dimension using UAVs and Pix4D photogrammetric software, as well as multispectral imagery related to the technical capabilities of the Parrot Sequoia camera. Applications are open to researchers across a range of disciplines, from archaeology to zoology. Proposals that integration drone technology with existing long-term experiments and studies are highly encouraged. 

Eligibility – Grants will be awarded on a competitive basis, judged on novelty, scientific merit and team experience. Applicants are not required to have advanced degrees. However, advanced degrees, formal association with educational organizations or institutions, and a strong record of climate change research will be ranked accordingly. 

Proposals are not restricted to location — Worldwide applications will be considered, though applications should be submitted in English only. Only one proposal will be accepted per applicant. 
This grant program does not provide financial support, nor does it offer scholarships or fellowships of any kind. Awards consist of a single drone package (hardware, software, and basic introductory training as needed). Grantees will be solely responsible for understanding and meeting country-specific UAV regulations for research use at a given field locality (e.g. Part 107 in the United States). Additional terms and conditions related to the proper use of drone hardware may apply. 

Grant award specifics – Each award winner will receive an aerial mapping kit that includes a single multirotor drone (3DR Solo or similar), 2 extra batteries, one Parrot Sequoia camera, Sequoia integration cables, and 6-month licence for Pix4D (totally ~ $6500 USD value). Drone hardware and software support is intended to function as complementary support. The award committee strongly encourages applicants to seek additional, concurrent funding from your organization, university or other funding agencies. 

Project communication expectations – Successful teams will be expected to coordinate with Parrot to communicate and promote their research and through Parrot social media channels on a regular basis throughout the duration of the project. Please submit a two-page proposal along with your resume or academic CV by Feb. 1, 2017 to be considered for this grant. 

Go to edu.parrot.com/climate

On the right our very first prototype, on the left our latest protoype.

Very early test of concept. Testing 3D printing for the first time.

Prototype version 2. Very early development.

Our first fully functional prototype a long time ago with fully functional checkpoints algo.

Electronics PCB ofthe first fully functional prototype. Soldered by ourselves by hand.

The first fully functional prototype already mounted. Large and ugly.

Link of our Droiko on Kickstarter: Kickstarter Droiko

The autopilot on the blimp is enabled whenever the hardcore 80s music is playing

RC Blimp with Rapsberry Pi +Navio2 and autopilot algorithm written in Go: 

True Story Follows

A few years ago I worked on an autopilot module for a blimp and subsequently presented a PyCon talk about it. Like any developer looking back on previous works, I think the code was horrible and the talk could have been more substantive as well. The lime green Hawaii shirt, however, I have no regrets about. Sometimes I wear it to work and people tell me that they can’t hear what I’m saying with how loud my shirt is. It is true, I have even louder shirts that my wife got me for Christmas, including some wicked tie-dye and some absurd dye-sublimation designs.

Fast forward a few years, and everyone on the streets is clinging to Go as the hottest new programming language. So when I tried picking up Go, it was somewhat challenging because I had no practical reason to learn. My project at work will be stuck as a Python project until we undergo the deliberate and painstaking effort to re-write it in a compiled language. This effort to learn the language coincided with a desire to go back to the blimp project and revive the effort to bring it to a reasonable conclusion.

The Shortcomings of Last Project

The largest pitfall of my last endeavor to create an autopilot for the blimp was that it was not easily reproducible. I bought individual sensors and had to wire them up to a separate singleboard computer, and I had put together a laser cut acryllic design to house all the pieces. Then there was corresponding nylon screws and bolts to mount evertyhing. If I ever wanted to create a multitude of autopilot modules, this would become a painstaking and problematic effort for something that was a side project and a hobby. And obviously, the end goal is to deploy thousands of autonomous blimps to rule the skies, so an unscalable solution was not a solution at all.

The other project, while capable of basic flight, was not that great, which was amplified more after working on my current project. Calculating a compass heading, for example, relied on sterile conditions where the aircraft was completely level in the skies, which is obviously not a valid assumption. Otherwise, the basic ideas of flight were reasonable.

And finally, the last project lacked a reasonable user interface. I put some stuff together with OpenCV, but it was nothing that looked professional, and nothing to help diagnose any problem going on.

The Go Re-Write

I re-wrote the entire autopilot algorithm in Go from Python for a few reasons.

My first concern was how to go about reading from sensors. This pretty much required C++ usage, so I could either write everything in C++ or just use a language that was easily compatible. Go is advertised as a language that can do this, and the final implementation proved that this was relatively straightforward.

Another concern which was later validated is that the autopilot would be a multi-threaded environment. I didn’t want some sort of whacky scenario where the serial port blocked for a prolonged period for whatever reason and subsequently prevented the autopilot from controlling the aircraft. The only scenario in which some sort of crash would be desirable is if Kraft foods hired me to paint a 30 foot blimp like the Kool-Aid guy and have the blimp ram full speed into and through a brittle wall. Go is a reasonable language choice for an application with multiple concurrent processing tasks, and while it’s fairly obvious that motor control, computing waypoints, reading from sensors, and reading from user input could significantly benefit from executing independent of each other, it turned out that my autopilot implementation was inherently asynchronous in virtually all aspects, and combined with the long lived nature of the program, Go proved to be an excellent choice.

The last reason to use Go was for the simple matter mentioned above that I need to learn Go, in part because I want to, and in part because it’s being used frequently at work so I should at a minimum be able to intelligently understand Go code and ideally be able to write my next project using it.

And finally, another point in Go’s favor was that it would be faster and use less resources. I’m not necessarily concerned with either, but faster code is always good and in this case may be able to enable better navigating with higher frequency computation. Additionally, if I can use less compute resources, I can use less battery and therefore prolong flight time.

Requirements and Features

In its current state, the blimp is not yet 100% complete, but the bullets enumerated below represent either a completed feature, an implemented but untested feature, or a feature with a small enough scope that it’s safe for me to promise its completion.

• A client laptop is assumed to work in conjunction with the autopilot.
• Blimp will take off vertically and hover until waypoints are specified
• Communication range between laptop and blimp is a function of the XBee modules used (the ones I’m using can work about a mile away if there’s line of sight communication)
• Feedback from the blimp, such as target heading and output sent to the aircraft’s servos and motors, is passed back to the client; this proved invaluable for testing and diagnosing problems.
• Waypoints are specified in real-time by clicking on a map on the user interface (it’s assumed the client laptop has internets)
• Waypoints can either be consumed as the aircraft reaches them or the aircraft can simply loop through all waypoints continuously
• In the event of lost communication, the blimp will immediately shut off its motors and pitch downward
• The compass needs to be re-calibrated whenever the geographic region changes; we can’t all live in the Bay Area. Calibration starts and stops with the press of a button on the user interface, and the autopilot module just needs to be rotated in all directions until a reasonable heading is established.
• When not actively flying, the user interface has buttons to individually test pitch, yaw, thrust intensity, and the thrust vector
• PWM min and max ranges (which can vary by servo or electronic speed controller or can have different ranges based on aircraft nuances) can be adjusted on the client side
• Blimp will cruise at 5 miles per hour to minimize power consumption; blimp will slow as it approaches a waypoint.
• Blimp will fly 25 meters above ground level

Major Parts List

• Blimps built by EBlimp
• Raspberry Pi
• Emlid Navio2 Sensor Hat
• 4x Xbee Pro Series 1 (dedicated transmit and dedicated receive channels)
• SF11-C Laser Range Finder

Mistakes in Current Implementation

It is true. Even The Lobbdawg makes mistakes. From the initial flight test, there were a few noticeable problems.

Forward speed is embarrassingly miscalculated depending on the quadrant the azimuth of the blimp lands in. This caused speed to be represented as a negative value, which then caused the blimp to compensate and try to increase speed. And now, the blimp would fly too fast, like the gazelle.

The algorithm for hovering was based entirely off of incorrect assumptions. The idea was that if the pitch of the blimp is 0 and I can keep the pitch of the blimp at 0, then I must be hovering. This assumption is incorrect, but it’s also very difficult to take off in a hover based on this sort of flight strategy.

The determining factors for thrust intensity are also currently incorrect. The idea was that the thrust vector for the motors should always be at a neutral (roughly 45 degree) angle, and altitude would be controlled by the tail elevator. Therefore, while the motors would still provide upward thrust, I only adjusted the thrust intensity based on the current forward speed of the aircraft. This created the problem that if the blimp was flying too fast, the motors would shut off, and the blimp would slowly descend in altitude while the tail elevator and rudder couldn’t direct the aircraft as well with the reduction in power.

Finally, in some cases during flight, control of the motors was completely lost if a preceding operation kept the motors powered down. While I’m still speculating somewhat here, my guess is that the PWM update frequency should happen at 50 hertz. Currently, the update frequency is directly correlated to sensor read frequency.

What Went Well

While the test flight to me felt like a failure, it certainly wasn’t because I learned enough to know how to correct the problems. On top of that, it was easy to take for granted some of the now proven assumptions. Primarily, the math used to calculate output to the tail elevator and rudder proved to be spot on. The blimp was able to fly directly to waypoints and cut directly through the target. If the blimps can be considered arrows, then you could consider me to be Robin Hood, but only in the sense that I can shoot arrows really well. Not in the sense that I’d steal money because I don’t want to go to jail. Also I think Robin Hood dies in the end.

But I digress. The point is, pitching and yawing is based on the idea that we have a curent angle (in either the pitch or the yaw plane) and a target angle. From there, we have a target angular velocity. Based on the current angular velocity, we can then output a corresponding intensity percent to the motors. As a result, we can safely compensate for things like wind, and we can counter intuitively pitch or yaw in the opposite direction of the intended target if the aircraft is spinning too fast.

Another point to put on the scoreboard is the effort in putting together all of the details in the user interface proved incredibly fruitful. While some of the view data was based on an idea of putting something cool looking on the display, it ended up helping to diagnose and reveal the problems mentioned above. Had it not been for the user interface, I would only be speculating and postulating what the problems were.

What’s Next

Put simply, I’m going to fix the problems listed above. They’re all fairly straightforward to address except the problem around thrust vector angle and thrust intensity.

After thinking it over, I’d like to rework the flight algorithm differently. Blimps are notoriously a combination of flying a helicopter and flying an airplane (you could think of these RC blimps as a crossover between an MH-53 Pavelow and an F-14 Tomcat, the performance characters are comparable), so it ends up making sense to simply decouple those respective components and let them operate entirely independently. In practice, they’ll be coupled together by happenstance and equilibrate to an ideal flight configuration. The current algorithm for controlling altitude is based purely off of pitching the aircraft up or down through the tail elevator. This is fine; now, the motors should operate independent of the elevator to help manage altitude and forward speed.

The thrust vector will be computed first. I know I can already ascertain a target upward velocity to reach a target altitude, and I can already ascertain a target forward velocity to reach a target forward speed. Throw some arc tangents into the mix, and now I can get the ideal thrust vector to apply forward and upward forces in the correct proportions. Now I can just offset the resultant angle with the current pitch of the aircraft to apply forces in the perfectly correct directions.

Finally, thrust intensity can be computed in a similar way; get the required forces to apply in the forward and upward directions, and the final force applied will be the square root of the sum of squares.

This sort of approach I think will end up creating a very elegant flight pattern. Target speed can also take altitude into account, where target speed will be a function of the current implementation of target speed interpolated against the current altitude relative to the target altitude. In plain English, the blimp’s target forward speed will increase from 0 to max as it ascends, which will end up causing the blimp to rise vertically and then gradually speed up as it reaches a safe altitude.

In normal flight where the blimp is flying straight forward to a target destination, the thrust vector will have reached perfect equilibrium with maximal efficiency to distribute upward and forward forces (in practice this means that the thrust vector will be at or near parallel with the blimp’s air frame).

Author's blog

Episode of Drone Dish profiles Ryan De Seixas, one of the top aerial videographers in Hawaii,  

Drone Dish Profile of Ryan de Seixas

Displaying both manual and autonomous modes. Wow!

Sometimes there's just no good place to mount the external LED to on a copter or one simply wants more light output... While developing my own little light controller, I wrote a decoder which decodes the I²C control signals for the external LED and controls arbitray amounts of Neopixels accordingly.

NOTE: Never power any amount of extra LEDs from the flight controller or the flight controller's power supply! One Neopixel can pull up to 60mA. That accumulates pretty quickly into significant currents when using many.

To get started, solder a 4-pin I²C DF13-cable to your Nano or Pro Mini. Pinouts for the flight controllers can be found in the respective documentations. Then solder ground and data in of the Neopixels to ground and your chosen data out on the Arduino. You can choose the amount of Neopixels and the data out pin in the #defines in the code.

Find the code on GitHub: https://github.com/sgofferj/Ardupilot-Neopixel
You will also need Adafruit's Neopixel library: https://github.com/adafruit/Adafruit_NeoPixel

Original Article: http://stefan.gofferje.net/uav/219-neopixel-leds-as-status-leds-for-ardupilot

Gaming drones are about to change. It's time for drone battles, drone racing, challenges and games. Single player or multiplayer.

First of all...What is Droiko?

Droiko is a high technology gaming micro drone. There are many drones out there that you can fly around, but with Droiko you get to PLAY GAMES, single player or multiplayer. These games include laser combats, drone racing, challenges, and many more games like capture the flag or defend your base.

Some of the games are only possible thanks to Droiko's main accessory: Checkpoints. These little boxes are used to define special areas during gaming, for example: control points for your customized racing track or your base where you can land to refill simulated ammunition. 

Droiko can be flown using our free App in your smartphone or using any standard RC transmitter, and a beginner mode can be selected so anyone can fly it.

If you want to know more about Droiko click on the next link:Kickstarter Droiko

Thank you :)

A continuation of this project

http://diydrones.com/profiles/blogs/ardupilot-flight-controller-with-onboard-osd-and-optional-rpi

Hi guys,

check out our thermal camera on one of the custom endurance builds.

We were able to improve the video quality significantly and it looks very smooth with gimbal stabilization.

It it able to show warm bodies on the ground from few hundred feet up. 

We are selling this complete thermal kit with camera, screen, video link and gimbal as an add-on on our website.

Read more and get a 10% discount on it before the end of the year here.

Best,

Easy Aerial Team

It’s amazing how many variations of hybrid VTOL systems are already out there, and it is even more amazing to see them fly with fully functional autopilots. The E-flite Convergence is a nice little tiltrotor and lots of fun to fly, BUT what if you lose track of it and just want to hit the return button? At UAVenture we specialize in hybrid VTOLs and are always looking for new vehicles to get flying fully autonomous so we put a Pixfalcon in it and installed PX4.

The versatility of the PX4 autopilot makes it possible to easily integrate it into any form of VTOL out there so it only took a few changes and a new mixer to make the Convergence fly (and a bored engineer over the holidays ;)).

For a video of the very first autonomous flight and links to the build log (including the pull-request to PX4) checkout http://uaventure.com/2016/12/30/the-tiltrotors-are-coming/

Hello (again),

XUAV (HOOAH aviation technology LTD) latest EPO FPV/Survey model is the "Clouds". Here a quick overview and unboxing video, with some comparison with their Talon flagship model.

Hello,

Here a shared review of a quite cute and tiny FPV quad, the QX90.

It was unfortunately delivered to me with a built in DSM type receiver so I could not use it with my Taranis radio.

I therefore modded the electronics with another tiny board that is incredible : it integrates a F3 flight controller with all bells and whistles plus an integrated FrSky compatible receiver !

I still have some stability issues with the receiver and Taranis. I am troubleshooting with the maker of this board and will post a follow up later on.

Hi! After my successful first project a friend of mine asked me to modify my design for night flying with a built-in IR LED. We worked together on this way, and the result is quite promissing! Further details and test results can be found on his blog page. Check out his other DIY projects and builts too, quite impressive!!!

After initial testing I made some minor changes on the frame according to his suggestions, ie. screwed upper hull instead of magnetic fixing. The final version of the frame 3D model can be downloaded from the project GrabCAD page. 

Technical data:

• Motor to motor distance: 170 mm
• motor mount: 4 x M3 screw (on 12 and 16 mm diameter)
• frame weight: around 130g with suggested print settings (top + bottom covers)
• motor angle: 0 degree
• camera angle: 30 degrees up

Suggested FDM printer settings for Polymaker Polymax-PLA:

• 4 layers all around (top/bottom and perimeter)
• 40% infill (3D honeycomb suggested)
• 0,2mm layer height
• Support as needed
• 215C print temperature, BUILDTAK print surface.

Suggested electric components:

• BeeRotor ZoeFPV 1806 2900 KV motor + 4" prop or similar
• FVT Littlebee 20A_S ESC (or similar, max. dimension: 24x13x6 mm)
• F3 or F4Flight Controller, any FC can be used with 30,5x30,5 mm hole spacing, but maybe USB port will be covered by frame)
• PDB - optional
• 200...600 mW mini 5.8 GHz Video TX (ie. BeeRotor 25-600 mW) + antenna 
• miniature transmitter RX according to transmitter system
• Runcam OWL camera (or other with same housing)
• 12mm diameter buzzer (optional)
• led stripe (optional)
• OSLON SFH4725S IR LEDs on a 4-LED arrangement plate
• 1A LED Driver, ie. RECOM (mount in the frame is for RECOM)
• RC controlled switch for LED to prevent over heating when on the ground - optional

Please note that this is totally an experimental DIY project, try it on your own risk, I'll not take any responsibility for possible damages or other issues!!! 

If you think my work is useful and would like to support my further prototypes, you can donate by paypal (nhadrian@gmail.com) or any useful electric components are wellcome.

Happy flying, regards Adrian