It is that time of the year when for many of us the furnaces have been turned on for the coming winter and the indoor air is getting dry, so it must be time for my annual ESD Public Service Announcement.

What is ESD?  Electrostatic Discharge!  That little spark you sometimes get when you touch a light switch or some other grounded object.  Electrostatic discharge is always an issue when working with electronic equipment, but is a particular problem during the winter months due to dry indoor air.  When low temperature outside air enters a building and is heated the relative humidity drops considerably.  Dry air conditions increase static charge buildup.

Why should you care?  Well, if you are working with APM (or any other unprotected electronics) and build a large static charge on your person, then transfer that charge to APM (which may (or may not) be signaled by your touching it being accompanied by a spark), that may cause damage to the autopilot.  The hardware multiplexor on APM1 is particularly susceptible to damage from ESD, but many other components can be damaged as well.

How can you avoid damage from ESD?  There are a variety of products and techniques that can help.  Best practices would include using an anti-static mat on your work surface and using a wrist strap to ground your body to the mat when working on APM.  However, simpler, lower cost things can help a lot.  Pay attention to what clothes you are wearing when working on APM.  You may want to remove your fleece jacket or wool sweater.  When I sit down to work with APM I try to momentarily ground myself when first sitting down at my bench to drain any accumulated charge I am carrying, and do so every time I leave and come back to the bench.  Also, there are a variety of household anti-static products that can be very effective in lowering the amount of static charge you pick up.  I use an aerosol anti-static product that will treat a room with a few seconds spray, and which will last several days.

This may be old news to many, but if not then developing a small amount of ESD paranoia and some good habits can save you from killing electronics on the bench.  Personally if I am going to ruin an autopilot I prefer to do it with a spectacular crash!

I have had a Lemon-RX (previously known as Orange-RX) DSM2 6-Channel Receiver (PPM + UART)

sitting around for a bit, and finally got around to hooking it up to my logic analyzer and checking it out today.  I was interested in this RX as an inexpensive option if you need PPM output and run Spektrum/JR gear.  I knew from the spec sheet that the channel resolution on the UART output was a bit coarse.  It runs DEC(66) ~ DEC(134) full scale, giving only 68 disrete levels.  The PPM output is a bit better with a minimum change of about 12 microseconds, so about 83 steps.  Bumping my TX endpoints up got it up to 100 steps.  So that is not great, but OK for drone use IMO.  The stability and jitter looked really quite good at around 1 microsecond.

This RX comes as a bare board with a 3x7 header and 3x2 header soldered on.  It is a bit longer than an AR6200 and a bit narrower.  Some careful work with a soldering iron should allow for removal of the headers and soldering in a 3 wire pigtail if all you need is PPM, leaving you with a very thin package.

I have not done any range testing, but my expectation is that it should be similar to a real AR6200 as they are using the Cypress RF chipset.  Seems like a pretty good PPM option for only US$ 15.30 (plus shipping of course).

From our company Blog:

2012 ESRI International User Conference, San Diego:

Hawkeye UAV was fortunate enough to be invited to exhibit at this year’s ESRI GIS User Conference in San Diego. With a sponsored booth in a prime position in Hall D we could only say "Yes, thank you!" So in late July, Rowland and myself made our way across from New Zealand. Rowland left the week prior to the UC in order to attend the preconference seminars, conduct some meetings and make our technology accessible to the Survey community. Along with the two of us, and providing their expertise on the photogrammetry processing were Luke, Hayden and Sheryl from Areo (http://areo.co.nz/).

The first big coup was ESRI’s invitation to have our display bird on the main stage for the duration of the weekend and Plenary sessions at the start of the Conference. To put all this in perspective, the "main stage" is in front of a room in the region of 200m long, and is backed by three HUGE screens. The room hosted 16,000 people at one time, so a lot of GIS professionals saw our UAV onstage and some of our data as part of the plenary presentations.

In fact many folks mentioned to us at the booth that they’d seen the AreoHawk onstage and asked about the content in the keynote presentation. It was both humbling an exciting to have our technology out there in front of the world.

The DimensionNext blog reports on a cool new UVA research project. Excerpt

When Mitre Corporation, a McLean-based defense contractor announced that they were looking for summer interns, University of Virginia engineering student Steven Easter and his brother and lab partner, Jonathan Turman applied the job. They got the assignment: to build an unmanned aerial vehicle, using 3DPrinting technology.

Luckily they got support from Professor David Sheffler, a 20-year veteran in aerospace engineering. Between May and August the team has been working on designing and building a plane entirely from parts from a 3DPrinter.

The plane has a 2 metre wingspan and all the parts were printed in layers in plastic. During four test flights in August and early September at Milton Airfield near Keswick, the plane achieved a cruising speed of 70 kilometers per hour.

This is what it looks like covered:

On Wednesday, before I spoke at the Tijuana Innovadora conference, I dropped by the 3D Robotics factory there. This is our second factory, and it's now equaled the capacity of our San Diego plant. Guillermo ("Gigio") Romero, the operations lead there, has done a tremendous job bringing this factory up, building a top-notch pick-and-place and CNC operation and a staff of 20 in just a few months.

Here's a quick tour of how your APM 2.5s and ArduCopters are built!

Before 3D Robotics acquired it and it ramped up as a full factory, uDrones was a small stand-alone assembly operation doing early ArduCopters. Some of that history, as well as current products, are on display in the lobby. 

Here you can see the back of the factory. The ceiling of the overall space is very high and the entire space is not air-conditioned, so the manufacturing part is in a "building within a building". Behind those walls and hung celiling, everything is air-conditioned and the air is filtered (double-filtered in the CNC room).

Components and inventory is kept in a fenced-off area with strict controls. This allows us to keep tight reins on stock and our supply chain info. 

Boards start by going through this stencil printer. 

Then they go through the pick-and-place machine. This is the newest Manncorp, even better than the one we have in San Diego. 

Then on to the reflow oven, at right. 

All electronics workers wear anti-static pads on their shoes.

When the boards come out of the machines, they are put on a test jig and run through a full software test routine. 

A video of how the sensor testing works.

Visual inspection is a very important step of the QA process. Boards that fail here are reworked or binned. 

This is the station where ArduCopter PDBs and other solder rework is done. 

And this is the station where they do the hand soldering of connectors and other through-hole parts. 

A rack of APM 2.5s waiting for their pins!

Now for the CNC room, where ArduCopter parts are made. This is the bigger of the two CNC machines. He's holding part of a secret not-yet-announced camera gimbal design ;-)

Another CNC machine and operator. Because of the dust, masks, ventilation and filtering is really important in this room. 

Finished legs, ready for kits. 

Lots of instructions

There are lots of binders with really specific manufacturing instructions. We're going for ISO9000 compliance!

This is the room where the ArduCopter kits are assembled, tested and packed. 

Components. Inventory control is super important. All parts have check-in/check-out forms on the box and we have a custom ERP system. We'll be implementing bar-code scanning soon.

Part of the Admin area

This is the engineering area

Lissana will meet you at reception

Time for a group photo!

Go team! 

Hi all, I'm glad to announce that the R10 kickstarter so far has been a great success, we reached our funding goal within 30 hours, and there is still interest.  So I thank all of you here at DIY Drones, I know some of the community here have supported us too, so thank you.

I wanted to share with you guys some of the history and development of the R10, including crashes, dating back to the quadrotor that was called ROFL (pictured above) from sometime in 2011.  Some of these videos/images you may have already seen as they were posted in Henry's bloghere on DIY drones at the time.

For brevity, I've only selected some of the key highlights, the rest of the historycan be found on our website.

These were some sketches that were made of the frame, and a few prototypes made of palstic and card.  The aim was to minimze the number of components needed to build the frame, so a slot-together design was chosen, and that design remains core to the R10 frame today.

The initial testing was exeedingly difficult, at that point three things had to have right for anything to work - the electronics, which were completely new; the frame, which was untested; and the software, which was written from scratch.  Unsurprisingly, mistakes and erroneous assumptions were made, which meant that things didn't work as well as planned at the start.  The test rig was built in a garage using scraps of wood and clamps.

Eventually after a lot of head-scratching, research, maths, and frustration later, things started going well and it the quadrotor appeared to be behaving more like a flying machine than a glorified desk-fan.

I think many of you here will empathise with us about the lengths we went through to find workable tunings for the craft from scratch.  This prompted the development of an XBee-enabled version of the control board, and a debug interface was created in Qt that had data-logging, sliders, and data-entry boxes.  In this video, the quad is deliberately detuned mid-flight just for fun.

Things went well after that, however there were some persistent bugs in the flight code that caused transient unexpected behaviour, and gradual loss of control, a night flight ended in the worst crash to date, losing two motors and ESCs.

Many long nights of code tweaking, a complete rewrite of the AHRS, and new ESCs later, (Ok, I just skipped about 4 or 5 months of development time here, but just imagine countless crashes, whole bags of props smashed and a lot of swearing) we ended up with something that was acceptable

The ROFL quadrotor, and Henry make a brief appearence in this BBC News clip from earlier this Summer just before I joined: http://www.bbc.co.uk/news/uk-england-hampshire-18416111Henry and Universal Air were volunteering with TeenTech, a charity set up by BBC's Tomorrow's World presenter Maggie Philbin, which runs a program that invites schoolchildren to meet engineers in the real world and encourage them to seriously consider Engineering as a career.  (BBC's facts are wrong, Henry was at Cambridge University, not Oxford)

Henry set up a "flying tent" which contained the ROFL to keep people safe from any prop breakages, and the ROFL quadrotor was also "kid-proofed" with a large padded yellow ring.  The kids were allowed to try to fly the quadrotor.  It's a nervous experience letting kids mess around with a $400 quadrotor, and some did manage to break parts of the quad despite the extra ring, but most were able to fly the quad thanks to the ultrasound altitude-hold and magnetometer-based "simplicity mode" (which allows you to yaw as much as you want and still have the quad roll or pitch in YOUR reference frame: stick left makes quad go left, regardless of yaw).  There were even some who were surprisingly adept at flying without the altitude hold, we can see some promising drone pilots here.

Above was our showcase stand

And now, with even more code tweaks, a completely new flight controller, new operations in the US (that's me!), we end up with the R10 quadrotor system, which is currently on Kickstarter

Here's an assembly video:

What might not be clear in this video is that the flight controller is screwed into the side of one of the frame parts near the center, the flight controller doesn't actually feature in the video because we made the video before prototypes of the flight controller was available.  And the ESCs have been heat-shrunk directly onto the aluminium frame for better heat dissipation.

I hope this has been informative!

Rue Mohr has written a great tutorial on how servos work. Even if you already know most of this, it's a great reference on everything from the basic electronics to modifications and optimizations. 

Sample:

Servos are controlled by sending it a variable width pulse (a type of Pulse Width Modulation (PWM)). Important paramiters about the shape of the pulse are the 'centre duration'  and repetition rate. A servo often turns less than 180 degrees on the output shaft over the rated minimum and maximum output pulse lengths.
The centre position of the servo is defined by a pulse width input of 1.5ms high (it should be the shaft position in the middle of its capable movement). The standard pulse width range is 1ms to 2ms, which is often described as having a 180 degree difference in the output shaft, but often does not. (you can go wider on the pulse width changes, for example .9ms to 2.1ms which, depending on the servo, may give you more movement.)
Every time a control pulse is sent to a non-digtital servo, it performs a position 'correction'. The designed correction rate (pulse rate) is 50Hz, or a new pulse every 20ms, more about that later.
So, in summary, the servo expects to see a pulse every 20 milliseconds (ms) and the length of the pulse will determine the output position.
  For example:
   - 1.5ms pulse will make the motor turn to the 90-degree position. 
   - 1 ms pulse moves it to 0 degrees
   - 2 ms pulse will turn the servo to 180 degrees

 

[Via Hackaday]

I know almost nothing about this other than what's listed on the website.  It looks a lot like Chris's Manta and a direct competitor with the X8.

http://greenairdesigns.com/ejc/index.php/aircraft-kits/prop-aircraft/fpv-uav/viper-x-10-fpv-uav-flying-wing.html

From the website:

2.75m Flying Wing.

Breaks down to 3 pieces of 900mm (Max)

Payload 2-2.5kg

Requires:-

2 x 16g+ Metal geared servos

3542 800kv Motor or equivalent (able to turn a 12x6 to 14x8 prop, payload dependent)

80A+ ESC (gives a safe margin)

4s cells (motor dependent)

(all appropriate glues & adhesives required)

Its worth noteing that we are now working on a dedicated retractable camera gimbal for this and all our up and coming aircraft.

After a crash, two of the arms on my 3DR Hex shifted slightly.  Enough that the props overlapped.  I didn't notice it for a while, but on a subsequent flight, they prop tips touched.  The hex didn't crash but the noise it made certainly got my attention.

My solution was to add more sonar mounting brackets to beef up the arm placements.  It also gave me more places to mount stuff.  (Copter is upside-down in the photo).

Goal: Autonomous / semi-autonomous aerial mapping for creating georectified orthogonal imagery and eventually digital surface/elevation/terrain models (DEM, DTM). I'm in preliminary stages... though I believe that my POC is proven and so currently in testing and then on to my intended pilot project.

Current aircraft platform for testing and learning (and crashing):

Bixler 2 -stock setup plus flaps

• This plane can handle a lot of weight IMO for its size and stock motor etc. You absolutely have to get your CG squared away when you load it up but once you do it really soars and the ability to fly slow while stable is critical for mapping needs.
• Here's what I have on board when fully loaded:
  • APM 2.5
  • Ublox GPS
  • 3DR 90Mhz transceiver
  • RC rx
  • 800mw vtx with rubber duck antenna
  • Sony camera - in heavy metal housing (FPV)
  • Turnigy 2200 Mah lipo
  • RMRC 1100Mah lipo for vtx
  • canon point and shoot
  • A lot of hot glue from busting apart the fuse on crashes early on (prior to putting all the gear above on board)
  • Plenty of duct tape and packaging tape to protect against future (inevitable) crashes.

RC Transmitter:

Turnigy 9x 2.4Ghz stock -  9 channel tx 8 channel rx (was affordable alternative for me)

• I have the flaps controlled by one of the knobs instead of 3 pos switch I used to use  because I needed it for APM flight mode control (described below)
• Currently have 4 switchable APM flight modes configured via tx Gear switch as master and F.mode - 3 position toggle as slave. The gear switch is essentially an on/off between manual and all auto modes. This way I can switch to any one of the 3 position modes directly from manual and back to manual with one flip of switch if in trouble. This has so far been a nice set up. These are my 4 programed modes
  • Manual
  • Stabilize
  • Auto
  • RTL

Autopilot / Stabilization: APM 2.5

• In a bunch of bench tests and just a few field tests it seems to be performing consistently...
• Stabilize mode is absolutely wonderful. Landing in this mode is all but autonomous. You just line up your orientation and bring the throttle down, and you can pretty much watch it land, maybe an elevator nudge at the end to make it glide across the ground.
  • This is a fantastic feature and combining this with FPV for mapping linear features has a lot of potential, especially if you have a downward looking video feed. 
• Autopilot mode with loaded waypoints is obviously the key for my entire project. So far I have one successful mission flying to 2 waypoints. I had to take manual control again before the plane started for home because people started arriving at the field and I was not willing to test with people below. Next test I will run another simple mission and complete the return to home and loiter. I will also set more variety in my WP altitudes.
• RTL mode appears to be working well also. I need to test various altitudes to get it where I will want it for most applications but so far it seems to be doing its job.

Telemetry:

3DR 900Mhz transceivers- so far great range, no problems

• For real-time data from the plane, this is amazing. 
• You can also update your mission from the ground by adding WPs, or simply load the next mission. 
  • I could see this being useful if mission locations are adjacent to each other and within a reasonable range. After completing the first mission you could switch to loiter mode and while loitering, upload the next mission. Then just switch to auto mode again and it should begin its second mission and then return to home. If there's ample battery life and you want to save time from coming in for a landing and relaunching for mission 2, this could be a great approach. I will test this at some point...after I finish my other hundreds of tests. lol

FPV:

1280 Mhz 800mw vtx with 12db pad antenna and multi channel vrx (all from readymaderc)

• Still testing - getting interference but working on it...

GCS: Mission Planner

• Great interface to integrate map view, HUD and even FPV. The HUD is slick looking and it has a nice base of data but you can add a whole slew of overlays as well. I prefer the least screen clutter possible.
• I use easycap to feed live video from vrx to my laptop and overlay the live HUD coming in from the 3DR telemetry transceivers. 
  • It looks good and really no noticeable delay
  • Still having trouble recording the video feed consistently. 90% of the time I get an unusable cropped video...still sorting this one out
  • Also, can't seem to play video back in any video software. I upload to youtube just to see it...it's a pain.

Please let me know if you have any questions or tips for me. 

I would like to learn from others here as I am a total novice.

Interesting roundtable discussion among UAV 'experts' and opinion leaders

From The Engineer: 'The role of the pilot, or commander, or whatever the person overseeing the aircraft is called, is already covered by the existing regulations and the concept of equivalence, said Corbett. Although there are differences in how control is exercised, ‘the aircraft is still piloted, whether it’s by waggling a stick, or using point-and-click with a mouse and on-screen interface. The elements of “airmanship” have to be exactly the same as any other pilot occupying the same piece of airspace, because they will have to cope with the same conditions. Their training might be different, but the end result has to be the same.’

 In fact, Corbett said, the whole category of UAV is somewhat misleading. ‘There are four categories of aircraft: glider, balloon, airship and flying machine, and there are manned and unmanned versions of each,’ he said. ‘But if they’re going to operate in the same airspace, then UAVs shouldn’t be considered separately, as something tagged onto the side. They’re just another subset of the same categories.’

'...another consideration is the interest from potential commercial UAS users, and where their demands could pull the technology. Much of the demand is for vehicles which fly at or below 500m, where some of the technology developed in Astraea — sense-and-avoid, for example — might not need to be so complex, as there is little chance of colliding with other aircraft or trees at these altitudes.  ‘But the two ends [high- and low-altitude] will come together as the technology miniaturises,’ commented Dopping-Heppenstal. ‘We’ll see lessons from small-scale UAVs taken up by those developing larger aircraft...’

This is Vbrain RTF with new enclosure the .stl file is available on thinkverse:

http://www.thingiverse.com/thing:32321
This last revision of VBrain will be official presented to Makers Italy in Milan 9 November 2012 join us at the event : http://www.virtualrobotix.com/events/virtual-robotix-workshop-d-autunno-incontriamoci-a-makersitaly

Emile and Roberto are progressing on the port and test of the VRBrain with the Arducopter

code now we are working on rev 2.7.3-4.

In this video is possible to see the test of Emile Hexa . It's the first flight and we testing the stability , loiter and alt hold and return to land with approach activated.

We have succesfully flown and tested latest features and came up with some benchmarks to compare the different architectures using Arducopter firmwarre.

In this video is possible to see a vbrain installed on a custom frame that use great component : SmartDrone motors and propeller the time of flight is around 27 min.

This is the video of first flight of special revision of firmware for VBRAIN that use the FPU acceleration the benchmark is about this revision of code.

Roberto and Emile a FoxTeam Member .

Here the original blog post :http://www.virtualrobotix.com/profiles/blogs/foxteam-present-last-update-on-vbrain-project-benchmark-of-arduco

An interesting post from Hackaday:

So you’ve got a broken gear for you model helicopter, and don’t have a 3d printer handy. If you need your little helo flying right away, [James] wrote in to tell us about his solution. As you may have guessed from the title, he made a tiny mould and produced a copy of the gear he needed with it. Given the complications of printing or some tiny subtractive method, this little gear turned out really nicely!

The video after the break shows all the steps for doing this procedure. If you’d rather just skip to the results, check out around 10:00 to see the finished gear, and eventually the little guy in flight. As noted, he did have to drill a hole in the middle of the gear after the mould process, but this was the only machining operation.

The helicopter gears worked out nicely, but be sure to check out some of the other really interesting projects on the [xrobots], some of which we’ve featured here!

NASA has announced a new UAS contest that I think might interest people here. It is called the UAS Airspace Operations Challenge and it's being developed as part of NASA's Centennial Challenge Program. Our goal is to hold the competition in the Fall of 2013 and the total amount of prize money available at that time will be $500,000. If the 2013 competition goes well, it will be followed by a tougher competition in 2014 with $1,000,000 in prize money. We're announcing it now, along with a preliminary draft of the rules, to get feedback and ideas from the UAS community and to see if any organizations are interested in partnering with us to run the competition. The rules are incomplete because there are many details that still need to be worked out and we want to be able to improve things based upon your feedback. 

This is your chance to give us your ideas on how we can structure this competition to foster significant progress toward solving the technical challenges to integrating unmanned aircraft into the U.S. National Airspace System. The web page lists the kind of information we are looking for and how to submit official feedback to NASA. There is a link to the draft rules on that page. 

Garry

Following on from Tridge’s article (here), this article focuses on the bottle drop malfunction in CanberraUAV’s flight at the UAV Outback Challenge 2012.

The aim is to show the evidence and theories about why/how the bottle came off, with an emphasis on post-flight analysis on the flight logs. This will hopefully assist other users and developers in analysing their own flights.

What we know

• Takeoff was at 13:43 (local time)
• We entered the search area at 13:46
• The bottle sensor showed “dropped” at 13:53
• Over the next couple of minutes, our speed dropped to 50%
• Exited the search area at 14:33
• We landed back at the airport at 14:35
• The UAV looked like this after landing:

• The bottle was found in a field in the search area in 1 piece, undamaged.

It was obvious that the bottle had come off mid-flight. The parachute became tangled in the propeller. There was a large chip in the propeller that indicated a large collision with it, possibly from the bottle (note the propeller was brand new at the start of the competition).

As for any investigation, the aim is to review the events and data leading up to the event of interest. Fortunately, we have full flight logs (here). They were captured via MAVProxy. The analysis was performed using the Mavlink examples.

Analysis          

We had our bottle drop sensor (digital microswitch) connected to the voltage sensor on the APM.

Considering the speed drop after the bottle drop, a reasonable theory was that bottle “hung around” (possible caught on the tail) for a while, adding drag to the UAV. However, the throttle compensation needed to maintain cruise speed was needed throughout the entire flight after the bottle drop. This indicates a permanent effect – possibly engine damage.

Let’s take a look at that:

mavgraph.py flight.log VFR_HUD.airspeed VFR_HUD.groundspeed SYS_STATUS.voltage_battery:2

(The “:2” tells mavgraph to use the right-hand axis for the aforementioned variable)

So, we have the speed scale (m/s) of the left and microswitch voltage (mV) on the right.

This graph shows us the speed did definitely go down at around 13:56, several minutes after the bottle drop sensor showed dropped. Thus there was some time between the bottle coming off and the engine being affected.

Also of interest is the “almost drops” 5 times before the final drop. This could indicate that the microswitch was rapidly switching on/off for ~15 seconds on a number of occasions. Possibly the bottle was already loose and was rolling off the sensor.

The question is why the bottle was rolling off the sensor at these times. There seemed to be a possible relation to groundspeed though.

So, let’s have a look at what direction the UAV was flying in:

mavgraph.py flight.log VFR_HUD.heading SYS_STATUS.voltage_battery:2

This shows quite clearly that each time the UAV did a 90 degree turn, the bottle rolled off it’s sensor.

We can also look at the UAV’s roll and pitch:

mavgraph.py flight.log ‘degrees(ATTITUDE.roll)’ ‘degrees(ATTITUDE.pitch)’ SYS_STATUS.voltage_battery:2

(note roll and pitch are logged in radians. Mavgraph can do the conversion though, and any other basic maths)

Each time the UAV rolled, the bottle slipped a bit on the sensor. Maybe it was a bit loose?

As for the final drop, it would be possible that this would have imparted a large force of the UAV – if it was a sudden, forceful event (such as the propeller initially getting fouled with the parachute). So let’s take a look at the accelerometers and gyros for any evidence of this:

mavgraph.py flight.log RAW_IMU.xacc RAW_IMU.yacc RAW_IMU.zacc SYS_STATUS.voltage_battery:2

mavgraph.py flight.log ‘degrees(ATTITUDE.rollspeed) ‘degrees(ATTITUDE.pitchspeed)’ ‘degrees(ATTITUDE.yawspeed)’ SYS_STATUS.voltage_battery:2

Nope, nothing significant - no sudden large forces.

Thus the event would have not been particularly violent. It was most likely spread over some time.

Conclusions

Thus, given that:

• The bottle coming off the UAV was not particularly violent
• The UAV started slowing down a few minutes after the bottle came off
• The bottle was starting to let loose during turns, when the UAV was rolling at ~60 degrees
• The bottle itself show no signs of damage (thus was not caught in the propeller)

It is our best guess that:

1. Some string from the parachute came loose during flight
2. The rolls that the UAV was experiencing during turns may have moved the bottle assembly enough to let the string loose
3. Once the string was extended far enough back, it got fouled in the propeller
4. The bottle got partially ripped off – enough to trip the sensor, but not enough to completely release from the UAV
5. The force of this let the parachute string slip freely around the propeller
6. After several minutes, the propeller caught the string again, ripping off the bottle for good. As it came off, the rest of the parachute string caught on the engine block, damaging it
7. As a result of this damage, the engine could not maintain speed at the given throttle level.
8. The UAV continued slowing down until the Ground Station commanded a ~20% throttle increase.

And that’s how you analyse an incident with your UAV/drone:

• Look at the physical evidence
• Look at the flight logs for any unusual readings
• Look for links (i.e. occurred at the same time) between different data variables and the physical evidence
• Develop a timeline of events, with a focus on why one event led to another event and so forth until you reach the incident in question
  
• Come up with the most likely, logical explanation for the incident.

Note: a full list of all the MAVlink datafields collected in a standard log is here. Note not all autopilots use all the datafields. Some may be blank.

Hi everyone, 

Another blog post about OpenBee :)

Everyone asking about telemetry speed but i didnt answer this questions because of nature of RF telemetry.
RF telemetry speed depends more than one thing. I just take this video for showing unidirectional communication limits. 
The limit depends FSK modulation frequency and RF bandwidth. We can increase the limit but range reduces.

As you can see on the video, OpenBee handling %47.7 of 115200 baud without any problem. I guess 5500 bytes per seconds (55.000bps) is enough for most of telemetry project :)


I'm using firmware v1.01 on this video, we can add MAVLINK packers and other useful codes. 

Please feel free for any question and request. 

Cheers

Melih
 

Today we are pleased to announce the AeroDrone MR4 Quadrotor Platform!

The AeroDrone MR4 is a rigid, lightweight and aerodynamically efficient quadrotor design that not only looks great, but has the performance to match. This platform is the evolutionary result of rigorous engineering design, development, and testing conducted in-house at our facility in Melbourne, Australia. Utilizing the amazing APM Autopilot, the MR4 frame has been extensively field tested in order to assure high-end performance when used in any flight mode. The core of the MR4 is covered by the hard ABS Case which has been designed not only to protect the on-board electronics but to make it look great as well. The MR4 platform comprises of strategically placed inbuilt sensor bays, has been designed with high ground clearance (14.5cm) to accommodate a payload of up to 500 grams, and is capable of flying for over 15 minutes. The frame is built entirely out of recyclable materials (like polycarbonate and aluminium), ensuring that the environmental impact of the MR4 is kept to a minimum over the lifetime of the product.

We are selling three different kit versions;

• Frame Kit
• Frame Kit + Propulsion Pack
• Full Kit

as well as an RTF package.

Take a look around our newly designed website to find out more about the MR4. We would love to hear your thoughts on the product and look forward to helping you get flying with this amazing system.

If you have any questions or comments you can post them below or send us an email at support@baskindustries.com and we'll do our best to help.

We would also like to thank all those who contribute to the wonderful ArduPilot project. Your amazing skills coupled with 3DRs fantastic hardware has produced what we think is the worlds best autopilot for its price. The MR4 has been built around it. Keep up the great work, you're an inspiration to all of us.

Hi Guys,

OpenBee modules ready and in stocks today. I just tested Dennis Frie's spectrum analyzer firmware and software over OpenBee. It is working perfect!. The original code a part of OpenLRS RC Receivers and OpenBee using same RF module and pinouts with OpenLRS project, this is why the code working without any problem. :)

In this video, I'm using 1W UHF radio on 459.075Mhz, and analyzer scanning 455-465Mhz band.

You can download the codes (Telemetry and Spectrum Analyzer) and software from OpenBee repository 

And upload into OpenBee easily

Here is the details of Dennis Frie's Spectrum Analyser project:
http://www.rcgroups.com/forums/showthread.php?t=1617297

And OpenBee product page: 
http://www.flytron.com/open-source-hardwares/210-openbee-100mw-telemetry-module.html

Please share your comments with us

Thanks

Melih