All Posts (11086)

Sort by
Moderator

These are the board developed by VR Lab available in the store : VR micro Gimbal , VR Multi Constellation GPS 8  ,VR Micro Brain 5 and plug and play VR micro telemetry board  . The VR Brain 5.2 is in pre order.

3689627664?profile=original

3689627757?profile=original

Example how is possible to assemble  the boards togheter , the form factor is very small and lightwheight . 

3689613300?profile=original

In the picture below is presente the VRX Radio Module lite , Standard and Advanced ( OSD support ) 

3689625833?profile=original

This is a very exclusive video  example of fully autonomous fly using VR Leash experimental kit . You can set the position where put the drone by VR Leash natural reposition system or by PAD / Smartphone user interface available in VR Pad Station Pro.

These electronic component is in the stock on the store and with the Black Friday coupon you can obtain a discount of 20 % for Friday 27 November 2015 :) and for 28 November 2014. You need to insert the coupon during the checkout process.

The Standard Coupon is : 20%VRBlackFriday2014

The "Secret" Coupon is :  20%VRBlackFriday2015

VR micro Brain 5 : http://www.virtualrobotix.it/index.php/en/shop/autopilot/vrbrainmicro51-detail

VR GPS 8 : http://www.virtualrobotix.it/index.php/en/shop/accessories/gps-ublox-8-detail

VRX uBrain Telemetry module lite option 433 : http://www.virtualrobotix.it/index.php/en/shop/accessories/vrx-ubrain-radio-module-lite-433-mhz-europe-38-61-detail

VR uBrain Telemetry module lite option 868 : http://www.virtualrobotix.it/index.php/en/shop/accessories/vrx-ubrain-radio-module-lite-868-mhz-europe-38-61-62-detail

VR radio module lite option 433: http://www.virtualrobotix.it/index.php/en/shop/accessories/vrx-radio-module-lite-433-mhz-europe-38-detail

VR radio module lite option 868: http://www.virtualrobotix.it/index.php/en/shop/accessories/vrx-radio-module-lite-868-mhz-europe-38-61-detail

VR micro Gimbal Board :  will be available at december 

VR Leash : available for OEM and Pro project.

About VR Brain 5.2 

http://www.virtualrobotix.it/index.php/en/shop/autopilot/vrbrain5-detail

today we officially open the pre order for VR Brain 5 sorry for delay but we did some update to the project now the current release is VR Brain 5.2 we add some new connector respect of rev 5.1, more detail came on wiki in the next days .

The delivery will be from 18/12/2014 if we have some update about new early dates will inform you by broadcast mail on virtualrobotix.com so you register on it please.

We decide to open today so you can use the VR Black Friday coupon .

Best

Roberto

Read more…
MR60

3689627679?profile=originalHi,

I'm sharing with this community about my project's experiments which has for an objective to write (i.e. set = modify) a parameter (i.e. parameters we can see in the full parameters list in mission planner) using Mavlink.

You're now thinking : what a stupid objective, just use a GCS like mission planner to write your @#{{ parameter!

Well, no, I want to build an excel pre-flight checklist; within this checklist I'd like to see a list of all of the failsafe parameters of my multirotor AND be able to change their values (for example by clicking on a write button on this Excel checklist). Indeed none of the available GCS software is practical to do just that : you have to click and navigate through dozens of screens to get to all of these parameters I want in my checklist. Just unusable. Therefore I decided to try to build this in a typical DIY way.... It would also be a good Mavlink learning experience.

 

You may think: so what ? just use available libs or APIs and it's done. Yeah right, so I thought too naively in the beginning....

What I found is that Mavlink is the most complex contraption I have rarely met. Not only is  the standard awfully complex, but there is absolutely no material available on the web that would qualify seriously enough as "documentation" (developers tend to think that documentation consists in their comments within the source code, and that is only valid when they write comments in their source code...). The complexity of this standard comes from the fact their inventor(s) wanted something totally generic, for any kind of UAV and for any kind of parameters and any kind of control messages (it even cares for creating your own set of parameters/messages). Another reason for the complexity of Mavlink is the choice they made to partition the information in hundreds of different small compartments/files/scripts. So it makes it very very hard to get an bird's eye view on it and to understand what links what.

About documentation, the only data I found  (I did visit dozens of web pages and various  links about Mavproxy, about drone api, about Mavlink, about pymavlink, etc) were parcellar, very short pieces of information. Impossible to find a synthesized, clear overview of how to program concretely with Mavlink. Not even a single code example to show how to write a parameter via Mavlink from A to Z, not a single example ! However you will find tons of much more complex code examples such as fully functional GCS software. I did do a thorough information collection searching for similar topics on this forum and posting some help requests... without joy.

The least undocumented I found was Mavproxy, on a few web pages written by Tridge. However Mavproxy is a GCS software that is meant to be used with a human-machine prompt interface, on which you type in commands. You can't use it (or I did not find how, which prove how bad documentation is) for programming commands to be executed automatically (without a human typing something on the Mavproxy prompt). That is thus not usable for my project; however I decided to start from MavProxy to see if I could reverse engineer it, decrypt it  (I felt like Champollion and his Roseta stone) and reduce it to the bare minimum needed to just "set a parameter value" via Mavlink.

 

Not being a developer, not knowing even the python programming language (I had to look up wikipedia to know what a "class" means), I did what an engineer does best : a logical analysis on the Mavproxy source code and all of its dependencies (libs, modules) and lots of trials and errors. This allowed me to identify how the libraries and modules were linked to each other , via which classes and functions and variables to write a parameter to Pixhawk via Mavlink.  Disclaimer : it is probably very much incomplete or even incorrect but I reached my wished result.

The result is the scheme above which attempts to provide a synthesized overview of how the different python libs/modules/functions interact to simply write a parameter to Pixhawk via Mavlink. An immediate conclusion of this is how ridiculously complex Mavproxy & Mavlink are (the base from which I derived a modified MavHugues.py python program that does what I want). It even more so ridiculous when you think that all of this boils down to just writing a few bytes to a COM port ! (I'm afraid that some guy(s) in ETH Zurich university did make things complex to justify their PHD)

My practical test bench was a pixhawk connected via USB on a COM port of my windows laptop. I installed Win python, pymavlink, Mavproxy. For testing the thing, I chose to change the value of the CIRCLE_RADIUS parameter. AND IT WORKED ! Alleluia. (<= this is a joy manifestation of succeeding doing something stupidly simple starting from an insanely complex contraption, i.e. Mavlink/Mavproxy).

I provide my modified Mavproxy.py python script (MavHugues.py) in annex for those who want to join me in the simplification fight for programming Mavlink !

Please, developers, be kind in your eventual reactions...I'm certainly a very bad developer but you're as bad documenters;)

Hope this will also help eventual other DIY'ers playing with Mavlink.

Cheers,

Hugues

File attached : mavhugues.py

Read more…

GoPro Developing Line of Consumer Drones

gopro+logo.png?width=150

GoPro Inc. is developing its own line of consumer drones to expand from its core business of making wearable video cameras popular with surfers and other sports enthusiasts, according to people familiar with its plans.

The company plans to start selling multirotor helicopters equipped with high-definition cameras late next year, aiming for a price tag between $500 and $1,000, according to these people.

The entry of a big consumer-electronics brand to the drone market signals how mainstream—and lucrative—the industry has become in just a few years. Consumers have flocked to unmanned aircraft in recent years as technology advances have made them smaller, cheaper and easier to fly, leaving regulators scrambling to keep up.

Consumer drones are typically lightweight helicopters with cameras that can be controlled with a tablet or smartphone. U.S. regulators allow their use by hobbyists. The devices are expected to be hot sellers this holiday season and have even inspired their own version of the selfie, or self-portrait photo, called a “dronie.”

GoPro’s move into drones comes as its market-leading camcorder business faces competition from rivals such as Sony Corp. and others. The 10-year old company, which went public in June, has been investing heavily in research and development to maintain its lead in the camera business, which shipped nearly 2.8 million units in the first nine months of the year, up 15% from the same period last year.

San Mateo, Calif.-based GoPro is already a supporting player in the drone market, providing many of the roughly 3 oz. cameras that consumer drones carry. But GoPro may be hedging against a business it could be losing; the world’s biggest consumer drone maker, SZ DJI Technology Co. of China, recently started selling devices that come with its own in-house cameras. Other drone makers could stop supporting GoPro devices if they are competing head-to-head with the camera maker.

“I’m happy to let GoPro keep making great cameras and we’ll keep making great copters,” said Colin Guinn, senior vice president of sales at Berkeley, Calif.-based 3D Robotics Inc., which sells GoPro cameras with its drones.

FROM http://online.wsj.com/

Read more…

  • dominoss.jpg The Delivery Drones are now available.

    "Delivery Drone's Here" will be a common phrase in 2-3 years time as urgent flying deliveries will be commonplace - shipping cargoes as mundane as beer and pizza to more vital necessities like medicines and survival kits.

    amazon1.jpg>

    The word is out that big companies like Amazon will be hiring qualified drone pilots, preferably with lots of flying experience. PRE-Flight Delivery Drones are armed with cargo handling capabilities. Drop packages with precision using downward-looking cameras. The drones even rebound upward when you release the payloads like the real thing.

    So start building up your Drone flying hours now, in complete safety with PRE-Flight's collection of popular models:

  • Amazon PrimeAir Drone
  • Domino's Pizza Delivery Drone
  • Parrot Drone 2 - Indoor mode
  • Parrot Drone 2 - Outdoor mode
  • DJI Phantom 2
  • x525 quadcopter - popular DIY drone
  • Octocopter - Carbon Giant, heavy lifter, high-speed
  • Reaper UAV - scale model
  • Reaper UAV - full scale
  • Walkera UFO - one of the first true drones
  • Walkera UFO - 3X scale for visibility and ease of flying
  • dronedil.jpg

    List of PRE-Flight Drone Edition sceneries (all sceneries have customizable wind conditions):

  • Target Practice Scenery for accurate cargo deliveries
  • Fireworks sceneries
  • London Eye - animated
  • Statue of Liberty - great for FPV exploring
  • Titanic - explore the outside, and inside of this famous vessel
  • Titanic and Iceberg - on a meeting with destiny
  • Titanic sinking - be in the front seat with FPV
  • 200 Windmills - animated windmills
  • T62 Tank - animated - try to track this intimidating object in FPV
  • T62 Tank - static - not so intimidating

Please visit www.preflightsim.com for details.

Read more…
Moderator

Great Stuff

3689627471?profile=original

A quadriplegic man who is confined to his bedroom has used his computing expertise to see the world from his bedroom, by flying a camera-mounted drone up to thousands of miles.

Stuart Turner could soon be looking round the Grand Canyon or Niagra Falls using the 2kg flying device, which he controls by moving his head his head and eyes using Google Glass computer worn on his head.

The 36-year-old has lost the use of his arms and legs over the past 10 years, due to spine and brain disorders including spina bifida, tethered spinal cord syndrome and chiari malformation.

Mr Turner, who was forced to drop out of a degree in computer science, has been developing the drone, and the software to control it, with scientists at Brown University, Rhode Island. He uses a Parrot AR Drone which has four separate rotary blades with a camera mounted on its body.

The device is still in testing phase, meaning that Mr Turner has so far only flown it around campus. He hopes to develop it further by replacing Google Glass with a type of virtual reality headset that will give him a three-dimensional, panoramic view of the drone’s location.

http://www.telegraph.co.uk/technology/11252632/Bedroom-bound-quadriplegic-develops-drone-to-see-the-world.html

Read more…

3689627287?profile=original

Hi again,

Hereby I'd like to continue my project. As I said earlier, all parts were printed using a Stratasys 3D printer, which uses FDM technology and support material too. These were the parts coming from the printer:

3689627371?profile=original3689627402?profile=original 

3689627387?profile=original

3689627320?profile=original

I made a small PCB for the modified USB plug:

DSC_0818_www.kepfeltoltes.hu_.jpg?width=200DSC_0819_www.kepfeltoltes.hu_.jpg?width=150DSC_0820_www.kepfeltoltes.hu_.jpg?width=145

DSC_0821_www.kepfeltoltes.hu_.jpg?width=150 DSC_0824_www.kepfeltoltes.hu_.jpg?width=150 DSC_0825_www.kepfeltoltes.hu_.jpg?width=170

Assembly of the arms:

DSC_0841_www.kepfeltoltes.hu_.jpg?width=300

DSC_0839_www.kepfeltoltes.hu_.jpg?width=300

DSC_0845_www.kepfeltoltes.hu_.jpg?width=300

DSC_0842_www.kepfeltoltes.hu_.jpg?width=300

USB plug assembled - plug-n-play solution for Mobius!

DSC_0852_www.kepfeltoltes.hu_.jpg?width=300

And finally some fully assembled shots. Now I'm waiting for the yaw motor and the controller to be delivered. After that I'll start testing in PART3. So stay tuned!!!

Best regards

Adrian

DSC_0850_www.kepfeltoltes.hu_.jpg?width=300

DSC_0851_www.kepfeltoltes.hu_.jpg?width=300

Read more…

Prototype Tiltrotor Development using APM 2.5

3689627595?profile=original

We are a two-man team that just completed the first major phase of our yearlong APM 2.5 tiltrotor project. We wanted to keep things in the dark until we knew it had potential. Here is a quick summary, but if you’re interested in VTOL aircraft, we’d really like you to read our detailed project summary (attached PDF) and give us some feedback.

Just some of many major accomplishments include:

Design and manufacturing of a tiltrotor on a relatively low budget.

  • Utilized many free software applications to make educated design compromises
  • Utilized 3D printing to create complex flight control components
  • Slow, methodical engineering to identify problems and solutions before first flight

Stable hover with conversion to 23 m/s full airplane flight

  • Light hover maneuvering completed in STABILIZE
  • Hovering tested in LOITER
  • Thrust vector can be set at any intermediate angle and flown carefree all the way to airplane mode

Merged several significant portions of Arducopter and Arduplane software on APM 2.5 hardware

  • Heading strategies for quad and plane merged with unique tiltrotor control
  • Seamless blend of servo actuated aerodynamic surfaces, and 2 brushless motors to achieve stable flight at any speed and intermediate thrust angle

 

Tiltrotor 1 Prototype Stats:

  • All-up Gross Weight = 2.4 KG
  • Motors= 2x G15 810kv with 14 inch CF props / single 3300 mah battery
  • OGE Hover Power Required - 40 amps
  • Conversion Power Required – Thrust vector at 30 degrees from vertical 10 m/s = 20 amps
  • Airplane Power Required - 23 m/s = 30 amps

 

We have lots left to do, but would love to get some feedback to help guide us.

Here is what we have planned next:

Autonomous Flight

  •  Merge Copter and Plane navigation strategies to suit a tiltrotor.

Pixhawk

  • We’d love to incorporate the new capabilities of EKF, spline waypoints, terrain following ect someday. The APM 2.5 has not limited our development at all, and is still our bread and butter.

Tiltrotor 2?

  • We learned A LOT in a year. There are numerous things we can make better on this prototype, or improve upon with the “next generation” model. We’d like to build a bigger, better, more efficient tiltrotor with all the lessons learned. This is where we need some feedback from the community. Please read the detailed design summary (attached).

 

Of course we are not going to brag about designing a tiltrotor and NOT post a video.

 Tiltrotor_1_Design_Summary.pdf

This barley summarizes a year of work in 10 minutes.

 

Read more…
Developer

ArduCopter 3.2 Released

ArduCopter 3.2 (aka APM:Copter) has been released as the default version replacing AC3.1.5. This is the exact same version that we invited all users to test two weeks ago.  Users who wish continue using AC3.1.5 can find it under the "Pick previous firmware" version on the MP's Install Firmware screen.

The full list of changes can be found in the ReleaseNotes but here are the highlights:
Flight Mode Enhancements:

  • PosHold flight mode: similar to Loiter but with direct response to pilot input during repositioning
  • ACRO mode handling improvement EXPO (for faster rotations)
  • Drift mode uses "throttle assist" (similar to AltHold)
  • Smoother transitions between flight modes (i..e when entering Loiter or RTL from high speeds)

Mission Enhancements/Fixes:

New Sensors/Devices:

Safety Features:

  • EKF/DCM check will switch to LAND mode if heading error > 60deg for 1 second
  • Baro glitch detection
  • Pre-arm check for Gyro calibration success
  • Pre-arm check that internal & external sensors (gyros, accels and compass) are consistent (Pixhawk only)
  • Parachute support (Pixhawk only)
  • Feedback to Pilot when taking off in AltHold, Loiter, PosHold (i.e. motors spin up a little as throttle is raised)
  • EKF (new attitude and position estimate system only used for reference in this release)

Bug Fixes:

  • Pixhawk GPS driver buffer overflow that could lead to missed GPS messages
  • Pixhawk I2C bug that could lead freeze up if I2C bus is noisy


Known issues/Warnings:

  • Pixhawk users will need to recalibrate their compasses
  • PosHold won't show up as option on FlightMode screen if you have an old version of mission planner. Please select Help > Check for Updates.
  • Landing detector is more strict meaning it may take longer to disarm after RTL, AUTO.
  • Set THR_MID parameter especially if you have a very powerful copter because "Feedback to Pilot" raises throttle to 1/2 of THR_MID
  • Spline twitches slightly as it passes a waypoint especially if WPNAV_SPEED is set > 500.
  • Dropped support for NMEA and SIRF GPS on APM boards (ran out of Flash space)
  • Dropped support for sonar for MultiCopters on APM1 and TradHeli on APM1 & APM2 (ran out of Flash space)

If you hit issues, please post them in the APM Forum and include a dataflash log file if possible.

Special thanks to Marco and the Beta Testing team from the AC3.2 beta testing thread who put their copters at risk in the pursuit of a smooth, safe release. Here are links to some of their videos: Marco's DJIs900, Holger's Water Tower, Josh's Acro, Ray's TradHeli2&FPV, Raph's Hawaii, PhillS's CommandYaw, Thor's Zombie Run&FollowMe, Phanivyas's Test, Rob's TradHeli, Christian's Test1&Test2, Balloon's Spline, JimJ's FPV, Ultrojo's ROI & Spline&FollowMe1&FollowMe2, Troy's Mission

Thanks also to the code contributors to this release including Tridge, Jonathan, Leonard, RobL, Paul Riseborough, MichaelO, Julien Dubois, David Dewey, Andrew Chapman, Emile, Allyson and many more. If you want to get involved check-out our dev wiki.

Read more…
Developer

APM:Plane 3.2.0 released

3689591584?profile=original
The ardupilot development team is proud to announce the release of version 3.2.0 of APM:Plane. This is a major release with a lot of new features.

The changes span a lot of different areas of the code, but arguably the most important changes are:
  • automatic stall prevention code
  • PX4IO based RC override code on FMU failure
  • I2C crash bugfix
  • new autoland code from Michael Day
  • compass independent auto takeoff

I'll go into each of these changes in a bit more detail.

Automatic Stall Prevention

The automatic stall prevention code is code that uses the aerodynamic load factor (calculated from demanded bank angle) to adjust both the maximum roll angle and the minimum airspeed. You can enable/disable this code with the STALL_PREVENTION parameter which defaults to enabled.

When in stabilised manual throttle modes this option has the effect of limiting how much bank angle you can demand when close to the configured minimum airspeed (from ARSPD_FBW_MIN). That means when in FBWA mode if you try to turn hard while close to ARSPD_FBW_MIN it will limit the bank angle to an amount that will keep the speed above ARSPD_FBW_MIN times the aerodynamic load factor. It will always allow you at bank at least 25 degrees however, to ensure you keep some maneuverability if the airspeed estimate is incorrect.

When in auto-throttle modes (such as AUTO, RTL, CRUISE etc) it will additionally raise the minimum airspeed in proportion to the aerodynamic load factor. That means if a mission demands a sharp turn
at low speed then initially the turn will be less sharp, and the TECS controller will add power to bring the airspeed up to a level that can handle the demanded turn. After the turn is complete the minimum airspeed will drop back to the normal level.

This change won't completely eliminate stalls of course, but it should make them less likely if you properly configure ARSPD_FBW_MIN for your aircraft.

PX4IO based RC override code

This releases adds support for PX4IO based RC override. This is a safety feature where the stm32 IO co-processor on the PX4 and Pixhawk will give the pilot manual control if the main ArduPilot micro-controller fails (or the autopilot code crashes). This is particularly useful when testing new code that may not be stable.

As part of this new RC override support we also have a new OVERRIDE_CHAN parameter, which allows you to specify a RC input channel which can be used to test the RC override support. See the documentation on OVERRIDE_CHAN for details.

I2C bugfix

This release fixes another I2C bug in NuttX which could cause the Pixhawk to lock up under high I2C load with noise on I2C cables. This bug has caused at least two aircraft to crash, so it is an important fix. I hope this will be the last I2C crash bug we find in NuttX! An audit of the code was done to try to confirm that no more bugs of this type are present.

New Autoland code

This release incorporates some new autoland capabilities contributed by Michael Day. The key new feature is the ability to trigger an automatic landing when a RTL completes, which for the first time allows a user to setup their aircraft to land using only transmitter control.

The way it works is there is a new parameter RTL_AUTOLAND. If that is set to 1 and the aircraft reaches its target location in an RTL it will look for DO_LAND_START mission item in the mission. If that is found then the aircraft will switch to AUTO starting at that section of the mission. The user sets up their land mission commands starting with a DO_LAND_START mission item.

There is more to do in this autoland support. We have been discussing more advanced go-around capabilities and also better path planning for landing. The code in this release is an important first step though, and will be a good basis for future work.

Compass independent takeoff code

The auto-takeoff code has been changed to make it more independent of compass settings, allowing for reliable takeoff down a runway with poor compass offsets. The new takeoff code uses the gyroscope as the
primary heading control for the first part of the takeoff, until the aircraft gains enough speed for a GPS heading to be reliable.

Many thanks to all the contributors, especially:

  • Paul and Jon for EKF and TECS updates
  • Bret and Grant for stall prevention testing
  • Michael for all his autoland work
  • all the work on NavIO, PXF and Zynq by John, Victor, George and Siddarth
  • The PX4 team for all the PX4 updates
  • Flaperon updates from Kirill

More complete list of changes:

  • allow GCS to enable/disable PX4 safety switch
  • make auto-takeoff independent of compass errors
  • report gyro unhealthy if calibration failed
  • added support for MAV_CMD_DO_LAND_START
  • added RTL_AUTOLAND parameter
  • disable CLI by default in build
  • new InertialSensor implementation
  • added landing go around support
  • enable PX4 failsafe RC override
  • added OVERRIDE_CHAN parameter
  • changed default AUTOTUNE level to 6
  • changed default I value for roll/pitch controllers
  • added CAMERA_FEEDBACK mavlink messages
  • use airspeed temperature for baro calibration if possible
  • added STALL_PREVENTION parameter
  • fixed handling of TKOFF_THR_MAX parameter
  • added ARSPD_SKIP_CAL parameter
  • fixed flaperon trim handling (WARNING: may need to retrim flaperons)
  • EKF robustness improvements, especially for MAG handling
  • lots of HAL_Linux updates
  • support wider range of I2C Lidars
  • fixed fallback to DCM in AHRS
  • fixed I2C crash bug in NuttX
  • TECS prevent throttle undershoot after a climb
  • AP_Mount: added lead filter to improve servo gimbals
  • Zynq and NavIO updates
  • fixed preflight calibration to prevent losing 3D accel cal
  • perform a gyro calibration when doing 3D accel cal
  • added DO_CONTINUE_AND_CHANGE_ALT mission command
  • added support for DO_FENCE_ENABLE mission command
  • allow gyro calibration to take up to 30 seconds
  • improved health checks in the EKF for DCM fallback

Note: If you use flaperons you may need to re-trim them before you
fly due to the change in flaperon trim handling.

I hope that everyone enjoys flying this new APM:Plane release as much as we enjoyed producing it!

Happy flying!
Read more…

3689627042?profile=original

3689626897?profile=original

3689627107?profile=original

3689541667?profile=original

We have just completed a flight test program of our MK-II SurVoyeur UAV System after having fitted the new Autopilot/IMU. This autopilot replaces the 32bit AVR based autopilot in our preceding UAV's, with a view to giving a big boost in performance, shorten IMU cycle times ( from 200Hz), and eliminating all the component obsolescence issues of the AVR based modules.

The autopilot is again a single module, but now contained all the video switching for up to 4 video sources, switchable from the ground station, all the DC-DC convertors for up to eight Medium size Digital servos, all the power supplies for Datalink and video transmitter modules, as well as all power conditioning for the EO-IR stabilized gimbal fitted to the MK-II system.

There are now 6 serial channels ( RS422/RS232/TTL configurable) , 11 PWM outputs, Analogue inputs for Laser Rangefinder. Ultrasonic Rangefinder, ESC/Motor Amp measurement, and for a two cylinder Gas engine CHT measurement ( using thermocouples).  External Air temp is also measured to do Static Pressure compensation for Baro Alt.

The module is also fitted the Measurement Specialities 24bit Static and Dynamic pressure sensors. In addition, a further 6 (!) digital static pressure sensors are fitted. 

These are :

MS5611  ( two fitted in different locations)

MPL3115

LPS331

BMP180

LPS25H

The reason for this was really to test the performance of each of these sensors, and as they cost very little, we decided to include them all on the final modules.  Since most actually all work quite well, we are implementing a redundancy selection scheme to select working sensors from failed ones, just because they are there...

The sensor we are most unhappy with is the 24bit Measurement Specialities device the MS4525HDR. It is so complex to manage, each sensor serial number is supplied with a special set of coefficients that are used in a complex set of computations to do the pressure/temperature computation. These coefficients have to be stored on-board the autopilot which means each software load has a specific module particular to that board. A config management mess...since the coefficients are not stored within the sensor by the manufacturer, but on a piece of paper supplied with the sensor. Nuts!

And then the sensor performance over the range 0 to 60deg C is not great - it varies by more than 5millibar ( 40meters!). So, on top of its complexity, we still have to do a 2nd order polynomial temp correction to get better than 0.5millbar variation over that temp range. It does not end there - it is also very susceptible to vibration - in the plot below, you can see the wild oscillation  ( blue line) as soon as the wheels start to roll, and how the pressure reading goes smooth again as the wheels lift off the ground : From vertical lines 2 up to 4. The graph is in pressure, so the graph shows reducing pressure as the plane climbs from vertical line 4. The oscillation is a peak to peak value of 0.9millibar - nearly 8 meters! Certainly cannot use this sensor to know if you have lifted off the ground! We use the LRF...

Measurement Specialties just snubs us - we are to small for them to be concerned about our 'bad' report...

3689627122?profile=original

The IMU is fitted with two MPU6500, each running a full IMU at 400Hz, but with different filter coefficients within the Kalman filter - this helps tremendously in the elimination of IMU bias or drift during high vibration, such as during taxi on rough ground.  An HMC5883 Magnetometer is also fitted as a separate module, able to be located in a clean environment on the A/C.

ALL sensors are fully temperature compensated from 0deg C to 65deg C

The host processor is the STM32F427, running at 140MHz.

Failsafe is managed by a separate AVR processor on the module.

We also used large connectors so that cables are more easily crimped, more reliable, and fit securely.

( see my previous blogs for info on the previous autopilots)

The test aircraft was fitted with is full payload - an EO-IR stabilised gimbal ( Sony EX11 block cam, and FLIR QUARK IR CAM), and a 16Mpixel fixed down looking stills camera, snap and focus controlled by the autopilot.

The Laserman ( Lightware) SF10 laser rangefinder is also fitted as the main landing aid sensor, as visible in the above photographs. 

Here are some photos of the autopilot module:

Top view of full board:

3689626986?profile=original

These are the two module in the middle, containing the inertial sensors and all the pressure sensors. They are separate , small PCB's, so that they can be easily exchange for ones fitted with newer devices, etc.

3689627062?profile=original

The flight test were very successful, the new autopilot performs very well, and the IMU worked as designed...

The launch and landing plots below show the Height above ground from Baro Pressure sensor and the laser Rangefinder height to ground.

This is the auto-launch plot:

The image is not very clear, but resolution on the blog post does not really allow any better...

The green is the Rangefinder, which works to 60meters, but we limit it at 40meters, since we are not interested in range above that.

The red is pressure height AGL.

The vertical delimiters are 2.4seconds apart. Wheels up are at the 4th vertical.

The 'step' in the red line at middway between 9 and 10 is where we command a change in datalink TX power from 1milliwatt to 100milliwatts which results in a short link loss period.

A nice smooth climb of the A/C. The left scale is 4meters per horizontal line.

What is very evident is the lag in pressure altitude measurement during the climb - the lag is almost a half second. The air pressure measurement is not filtered or smoothed at all, so it is purely the digital sensor internal oversampling delay.

3689627136?profile=original

And the Auto-landings , below, are a thing of beauty!

Red again is pressure based height AGL, green is LRF.

And again, the step middway between the 1st and 2nd verticals is the switch from 100milliwate back to 1milliwatt on the datalink , because we land about 10meters away from the ground station, and 100milliwatts saturates the RX at that range - the Xbee 868MHz modem are VERY sensitive - we get nearly 30km range at 300milliwatts with 1/2 wave dipoles.

The landing is a circle, starting at 100meters height, and spiraling down, till about 20meters AGL ( vertical line 6 approx) and then unrolling, straightening out onto track to touch down at a GPS point ahead. It is seen that the LRF and Pressure height track reasonably well, but the pressure sensor lag is still evident.

At vertical 11, we are at approx 6 meters height, and we begin final landing control, at 4 meters we kill throttle, and start the flare maneuver, which completes at 0.4meters above ground, and a smooth gentle touchdown at just after vertical 16, at about 0.5m/s sink rate. After 14 such landings the min sink rate achieved was 0.3m/s at touchdown, and the max was 0.7m/s. Windspeeds during the 14 flights varied from 4m/s up to 13m/s.

We never managed this reliably at all with pressure only landings, and with the previously fitted ultrasound sensors we often had 'hard' landings, due to the fact that the switch from pressure height to actual ultrasound height would only occur at 5meters AGL or so - the typical range of ultrasound sensors over rough ground. With laser we switch to the LRF height at 30 meters already, and are able to compensate for any pressure sensor drift in good time.

The system is now totally hands off....Push the button and go..

3689626999?profile=original

The NamPilot...

Read more…

3689626935?profile=originalHi guys, 

let me introduce my latest project, a 3D printed gimbal for MobiusHD camera. I call it GimBALL regarding of it's shape...

My goal was to make a closed, aerodynamic shaped gimbal, which can be used in the front of a plane (ie. X-UAV Talon), up to 100 km/h airspeed. So I tried to make thisthing  as aerodynamic as it can be. For drive I choosed three size of motors, according to the weight they have to rotate.

The smallest is for pitch axis, a HK 2206-140KV,  RCTimer 2212 is on roll and RCTimer 2804 hollow shaft is on yaw axis. I'll use a basecam 8bit 3-axis controller placed inside my plane's fuselage.

For easy operation and FPV purposes, I made a small PCB from an USB plug which will be fixed inside the GimBALL. So Mobius have to be plugged in, that's all. There is a hole for easy SD-card removing and also there are holes for buttons and LED.

I checked the main parts with FEM analysis to be sure they are optimized for external loads (parts weight and wind force):

3689626860?profile=original 3689626956?profile=original 3689626951?profile=original

All parts will be printed using a Stratasys 3D-printer (using FDM technology). Total weight including MobiusHD and motors, screws will be around 280 g (+-15g). 

Here are some renders about details:

3689627015?profile=original

3689626882?profile=original

3689626963?profile=original

Next step will be the parts producing and assembly (PART2) and final testing (PART3). So stay tuned!!!

Regards

Adrian

PS.: I'm not planning to produce this GimBALL but if anybody interrested in start producing, just write me an email (nhadrian@gmail.com), since I'm willing to sell 3D models - basically trade for smaller parts that are useful for my projects!!! But I don't have any time to produce parts and take support for customers, etc ... so please don't ask me how much will be a ready- to -use GimBALL...Thank you for your understanding!!!

Read more…

Maiden drive of APM:Rover2 on Raspberry Pi with Navio

3689626849?profile=original

Hello guys!

We were fascinated by the idea of controlling a drone directly from Linux from the very beginning. Navio was created exactly with that purpose in mind. Your support let us finalize the hardware and get to running APM on Raspberry Pi with Navio. We have already showed our progress on drivers and making different parts work, but it was time to actually drive it. Seeing the thing finally make its first autonomous turns in an empty parking lot, even with not tuned PIDs is a large step forward in our project.

Many people already have received Navios and are looking forward to new possibilities with Linux based APM. We have prepared guides on proper setup of equipment:

Here’s the list of currently working features:

  • Onboard IMU - MPU9250 
  • Onboard barometer - MS5611
  • Onboard magnetometer - AK8963 (as part of MPU9250)
  • Onboard GPS - U-blox NEO-7M
  • RC output using onboard PCA9685 PWM generator
  • PPM input decoding using DMA GPIO sampling with pigpio library
  • External GPS over UART
  • External I2C magnetometer
  • Telemetry over USB or UART or WiFi
  • RGB status LED
  • Voltage and current sensing with ADC (ADS1115)

Some of these are still in the prototype state, but we hope to finalize them soon. Thanks to the APM’s HAL all drivers are the same for Rover, Plane and Copter, so the first plane flight on Raspberry Pi with Navio is not far ahead - we’ll make it as soon as we do some additional testing with rover.

Special thanks to Andrew Tridgell and APM team for their help along the way.

3689626692?profile=original

Best regards, 

Emlid team

www.emlid.com

Read more…
3D Robotics

3689626677?profile=original

Highly anticipated federal rules on commercial drones are expected to require operators to have a license and limit flights to daylight hours, below 400 feet and within sight of the person at the controls, according to people familiar with the rule-making process.

The drone industry has awaited commercial rules for about six years, hoping the rules would pave the way for widespread drone use in industries such as farming, filmmaking and construction. Current FAA policy allows recreational drone flights in the U.S. but essentially bars drones from commercial use.

While the FAA wants to open the skies to unmanned commercial flights, the expected rules are more restrictive than drone supporters sought and wouldn’t address privacy concerns over the use of drones, people familiar with the matter said.

The agency also plans to group all drones weighing less than 55 pounds under one set of rules. That would dash hopes for looser rules on the smallest drones, such as the 2.8-pound Phantom line of camera-equipped, four-rotor helicopters made by China’s SZ DJI Technology Co. Similar-sized devices are seen as the most commercially viable drones and have surged in popularity in the last two years.

Small-drone supporters say such models are less risky to people and structures than heavier drones like Boeing Co. ’s ScanEagle, a gas-powered, 40-pound aircraft with a 10-foot wingspan that can stay aloft for more than 24 hours. ConocoPhillips Co. uses the ScanEagle to gather data on Arctic ice pack and whale migrations.

In addition, pilot certifications likely to be proposed by the FAA would typically require dozens of hours flying manned aircraft, according to people familiar with the rule-making discussions. Drone proponents have resisted requiring traditional pilot training for drone operators.

FAA officials expect to announce proposed rules by year-end. The proposal will kick off a public comment period that is likely to flood the agency with feedback. It could take one or two years to issue final rules.

In a statement, the FAA said it is working to “integrate unmanned aircraft into the busiest, most complex airspace system in the world—and to do so while we maintain our mission—protecting the safety of the American people in the air and on the ground. That is why we are taking a staged approach to the integration of these new airspace users.”

The White House Office of Management and Budget is reviewing the current FAA proposal and seeking comments from other parts of the government, including the Pentagon and law-enforcement agencies. Last-minute objections could change some specifics and delay release of the proposed rules.

The agency has said it is moving carefully on drone rules out of concern for potential collisions with other aircraft and injury to people and structures on the ground.

Airline pilots and aircraft owners have supported the cautious approach. But some drone-industry officials predict a loud backlash to the proposal.

“I feel like there’s a colossal mess coming,” said Michael Drobac, executive director of the Small UAV Coalition, an advocacy group for drone makers and innovators, includingGoogle Inc. and Amazon.com Inc. The rule is going to be “so divorced from the technology and the aspirations of this industry…that we’re going to see a loud rejection.”

Unmanned aircraft have proliferated in U.S. skies as technology makes them smaller, cheaper, more powerful and easier to fly. While the FAA has helped build unparalleled safety into passenger air-travel with strict manufacturing and operating rules, the system didn’t foresee thousands of small aircraft buzzing around at low altitude.

The FAA’s current policy allows commercial drone flights only with case-by-case approval. Officials have authorized just a handful of companies so far.

Still, thousands of entrepreneurs are believed to be flying the devices without FAA clearance, making it hard for those operators to get insurance.

Some government and aviation-industry officials are worried about surging use without meaningful oversight. Pilots are increasingly reporting midair drone sightings, including three near John F. Kennedy International Airport in New York last week.

Drone proponents say the U.S.’s regulatory approach is less accommodating than in other countries. This month, Canada plans to issue blanket approval for all commercial operations that use drones weighing less than 4.4 pounds as long as they comply with certain safety standards, such as altitude limits and no-fly zones around airports.

The FAA must “properly balance regulatory restrictions and the safety risks posed by” various sizes of unmanned aircraft, said Ted Ellett, a former FAA chief counsel who now is a partner at law firm Hogan Lovells US LLP. Mr. Ellett said a “one-size-fits-all” approach “will create yet another unnecessary and costly impediment.”

Gretchen West, former executive vice president of the Association for Unmanned Vehicle Systems International, the nation’s biggest drone-lobbying group, said large, powerful drones like those used by the military got more attention when the FAA began working on the rules.

Since then, much of the growth has shifted to smaller drones. The expected rules are “going to be very restrictive for small systems,” she added.

Jesse Kallman, head of regulatory affairs for drone-software firm Airware, said requiring commercial drone pilots to have cockpit training “will end up excluding someone who has hundreds of hours of experience on an unmanned aircraft in favor of a pilot who understands how to operate a Cessna but not an unmanned aircraft.”

In exemptions granted to six filmmaking companies to use drones on film sets earlier this year, the FAA required operators to have private-pilot licenses.

The FAA’s draft rule is expected to require lower-level pilot certifications requiring fewer flight hours, according to people familiar with the matter.

One former FAA official said the agency is concerned that statutes bar it from authorizing commercial aircraft operations that don’t have a certified pilot.

The agency is drafting language asking Congress for greater flexibility, this person said.

The planned 400-foot flying limit within the operator’s sight largely follows the FAA’s current rules for recreational uses of drones. Those rules are based partly on voluntary guidelines for model aircraft published by the agency in 1981.

Drone proponents say the FAA is relying on decades-old regulations that don’t account for advancements in technology. Many drone pilots use “first-person view” technology allowing them to rely on real-time footage from a drone’s camera broadcast to their controller or headwear that resembles virtual-reality visors. Users can add infrared and other sensors for night or low-visibility missions.

The FAA’s expected requirement for daylight flights within the operator’s sight would essentially prohibit many commercial applications, such as pipeline inspections and crop monitoring on large farms.

The FAA is awaiting data from a number of test sites before proposing regulations affecting drones that weigh more than 55 pounds. That process is expected to take at least several years. Until then, many states and local governments are likely to establish their own standards.

Read more…

Exmaps: Online Flight Logbook for Ardupilot Update #3

3689626656?profile=original

More updates!

3689626763?profile=original

1) Ability to input and save notes at the Loglist page and Log page

You can now make notes about change in parameters, upgrades, batteries etc. 

2) Facebook, Twitter sharing integrated in Loglist page. (blue slider bar) 

Posts to Facebook and Twitter will include a static image of the map with flight lines and automatically formatted text about the flight

3) Relative height

3689626733?profile=original

Mouse over Altitude graph now provides relative height to take off height. 

Bug Fixes

- Mode for Tlogs 

Try out the drone logbook service for free at www.exmaps.com and let us know your thoughts at hello@exmaps.com

Read more…

Apprentice Drone kit conversion

3689626532?profile=original

3689626627?profile=original

Because E-Flight Apprentice RC is very popular airplane and the fact that you can buy any replacement part for it I decided to design a 3D printed kit that would turn it into a Drone. The kit blends perfectly with the wing, it gives you easy access to the electronics from the top and also increases the wingspan by 3 inches. I am using the APM 2.6 but it could be used with any other autopilot, there is plenty of room, on the front I have a grill to let the air cool off the electronics and also a flat spot to install your GoPro or any other camera. I will have some kits available soon but you can also do it yourself, 3D printed frame available at https://www.shapeways.com/model/2743456/a-d-k-apprentice-drone-conversion-frame.html. 

https://www.youtube.com/watch?v=23bbqSXeAsI

Appreciate any comments.

3689626601?profile=original

Read more…

The Aeromapper 300 is the latest UAV offer from Aeromao Inc. Canada.

The Aeromapper 300 is one of the most complete UAV for general mappping applications, at the most competitve price on the market. Powerful yet very easy & friendly to use, with 1.5 hour endurance, currently more than two dozen different sensors or combination of sensors supported via swappable mounts, safe parachute landing capability, hand or catapult launch supported, long range data link and control and of course, fully automatic flight.

Despite its size it also has a small turning radius (about 30 m turning radius), making it also ideal for those low altitude–high ground resolution flights in which the flight lines are pretty close to each other.

The standard package of the Aeromapper 300 includes the Sony Nex 7 (24 MP) with a survey grade wide angle rectilinear lens. The UAV is also conceived to carry the mighty Sony Alpha a7r with 36 MP.

Customers can also choose from a large variety of payloads and sensors with swappable mounts, even combination of them (like Sony Nex 5 + tetracam ADC Micro, with simultaneous trigger). Information on the list of sensors and payloads for the Aeromapper family of UAVs is found here: http://www.aeromao.com/uav_payloads

The Aeromapper 300 also comes with a detailed User Manual well supported for first time users with no previous experience using drones, and trainings are also available in Ontario, Canada. Included in the package are all the accessories required as well as quality carrying cases.

Similarly to its smaller brother Aeromapper EV2, the Aeromapper 300 uses the concept of a highly engineered payload bay module attached to a high performance carbon fiber glider aircraft. Using this approach the company is able to offer high end UAVs at the fraction of the cost of other similar drones.

Most UAV manufacturers design and fabricate the fuselage and wings of their drones from scratch, leading to high pre and post production costs. The pod concept used by Aeromao reduces production costs immensely and provides additional advantages:

1. Modularity: since most of the electronics, payload and parachute system are contained in the payload module the fuselage can be easily exchanged for a new one, if required. This process usually takes two hours or less and can be done by the user. In other UAVs if the fuselage is not usable all the electronics and key components need to be migrated to a new fuselage, basically reassembling a new UAV (which leads to high costs and longer lead times)

2.  Cost Savings:  leveraging on an existing glider airframe produces immense savings, which are passed on to UAV customers. The Aeromapper 300 can match the specifications of other drones that cost $50,000 - $70,000 dollars.

3.  Customization: pods can be easily customized for special applications, again, thanks to not having to modify an entire airframe. Customizations are usually affordable and fast.

4.  Speed of adaptation: probably one of the most important advantages in the UAV market is the speed at which UAVs can adapt to new applications. If required, only the pod needs to be modified, not the entire fuselage.

For more information please visit http://www.aeromao.com/aeromapper_300

Read more…

3689626577?profile=original

3689626522?profile=original

Wide angle laser beams can detect and measure the range to people, trees and other safety critical objects from moving aerial or ground based platforms.

We've been experimenting with a new version of our SF10 laser altimeter to see what happens when we change the normally narrow, parallel laser beam into a wider, fan shape and align it horizontally or with a downwards tilt. There is a practical limit to the wide direction (major axis) of about 30 degrees but any angle from zero to thirty degrees is attainable. The best combination of range and sensitivity is found using a 10 x 3 degree beam pattern that can detect a person more than 10m away.

The two pictures above show the SF10 laser unit and an example of the modified laser beam pattern. The intensity, and therefore the detection sensitivity, is pretty uniform across the beam so even obstacles right at the edges give a good return signal. We're using time-of-flight technology to work out the distance and the unit has I2C, serial and analog interfaces.

The real purpose of this blog post is to ask the knowledgeable members of this forum for feedback about possible applications for wide laser beams, used either stand alone or in multiples. I admit that this is not going to be the ideal solution to every problem. Instead, I hope to use your feedback as a sanity check to see if we're going in the right direction with this technology.

Thanks, LD

Read more…