All Posts (11086)

Sort by

Flysky i6 Secret settings, mods, updates.

3689670853?profile=original

Hello,

I have been experimenting with my flysky i6 transmitter, and learned some neat things.

1) There is a secret menu

3689670784?profile=original

2) There is a secret way to put the transmitter into firmware update mode

3) The firmware & device is hackable to allow telemetry, thus allowing you not to require apm telemetry modules.

4) The i6 transmitter has been 'software limited' to be 6ch. It is really more than 6 (seems to be 8 right now).

If you have one of the Turnigy/Flysky i6 transmitters you can learn about these functions on my blog here:

http://dalybulge.blogspot.co.uk/2015/10/turnigyflysky-i6-secret-menu.html

happy to know your thoughts and experiences

Many thanks.

Read more…
3D Robotics

3689670740?profile=original

Cross-posted from the 3DR blog:

WHAT IS A FLIGHT LOG?

Solo’s ridiculous amount of computer overhead means the system can record a ridiculous amount of flight information in real time. We collectively call this information Solo’s “flight logs.”

Solo records 500 parameters of operational data at 20 Hz (meaning 20 times every second). It’s an almost unimaginably large store of information. You can “pull” these logs from Solo onto your computer and analyze them yourself for what you could call a highly technical story of your flight. Logs look like computer code. (In this regard, Solo isn’t exactly an exciting storyteller.)

If you’re interested in learning how to read flight logs, you can check out this tutorial.

Even more importantly, though, you can share your flight logs with us. And unlike any other drone out there, we record flight logs to the controller as well as to the drone. This means that even if you lose your drone, you still hold the “black box” in your hands and can send us your flight data immediately through the Solo app — even while you’re still in the field.

Additionally, flight logs are useful diagnostic tools for our tech support team: They can see exactly what happened in flight and when and where it happened. They’re also great information for our engineers developing the next updates for Solo.

Here’s a top-level explanation of what exactly flight logs are, what kinds of data different log types record and why it’s all useful and important to you. 

TYPES OF LOGS

Solo records several types of flight logs. These are mostly categorized according to which part of the Solo system they monitor (as you’ll see here, Solo is an incredibly complex system). Some of these categories are logs for the controller, the WiFi link, Smart Shots and telemetry. Here’s a breakdown of the most important logs—what data they record, and why that’s useful.

RC logs: This information mainly concerns the controller and its communication with Solo. RC logs monitor this communication (WiFi, via SoloLink) as it pertains to command and control—that is, what you have Solo do with your controller. When the WiFi signal gets from the controller in your hands to the autopilot in the copter, SoloLink has to convert that WiFi language to something called PWM, which is the language that the autopilot understands. If there’s a break in communication or some other error, we’ll see it in the RC logs.

In simple terms, RC logs show us what the user asks Solo to do and how that information has been communicated and translated.

Solo logs: This is like Solo stretching out before its flight. Solo logs record a top-down system check, a self-diagnosis that Solo performs each time you power up. Solo logs record these data from all of its major internal mechanisms: the autopilot firmware and status; Sololink firmware and status; WiFi initiation; and the controller firmware. This is Solo making sure everything’s in sync. This information is useful because if, for instance, your controller for some reason doesn’t pair with your copter, we can see exactly where the hiccup was by reading the Solo log. 

Wifi logs: This is the record of your WiFi signal strength and the integrity of the connection between SoloLink’s sending and receiving hubs. One of these hubs is on the controller, created by the controller’s computer; the other is on the copter, created by the copter’s computer. If your WiFi drops any information (called “packets”) in transmission, that shows up here, too.

Data flash logs: One of the more critical logs, data flash is the record of all of the detailed information from the actual flight. This includes read-outs for all of the autopilot’s IMU sensors (accelerometers, gyros, and the two barometric altimeters), as well as Solo’s GPS and compass readings.

These data let us see the story of Solo’s orientation, direction, speed and behavior during your flight. The data flash logs are also a record of all user inputs. This means that when taken all together, we can three things: your inputs; what the copter wanted to do; and then what actually happened. If there’s an error in flight, we can check these three things against each other and find the root of the problem. From this we will know for sure whether it’s user error or something in the system itself.

DiagnosingWithLogs_VibesData flash logs that track in-flight vibration

Importantly for you, data flash can serve as your evidence: These logs hold all parties accountable, so our customer support is guaranteed to be totally transparent. These logs are currently saved on the SD card that plugs into Solo’s autopilot. We’re working on pulling them to the controller’s computer in a future update.

However, even if you lose the copter, you can still send us your flight evidence. To do this, you’d share your…

Telemetry logs: Data about “the pipe.” Telemetry data are shown on both your controller screen and your Solo app screen; they include stuff like altitude, heading, speed, etc. These data are sent from Solo to your controller through SoloLink’s WiFi. The telemetry flight log is a record of how long it takes to send each packet of information through the SoloLink “pipe,” how big each packet of information is, etc. Basically, the telemetry log records how and how well the flight information that you see on your controller screen has been transmitted.

The T-log also provides us with user input information and allows us to check that against Solo’s behavior. This is your evidence. For an example, check out the header image of this blog. You can see what Solo did, and you can see what the user asked it to do. In this case we can clearly see and show that the cause of the crash was user input and not system error.

Shot logs: Information about Smart Shot commands. Among other things, shot logs record how your controller buttons are programmed, as well as all GoPro information, such as the mode, battery life and when you start and stop recording.

Also, when you’re flying, the data about where Solo is supposed to point are sourced through the Solo app, and then sent as instructions to the copter through SoloLink. The shot log shows all of those actions. This means that when you set up a Smart Shot and press “play” on the app, the shot log will say, “sending Solo to x orientation at x altitude.”

WHY DO WE RECORD ALL OF THIS STUFF?

How do we use logs?

Most importantly, we do all of this so that in the case of error or a crash we (and users, if they’re familiar enough with this technology to read the logs themselves) can see exactly what went wrong. And because you hold the black box in your hands, we’ll be able to help you even without the data from the copter. Only Solo’s dual computers can deliver this.

We (and you) can also see if anything about the copter isn’t performing well. In other words, we can monitor the health of the vehicle. For instance, if one motor is taking more amps than the others, we can anticipate that motor will burn out sooner.

Our engineers also use log data internally to tweak and improve performance. The bigger and better the logs, the more comprehensive the picture we have of Solo, and the greater possibility we have for improvements. Flight data also hold possibilities for new technology and innovations that can tap into this information in real time. Basically, the more information there is to access, the greater the possibilities for using that information in an innovative way.

Is this a privacy or security issue?

You should have no more concern about privacy with flight logs than you have with something like Facebook. Well, no, don’t freak out because that’s a bit of an overstatement. That’s because unlike Facebook, with Solo you yourself have to make the conscious decision to send us your data. And even if in the future these flight data get integrated into social platforms, it will be on an opt-in basis.

Read more…

3689670810?profile=original

Looking for feedback on the Autonomous Avionics SkyTractor Heavy Lift Octocopter. Any input is appreciated. Practical payload is 20 pounds, but we tested it with 30 pounds. Flight time is right around 12 minutes with the full payload, but the RED and Movi only weigh in around 12.5 pounds, so flight time should be around 15 minutes. We have built one with a DJI A2 flight controller and with a Pixhawk with good success.

AutonomousAvionics.com

Read more…
Hello fellow DIYer. Last February, my collegue and I posted a survey here asking if you'd be interested in a dynamometer for drone motors and propellers. We are now releasing the production version of the dynamometer!
For the release, here is a quick introduction to motor and propeller testing, as summarized in the video above.

Why testing your motors and propellers?

You must first ask yourself, what are your, or your end user's needs? This question is important, as it will help you know what parameters to optimize for.
  • Do you want to fly longer to film uninterrupted for longer periods?
  • Do you want to carry a larger payload?
  • Do you need more thrust and power to go faster, or to improve handling in strong winds?
  • Do you have overheating problems, and your application requires you to minimize failure rate?
The final choice of power system depends not only on the airframe and payload, but also on your application.

What parameters should I measure?

The motor

NTM propdrive 35-30 brushless motor and Quantum 13-4 carbon fibre prop.

To fully characterize a motor, you need to measure the following parameters.
  • Voltage (V)
  • Current (A)
  • Throttle input (%)
  • Motor load or torque (Nm)
  • Speed (RPM)
The RCbenchmark software automatically calculates the following parameters for you:

  • Mechanical power (Watts) = Torque (Nm) * Speed (rad/s)
  • Electrical power (Watts) = Voltage (V) * Current (A)
  • Motor Efficiency = Mechanical power / Electrical power

The output speed is function of the throttle, in %, and of the load (torque in Nm). If you want to completely characterize a motor, you will need to test it with multiple input voltages and different loads. The throttle is changed with the software, and the load is changed with the type and size of propeller.

The propeller

For extracting useful propeller data, you need to measure the following parameters:
  • Speed (RPM)
  • Torque
  • Thrust
The RCbenchmark software calculates the following parameters for you:
  • Mechanical power (Watts) = Torque (Nm) * Speed (rad/s) ← same as the motor
  • Propeller efficiency (g/Watts) =  Thrust (g) / Mechanical power (Watts)

Notice that the mechanical power is the same for the motor and propeller. That is because all the motor's mechanical power output goes into the propeller, since it is directly coupled to the motor's shaft.

The overall system

The overall performance of the system depends on a well balanced combination of motor and propeller. Your system will be very inefficient if these two parts don't match well together. Because these two parts have a common link (the shaft), the overall system efficiency is calculated as:
  • System efficiency (g/Watts) = Propeller efficiency (g/Watts) * Motor Efficiency
Where the system efficiency is in grams per watts of electrical power. Changing the motor, propeller, or even switching to another ESC will all contribute to changing this calculated system efficiency.

Moreover, the efficiency value will only be valid for a specific command input and mechanical load. In practice, this means that you will test you motor over a range of command inputs, and with multiple propellers to vary the mechanical load.

How to measure those parameters?

In summary, you need to simultaneously record voltage, current, torque, thrust, and motor speed, while at the same time control the motor's throttle. By combining these readings you can extract the electrical and mechanical power, which in turn will allow you to get the efficiency values.

The RCbenchmark motor test tool was built to reduce the time and cost associated with building a custom test rig. The tool is capable of measuring all the necessary parameters while controlling the ESC, and recording the data in a CSV file for analysis.

Dynamometer Thrust load cell

Test procedure for static tests

Dynamometer test of a brushless motor and a propeller


For now, we will only cover static tests (we won't talk about dynamic tests involving angular acceleration, estimating stall torque, etc...). Before starting your tests, we recommend:

  • Installing your propeller in pusher configuration, to reduce ground effects with the motor mounting plate
  • Have a reasonable distance between the propeller and other objects, again, to avoid ground effects
  • Having all safety measures in place to protect the people in the same room
  • Configuring your dynamometer to automatically cutoff the system should any parameter exceed its safe limit
A simple but effective test consists of ramping up the throttle in small steps, and recording a sample after every step. Before taking the sample after each step, we allow the system to stabilize for few seconds.

In the video above, we manually varied the throttle from 0 to 100% in 10 steps. This procedure could also have been performed using the RCbenchmark's automatic test or scripting feature, which we will cover in another tutorial.

The results obtained are shown in this CSV file.

How to use the efficiency results?

You can summarize a lot of data points using any plotting software. Here is an example obtained using the CSV file linked above:

plot trust and propeller efficiency
 

You can than compare this plot with other plots generated using the same method. Try comparing two plots, all with the same parameters identical expect one element changed, for example switching propeller.

What next?


We want to publish more tutorials, with more details about certain aspects, such as automatic tests, installation, automatic kV testing and pole counting, motor theory, dynamic tests, scripting, etc. Anything in particular you would like to learn about?

If you are interested by our dynamometer, have a look here. We offer 15% off until November 15 for DIYdrones readers using the code "DIY15".

It is an exciting time for my collegue and I, as this release is the results of almost a year of work! Please comment below, I will do my best to answer your questions!
Read more…

UAV Beer Lifting Entertainment

Here is a short video from the annual HobbyKing Beer lift challenge. One of the more entertaining events in the wacky world of UAV's. Maybe the folks over at Amazon, Google, WalMart, etc... can take note. Sure would be nice to see their "delivery" drone offerings/solutions giving the beer lift challenge a go. Maybe next year? Enjoy.

 

Read more…
3D Robotics

Pixhawk/APM compatible Wifi radio

3689670724?profile=original
Want to do mission planning or setup with Tower on Android or MAVPilot on iOS without the hassle of janky cables? What you need is a direct Wifi connection to your drone. The new Pixhawk/APM-compatible Wifi radio from HobbyKing is perfect for this, and just $19.97.  I almost exclusively use mobile apps and wifi now -- 400m range is fine for setup, planning and telemetry. Leave that laptop and those cables at home!

Tired of having to program your APM / Pixhawk system by wire? The APM / Pixhawk Wireless Wifi Radio Module is the perfect solution! This simple yet effective module replaces the 3DR data transmission module and frees you from the limitation of a USB cable. The system is suitable for all flight controllers with TTL interface.

The Wifi Radio module is supplied with both Pixhawk and APM compatible wire harnesses for quick and easy setup. 

Features: 
• Wireless functionality for Pixhawk and APM
• Compact and lightweight system supplied with Pixhawk and APM wire harnesses
• Replaces the 3DR data transmission system module
• Supplied with Pixhawk and APM wire harnesses

Specs: 
Transmission Rate: 11n:MAX150Mbps;11g:MAX54Mbps;11b;MAX11Mbps
Channels: 1~14
Frequency Range: 2.4 ~ 2.4835 Ghz
Transmitting Power: 14 ~ 18 DBM
Interface: Serial port, GPIO
Transmitting Range: 300 ~ 800 meter
Working Temperature: -20 ~ +70 degrees
Storage Temperature: -40 ~ +80 degrees
Bandwidth: 20MHz/40MHz/Auto Optional

Read more…

Video: Crisis Mapping Nepal with UAVs

3689670629?profile=original

I had the honor of spearheading this disaster recovery UAV mission in Nepal a few weeks ago as part of Kathmandu Flying Labs. This Flying Lab is the first of several local UAV innovation labs that I am setting up with friends and colleagues in disaster-prone countries around the world. The short film documentary above was launched just minutes ago at the 2015 Web Summit and describes how we teamed up with local partners in Kathmandu to make use of aerial robotics (UAVs) to map Nepal’s recovery efforts. 

Please help us share this story of drones for good widely. Thank you!

Read more…

3689670653?profile=originalThe light weight dual frequency on board GNSS system for sUAVs was first conceptualized in September 2011 when we were once again frustrated by the lack of vision of proprietary VTOL UAS manufacturers whom we could not convince of the advantages of on board dual frequency GNSS in sUAS mapping applications. Hence we decided to take the development of this cost saving feature in our own hands and built a universal, affordable, hot-exchangeable, dual frequency GNSS V-Map (shown above on a modified Steadidrone) receiver weighing less than 130g (antenna mounting and cables included) and running at 20Hz.

Shown below in photos dating back to 2012 the platform independent V-Map system is mounted on the Aibot X6 copter from Aibotix GmbH and on an md4-1000 from Microdrones GmbH. It can be mounted on fixed wing platforms as well.


3689670669?profile=original

Use the V-map system 

• in the air for GNSS supported SfM mapping,
• as a spatial reference back-bone in hydrographic surveying
• as well as in conventional terrestrial kinematic base-rover surveying as shown below

3689670682?profile=original

The V-Map system professionalizes small, modern, geo-spatial sensor platforms such as UAVs, remotely controlled autonomous boats and land vehicles. It empowers small mapping operations all over the world to make maps and geo-spatial products of professional quality. Equipped with an accurate event marker the V-Map system produces high precision camera exposure positions on dynamic platforms. The standard 1PPS port provides precision time tagging for hybrid surveying and data fusion applications. Additional ports for streaming RTCM and NMEA sentences can be furnished on request.

The V-Map concept: AFFORDABLE PROFESSIONAL SOLUTIONS through


• FLEXIBILITY
• RELIABILITY
• EASE OF USE
• HIGH PRECISION


Contact the V-team for more details



 

Read more…
3D Robotics

New: Dronecode Probe

3689670483?profile=original

From Pavel Kirienko: 
NicaDrone has just released the first batch of DroneCode Probe - open source, open hardware JTAG/SWD debugger and USB/UART adapter compatible with the hardware maintained by DroneCode and suitable for UAV and robotic projects in general.
Features:
  • Debugging via standard GDB.
  • No extra software is required (e.g. unlike Open OCD, no daemon is needed).
  • Works with Linux, Mac and Windows.
  • Works with Eclipse and other IDE.
  • Supports STM32, LPC11, LM3S - see the full list.
  • Tiny form-factor.
  • Standard DroneCode and ARM connectors.
The probes can be ordered from NicaDrone:
Read more…
3D Robotics

UK Police: FPV is "an offense"

3689670573?profile=originalFrom Wired: 

Police attempting to make an arrest for "negligent" use of drones have been instructed not to attempt to land the craft themselves -- in case they accidentally hit the public.

The suggested course of action? Just wait -- for the battery to run out.

The advice is included in 28-pages of guidance, provided to WIRED, on how police officers should deal with the misuse of drones by the public.

The document details a checklist that officers should stick to when they think a crime is being committed by someone flying a drone. 

Officers -- who are told "drone is a word that the Police Service has steered away from using in the past" -- are told not to "criminalise innocent misuse" of drones, but are reminded to bear in mind national security, public safety, and the prevention of "traditional crime" when drones are involved.

The guidance, which hasn't been published before but was issued to all forces this year, was created in response to the increasing use of drones for personal and professional means.

The document and its annexes set out the procedure, legislation, and frequently asked questions that officers may have to answer when they're faced by someone with a drone.

Officers are told:

  • They shouldn't try to take control of the drone "UNLESS EXCEPTIONAL CIRCUMSTANCES EXIST," such as a threat to life or damage to property. Officers are told: "Trying to land the system yourself may cause the drone to crash leading to a very real risk of injury to persons and damage to property (in addition to destroying the drone)."  
  • If the person is wearing first person goggles, showing them footage from the drone as they fly it, "they commit an offence. The pilot should be able to see the aircraft with the naked eye at all times."
  • To "ask to see the footage of anything recorded" despite not having "power to demand this or require its removal," unless the person is suspected of terrorism related offences.
  • If the drone's in the air "currently the only option open to you is to instruct the pilot to land the drone".
  • If the person refuses to land the drone "waiting is likely to be the most appropriate option" as its battery will run out.
  • There is a "concern" that terrorists could use drones to "obtain information through hostile reconnaissance". 
Read more…

The Jigsaw Puzzle of Commercial Drones

3689671510?profile=original

I wrote a blog post about my high-level thoughts on the current state of the commercial drone industry and wanted to post it here in case others wanted to chime in. For those interested in past and future posts, I will try to update our blog at senseme.io/blog on a weekly basis.

Commercial drone operations is like a gigantic jigsaw puzzle whose pieces have yet to come together. As a result of the industry being so young, the concept of operating a drone commercially is largely misunderstood by even some of those who are in the space. Military drones have been in existence for over the past decade. With over a million drones expected to be bought this Christmas, it’s clear that consumer drones have already hit the mainstream market (having its own South Park episode might be the best qualifier for that). Commercial drones....well, that’s a gray area that on the large scale of things has barely begun to sort itself out.

Perhaps what is most interesting is that drones operated for commercial purposes will likely be bigger than both military and consumer drones combined (per Chris Anderson and others' predictions). At the moment, however, that’ doesn't seem to be the case by a longshot. Buddy Michini, CTO of Airware, said in a recent talk that “If anyone tells you they’re making a lot of money on commercial drones – they’re lying.” At first, I was incredulous. There is an incredible demand for what drones can do in the commercial space, so shouldn’t a lot of people be making a sh**load of money? If Buddy is right and the profits of commercial businesses aren’t currently lining up with the potential of commercial drones, let’s look at some possible reasons why that is the case.
 
One possible reason is that the technological ecosystem isn’t completely there yet. Most – if not all – manufacturers and service providers are still optimizing their products and services for commercial purposes. Those who are able to offer a full-fledged and mature product or solution are those who are experts in the space and have been in the game since the very beginning. Those who don’t qualify for that distinction are in the beginning stages of their businesses. The demand-side might be there, but the quantity of mature supply-side operators might not be.
 
Even early adopters don’t want to pay top dollar for a system that doesn’t 100% work yet. Drones in many instances are replacing operations that construction companies, farms, etc. already have in place. Even though drones clearly present an optimal solution, integrating drones into everyday operations is a big leap. Sure, people are extremely eager to get their hands on the technology. As soon as the issue of money comes up? Many scurry away. On the demand side, end-users trying out this technology (justifiably) want free demos and discounted services for being an early adopter. On the supply side, many businesses are strapped for cash and resources, making it difficult for them to meet the demand side’s needs.

Another big reason that I’ve heard from other operators and that we’ve experienced ourselves is the massive gray area that exists for insurance and compliance, as well as the gap that exists between the compliance piece and the actual operations piece. This makes end-users of the technology even more wary. Big companies who are willing to pay top dollar want to see that it’s done correctly so that they’re not liable – right now that’s not entirely possible (especially in some locations, which I’ll get to shortly), or at the very least it’s more difficult than it should be. Smaller firms might be willing to fly under the radar, but they’re much more strapped for cash and can’t hand out the $$$ that many commercial operations require to be profitable.

One of our partnered service providers who holds a 333 always voices to us that their highest priority is flying in a way that’s compliant with the FAA. Their compliant is that they don’t have access to tools that allow them to do so. Their particular issue is that they are located in Las Vegas, Class B Airspace that according to their 333 requires them to have a 2-way transponder on-board their drone. In order to clarify how he should be flying within Class B Airspace he contacted all the FAA officials and local Flight Standards District Offices (FSDO) he knew of. No one had an answer for him. Clearly something is wrong when those who should be implementing the rules can’t offer advice for how to follow them.

Another relatively new piece of the puzzle in the commercial industry is insurance. In manned aviation, insurance dominates. In unmanned aviation, this isn’t the case (yet). One reason for this is that there is no protocol in place for service providers to follow – what are best practices? As a service provider, what is expected of me to mitigate risk? And if I follow these practices, will I be rewarded in the same way as if I consistently drive my car safely?

Below is a representation of what we believe service providers often juggle for their projects – the “service provider triangle,” if you will (forgive my poor drawing skills). This is comprised of meeting client’s needs through the most up-to-date technology, while making sure you’re doing so in a fashion that’s insurable and compliant. Each one of these pieces is maturing on its own. Technology is improving rapidly. Clients are slowly beginning to understand the technology. Regulations and insurance are also making strides at their own pace (albeit, not fast enough to keep up). The biggest issue is that these pieces don’t currently fit well together. Service providers have to jam them together hoping that they fit. Without a standard protocol and best practices that a commercial service provider can easily follow, this becomes a slow, inefficient, and often ineffective process where safety & compliance falls by the wayside.
 3689671481?profile=original

NVdrones is working together with all corners of this triangle to bridge the gap between them to make the lives of commercial operators easier. We are hoping to grow and evolve our newest product, SenseMe, to integrate with powerful pieces of software and provide operators with an easy solution to satisfy their clients while getting the best insurance and flying the most compliantly.

Like any other jigsaw puzzle, the individual pieces must come together in order for the entire picture to be realized. If you think the problem we’re solving is a viable one, visit senseme.io to learn more or e-mail me directly at kmukai@nvdrones.com.


Thanks for reading and hopefully I was able to provide some insight to those who spent the time!

Kevin

Read more…

3689670264?profile=original

AUAV is proud to announce our latest high quality PixHawk derivative - The XRacer V1. This project was developed in cooperation with Lorenz Meier, David Sidrane, Leonard Hall and many others. This board combines the latest IMU offerings from InvenSense and a large number of capabilities in a micro 36mmx36mm form factor.

 

Below are some pictures to peak your interest.

 3689670264?profile=original3689670448?profile=original3689670461?profile=original3689670519?profile=original3689670285?profile=original

XRacer V1 specifications:

  • MCU - STM32F427VIT6 rev.3
  • FRAM - FM25V02-G
  • Ultra low noise LDOs for sensors and FMU
  • Sensors used - MPU9250, HMC5983 ( optional ), ICM20608 ( optional ), baro MS5611
  • Connectors - GPS+I2C, RC-IN, PPM-IN, RSSI, SBus-IN, Spektrum-IN, USART3 ( TxD, RxD, CTS, RTS ), USART2 ( TxD, RxD, CTS, RTS ), FRSky-IN, FRSky-OUT, CAN, USART8 ( TxD, RxD ), ESP8266 ( full set ),      SERVO1-SERVO6, USART7 ( TxD, RxD ), JTAG ( SWDIO, SWCLK ), POWER-BRICK ( VDD, Voltage, Current, GND ), BUZZER-LED_BUTTON
  • MicroSD card reader
  • RGB LED
  • Micro USB
  • ESP8266 802.11bgn ( optional )
  • Dimensions - 36 x 36mm with 30.5 x 30.5mm hole grid with 3.2mm holes
  • Molex Clik-Mate ( JST GH series ) connectors for easy peripheral connect.
  • Full set of ready made cables for almost any peripheral module.
  • Power supply - 5-5.5VDC from USB or PowerBrick connector. Soon the  ACSP4 ( 36 x 36mm power distribution, current, voltage sensor with 5V/2.5A ultra low noise buck and 12V/2A ultra low noise buck ) companion will be announced.

 

The price and availability will be announced within a few weeks.

 

Thank you again for your support.

 

Phil and Nick

Read more…

Parcel delivery with 4Gmetry+Volta

This is a short demonstration of a simple delivery system, based on Volta+4Gmetry. Operator (who is virtually anywhere in the world) inserts the delivery point in Volta console (http://diydrones.com/group/volta). Route is automatically generated on the server, and written down to the drone via secure VPN over 4G  (http://4gmetry.voltarobots.com/). The server arms the drone, starts the mission and monitors the progress in real-time (adjusting the route, if necessary). Volta server can manage several drones simultaneously. Feedbacks are highly appreciated! 
 

Read more…
Developer

MAV Pilot 1.1 for iPhone, Update released.

3689670250?profile=original

MAV Pilot v1.1 for iPhone has updated and published to the App Store. It supports connection to MAVLink compatible drones using WiFi (& LTE/3G connections) including 3DR Solo.

MAV Pilot supports Plane & Copter.

MAV Pilot v1.1 has the following improvements

- Maps

  - Support for more mission items with direct placement of Waypoints and ROI directly on map (long press menu)

  - Guided mode

- Improved Audio Support (Text2Speech, custom speech strings possible)

- Improved App Settings for Network Connectivity.- 

- New attitude Indicator on Dashboard

- New analog displays  on Dashboard

- Map 'mini dashboard' of important information

- Servo Commands

- Support for ArDrone 2.0 with Flight Recorder GPS

- General UI improvements

Download here ( https://itunes.apple.com/us/app/mav-pilot/id649233096?mt=8)

Happy Flying... :)

Support here http://www.communistech.com/support/

PS: if you want to help with beta testing the next release, please contact me via the above link. Thx. Bill

Read more…
3D Robotics

3DR's evolution from micro to mass

Makers_2015_optimized_for_PPT.png

As many of you know, Jordi Munoz and I founded 3DR in 2009 as a way to help get drone technology into the hands of the masses.  And it certainly has reached the masses—these days, there’s never a day without many drone stories being published, and interest only continues to grow.

3DR continues to grow and evolve.  Where we were once a company focused on bags of parts and bare boards, we are increasingly centered around integrated products that just work for people, products that allow people to focus on the results rather than the mechanism.  Additionally, we’re placing bigger bets on a smaller number of products, with Solo being the prime example (so far!). Today, we are more than 200 employees and the overall business grew by more than 500% this year. 

Like the drone industry overall, we have evolved from a DIY company to a mass-production company and now compete directly with DJI and Parrot, both of which manufacture in large-scale factories in Shenzhen. We do the same with the Solo family and our future products.

For those of you who are familiar with my 2012 book Makers: The New Industrial Revolution, you may recall that this was always the plan. The above is a chart from that book, which shows that as volumes approach 100,000 units a year, economies of scale and a focus on margins require a move to mass production and deep supply chain integration. That's the volume 3DR is now at. For a product that increasingly resembles a smartphone, this scale can really only be done in Shenzhen, the capital of the smartphone industry.

As part of this transition, we are in the process of sunsetting many of our legacy products, which were made in our Tijuana factory.  There are now many great frames available, many supplier of FPV cameras, and many companies focused solely on very specific drone components.  In the process of winding down some of our older products, we’ll do our best to point you to alternatives.  And of course, many of you here already build and release technology that surpasses what exists commercially today!

Going forward, we will focus on the Solo family and other core elements of our next-gen platform. In particular, we will continue to offer Pixhawk-compatible autopilots, with improved versions designed in cooperation with partners. And autopilots continue to be a core focus of 3DR, with exciting new platforms coming in 2016.

3DR will continue to work on making a difference where we can best do so: in providing highly integrated, innovative, and fully configurable complete systems.  Additionally, we will continue to provide tools to enable people to stretch the boundaries of what this technology can do, and to work with true innovators like those in this community to build the core elements of our common drone future.

You can count on us continuing to be VERY active in the DIY Drones community (today, seven years after founding it, I still post and comment every day -- it’s a source of constant joy and amazement for me, and one of my proudest creations).  You all have been a central part of 3DR’s vision and development and will continue to be so—and we will continue to be active contributors back to both this community and the broader Dronecode development project -- indeed, this focus on becoming a much bigger company will allow us to devote even more resources into contributing open source code to the community and recruiting more partners to do so as well.  

At 43 companies and counting, Dronecode has more than doubled over the past year, and we will lead its march as the world’s leading open drone platform by extending the platform into video, the cloud and advanced computing by creating world-class developers tools such as Dronekit and the Solo SDK.

 

Thanks,

 

Chris

 

Read more…

Hello drone lovers!

We are excited to be so close to our goal on KickStarter with another 3 weeks left on the campaign. 

In the meantime a test we did last week proved that Easy Drone XL Pro could actually lift and fly with 8 pounds of weight for quite a few minutes (without bursting into flames). This is with a hand-tightened frame and it's default battery and props. 

We are still sticking to our 3 pound recommendation for the camera weight though since we want to give you more than 100% overhead to fight winds and be more agile. 

Take a look at a recent demo we did at InterDrone in Las Vegas below:

Read more…

RMRC Responses to FAA and DOT Actions

3689670418?profile=original

I'm glad that someone is raising some legit questions in the name of the whole community 

  "November 2, 2015 - As many in the US are aware, the FAA and DOT are considering requiring registration of some sUAS and have created a task force to help develop that process.

The DOT and FAA have asked for public input on the issue and have identified 10 specific questions in the document titled "Clarification of the Applicability of Aircraft Registration Requirements for Unmanned Aircraft Systems (UAS) and Request for Information Regarding Electronic Registration for UAS" that can be found at www.regulations.gov/#!docketDetail;D=FAA-2015-4378.

It is our opinion that the rush to create these new rules violates the existing procedures for enacting new rules and also goes against the law set forth in the FAA Modernization and Reform Act of 2012 (Public Law 112-95). That statute included Section 336, “a special rule for model aircraft.”  This provision was specifically included to protect the model aircraft hobby and industry from any over-reaching and onerous regulation that might be created in the future by the FAA as the FAA set out to create new rules for large commercial unmanned aircraft.  The law exempts recreational model aircraft from any new regulation, instead preserving for our communities their existing historical role of offering safety guidance, pilot instruction, flying site establishment, and event supervision, while preserving the FAA’s limited taxpayer resources for other important regulatory functions.

In our opinion, the FAA and DOT are making new rules while trying to justify them both by saying they are “interpreting” existing rules and by claiming that they are justified under the language of the 2012 law stating that “Nothing in this section shall be construed to limit the authority of the Administrator to pursue enforcement action against persons operating model aircraft who endanger the safety of the national airspace system.” It is our opinion that the current rulemaking attempt of the FAA and DOT specifically violates the FAA Modernization and Reform Act of 2012 by applying new rules not previously required for model aircraft or an aircraft being developed as a model aircraft.

That said, and outside of any legal proceeding to verify our opinion, we feel it is in the best interest of our customers to review the questions and offer comments. It is our opinion that the government website used to allow the submission of comments is limited and cumbersome in its implementation, but we have offered a few suggested comments below that you as our customers are welcome to use as a guideline for your submissions. We suggest you offer your own civil and productive comments as well. We believe model aircraft can be operated safely in the US airspace by enforcing rules already in place. If you use our replies below, you will probably have to save your comments as a document and upload the document to the web site.

Responses must be submitted by November 6, 2015 to be officially considered by the DOT and FAA."....

Check whole press release here http://www.readymaderc.com/faa  

Read more…