Blogs

Getting ready for the start of our next live podcast in a couple of hours time (you can download it later) 10:00 PST about 17:00 GMT I think (could very well be wrong)

The show link here

http://www.blogtalkradio.com/suasnews

Should also tell you what time it starts local to you.

If you have any questions for the airframe and autopilot designers, Jimmy Prouty and Chris Mc Nair then please send them to patrick@suasnews or tweet them at @sUASNews and if he can he will put them to them.

In this installment, we will discuss the role sUAS plays in assisting the Sea Shepherd in their ongoing endeavor to help safeguard the inhabitants of our delicate ocean ecosystems. Sure to be an exciting and informative dialogue, with all that had to be overcome operating an unmanned system from the high seas. We look forward to finding out more about this admirable example of what can be accomplished with a low risk, low cost solution.

Whilst not a aerial drone.. it still must be one of the coolest!

The links are below:

http://www.spaceflightnow.com/news/n1205/10rovertest/

http://www.reuters.com/news/pictures/slideshow?articleId=USRTR31W10

http://www.kcet.org/updaily/socal_focus/technology/mars-rover-piece.html

This is a simulation I'm working on to improve the Loiter control laws and discover optimal gains. I have identical code from Arducopter running in Flash as OO Javascript so I can ensure the behavior is the same as the real thing. I tested the MTEK GPS to find the actual latency and accuracy and then modeled it in code. This allows me to test PIDs and other coding ideas to see how the copter will behave in real life. The copter itself is a simple physics equation and should be fairly accurate. To better tune the SIM, I can compare AC Flash Logs from real flights side-by-side with the SIM flights which also output the same text based logs.

I've already found many areas for improvement in the Loiter code which i've just checked in to the GIT repository. 

Hopefully this tool will serve as a great PID introduction as well. I know I've learned a lot by comparing plots with small changes in the gains. 

Jason

Ok, I can honestly say, that I would never even attempt this with Arducopter.

Check out the AeroQuad website, if you're interested in learning more.

The Sparkfun Autonomous Vehicle Competition is on June 16th, just a month away! Once again the DIY Drones teams will be well represented, with at least 15 people from the APM team alone coming and competing. There will be the usual barbecue at Doug Weibel's house on Friday night, so if you're coming the competition and would like to join us, please give us your name in the comments below, so we can get a headcount.  

This year only airplanes (and rovers, of course) are allowed in the official Sparkfun competition on Saturday, so we're going to run our own DIY Drones Multicopter Competition on Sunday, with a location to be announced near the Sparkfun headquarters in Boulder.  So although Sparkfun doesn't want them, bring your multicopters (and traditional helis) anyway and stick around to Sunday for an all-copter competition, with cool prizes and good fun. Please give your name in the comments below if you'd like to enter in the Sunday competition, so we can plan accordingly.

Looking forward to seeing everyone in Boulder!

Hello everyone:

I don't know where to begin! This last 4 months has been amazing and very challenging. :) I couldn't have made it this far without the help the beta testers, Pteryx UAV (Krzysztof Bosak), Jeff Taylor, Irvin Stafford, Michael Oborne, Martin R and others. Thank you guys. As of now, we have a full feature set for the launch of the site around June 1st (maybe sooner). I don't have GCP support yet, but that is coming when I can get some additional time and maybe some development funds. I am pretty back logged processing flights and I am happy to report we've passed the 5000 imagery mark. Pretty cool! :D

I have been working with various companies to verify accuracy/resolution and result generation. It has been invaluable. I have to say that I am utterly amazed at the quality and consistency of the Pteryx UAV platform!

Here is an example of the worldfile results for a recently process Mikrokopter job. This job result was DEM 3cm/px with smooth/blending and Orthomosaic at 1.8cm/px.

0.0180503004230558872
0.0
0.0
-0.0180503004230558872
455529.862196518574
5569638.87532691658

(above image is SenseFly UAV Quarry Sample Imagery via DroneMapper)

Still lots of work to be done, bugs to fix and features to add. I am hoping to get some additional help with DroneMapper soon. 

Cheers and many thanks Pteryx UAV

JP Stoermer

This is a schematic of my wiring of the ArduIMU v3. I hope to be able to use this soon as my own personal and custom RTH and 'stabilized mode' solution with some extra benefits highlighted below. One extra analog pin will be used in the future to read out the RSSI level from the attached RC receiver.

This setup demonstrates how far you can push this remarkable board. The W5100 chip provides 30Hz telemetry over wifi to the ground (just make sure to use the sparkfun one, I've seen other implementations with a hardware bug that only allow that SPI device on the bus). It requires a wifi AP specifically designed for long-range connections that allows you to set some specific parameters for your intended range, up to 50km. I still need to see how this performs in the field though, but theoretically it should work nicely.

I'm using this setup in combination with an HD IP camera for a 720p video feed that has 150-200ms latency. The weight of that cam is 160g, so about the same as a gopro+analogcam. The two IP devices onboard are then connected to the onboard LR wifi station by a stripped down ethernet hub I found that fit the requirements. Regular, non-shielded, ethernet cables are stripped down (2x twisted pairs without grey insulation), which over these short distances and bitrate aren't any problem (20-40cm). All in all, it's about 100g heavier than a full analog setup on the same platform (2.3kg).

The benefit of digital over analog is that it's much easier to integrate both the vehicle and sensors into more complex ground station applications. The tasks for piloting, navigation and mission execution for example can be cleanly separated in either machines or persons.This opens up a range of possibilities of how people with different responsibilities interact with the platform or how they use the data that the plane is sending down at high bitrates.

I hope this ignites interest a bit in higher speed datalinks. Although I did manage to find the electronics for connecting stuff together, the hubs and other fairly simple electronics leave many things to be desired. Hopefully more people will consider adding a magjack instead of a serial port on their boards. The advantage of connecting everything on the plane on a single databus is that you can recalibrate *everything* in the air. This opens up ways to use resources more effectively and redirect resources depending on the context within which they are needed. There's something to say for one databus connection that everything is connected to. This facilitates integration and makes interoperability a lot easier.

I don't know how many of you guys have seen this yet, but this is HUGE NEWS for us. No COA needed for drones up to 25 pounds, as long as it's being operated by a U.S. safety agency.

Check out the article that came out 2 hours ago on Bloomberg. 

http://www.bloomberg.com/news/2012-05-14/drones-up-to-25-pounds-allowed-for-u-s-safety-agencies.html

From Hackaday:

Check out this video footage of this LED-adorned RC helicopter flying on a dark night. But this isn’t an art project. Analyzing the long-exposure photography turns out to be a great way of clearing up some of the physics of flight which otherwise are not at all intuitive. The helicopter used here has different colored lights on the nose and tail, as well as lights on the rotors.

Depending on how the aircraft is moving, different 3D spirography is captured by the camera. When you zoom in on part of the flight path it becomes clear that there are wider arcs on one side of the fuselage than there are on the other. This has to do with the forward progress of the aircraft and the rotation of the blades. The phenomenon is well known by helicopter enthusiasts, and accounted for in the design. But what we didn’t realize is that it actually translates to a theoretical speed limit for the aircraft. Our childhood love of Airwolf – the TV helicopter that could outrun jets — has been deflated.

You should remember the helicopter physics videos featured here last month. 

Jordi is one of MIT Tech Review's top ten innovators under 35 in Mexico! From the award annoucement: 

A 21-year old Mexican immigrant faces another day of tedious confinement in his apartment in Riverside, California, waiting to get his green card that would allow him to study, seek work or take out a driver’s license in the US.

Flashback to March 2007 and Jordi Muñoz, a passionate computer man dreaming of becoming a pilot, has just moved with his wife across the border while leaving his engineering studies hanging at the Center for Higher Technical Education of Baja California. “I was mega-bored at home so I started playing with chips and controllers, spent hours experimenting with Arduino (an open source electronic platform) code, browsing and reading on the computer,” said Muñoz.

Thus Muñoz discovered DIY Drones, a forum where thousands of hobbyists who build their own unmanned aerial vehicles share their experiences, code libraries that they develop and adapted to and plans for electronic components with other like-minded individuals.

Immersed in this sea of knowledge, Muñoz not only improved as a developer but he also  inherited the open and collaborative philosophy upon which he has based his career as an entrepreneur and made important contacts. His home experiments attracted the attention of Chris Anderson, Wiredmagazine’s editor, who saw Muñoz’s video of an autonomous helicopter flying using Arduino and a repurposed Wii controller.

Impressed, Anderson gave Muñoz a small amount of funding to manually produce 40 control boards. “They sold the same day and then we realized that here was a business,” explained Muñoz. Lo and behold, 3D Robotics, a company that employs 20 people and according to his estimates, was born. The company expects to generate $4.8 million profit by the end of the year [Editor's note: the translator confused revenue with profit. 3D Robotics is managed to generate no profit, and reinvests all earning into R&D].

This company, of which Muñoz is executive director, sells electronic accessories to hobbyists who build drones in their garage and university professors who want their students to learn engineering via robot design. The most popular product is ArduPilot system, a low-cost and easy to use autopilot. “For less than $200, builders are offered a high-tech system that would cost thousands,” says Muñoz. “Also, as its open source, they can ‘play’ with it and see real-time changes to their modifications.”

Along with teaching applications, these drones (or parts thereof) have proven useful for many other purposes. Using a small drone instead of chartering a helicopter saves a lot of money during surveillance missions, the monitoring of migratory animals or the inspection of archaeological sites.

In 2011, Munoz asked his friend William Romero to found a sister company to 3D Robotics based in Tijuana called Udrones. It is meant to serve the international market and has sent orders to customers requesting fully-assembled and ready-to-fly aircraft to places such as Germany and Australia. Although the manufacturing is done in Mexico with US technological development, the goal is to generate a technical training incubator for Mexican professionals whose skills Muñoz believes will soon be comparable to American engineers. “If the nature of my business was not open-source, I would just open an assembly line in Mexico and the workers would simply put together parts; there would not be a transfer of knowledge,” he explained.

For John Janas, president of the company Janas International Enterprises and TR35 Mexico awards judge, Muñoz’s key value lies precisely “in promoting the ideology of open source and Creative Commons researchers, students and others” who a share the details of their hardware and software. “This sharing of knowledge accelerates the development of innovative technology applications for aerial robots.”

The Dev Team has now pushed a maintenance update to both ArduCopter (2.5.5) and ArduPlane (2.34) that all APM 2 users should upgrade to (it also includes some nice improvements for APM 1).  It fixes both the APM 2 reset issue (you sometimes need to press the reset button to start the board under battery power) and an issue with some APM2s that have a slightly different version of the MPU-6000 sensor with a different accelerometer scaling factor (this is now auto-detected by the code).

Both of these are now in the Mission Planner so everyone can easily upgrade.

Tridge describes some of the changes to ArduPlane in this post:

This release includes one very important update for APM2 users, and a few other minor updates.

The main reason for the release is to fix a bug in the scaling of the MPU6000 accelerometers. We discovered that the MPU6000 on the most recently shipped APM2 boards had different accelerometer scaling than earlier boards. This resulted in bad attitude calculations which would get worse during flight (as the DCM code interpreted the conflicting information between the gyroscope and accelerometers as gyro drift). We now query the product ID of the MPU6000 on startup, and fix the scaling according to whether it is a RevC or RevD version of the chip.

If you use an APM2 with ArduPlane then it is strongly recommended that you update to the 2.34 release.

Other less critical changes in this release include:

• fixes for building ArduPlane with the MAVLink 1.0 protocol (we currently use the 0.9 protocol). In a future release this will be the default once all other components are ready
• expose a new parameter AHRS_YAW_P to control how fast the compass controls the heading. The default is 0.2, which should be good for most users (this was mostly added for ArduCopter users)
• fixed the reporting of the raw servo output value in the MAVLink logs. Previously if you uses a mission element to set a servo value (for example, for a bottle drop) the log would not reflect the servo change. The logged value is now obtained directly from the servo library so will always be accurate
• changed the default I terms for navigation roll and pitch to 0.1. It is very common to need a small I value for navigation, so a 0.1 default is better than 0
• make it possible to use UART2 for Telemetry. The APM2 has a otherwise unused UART2 port, which you can connect to the telemetry connector via a solder bridge. This adds a TELEMETRY_UART2 build option to configure the code to use this port. This is mostly useful if you have an onboard computer connecting to the APM2 via USB at the same time as you connect a radio to the telemetry port, and you want both telemetry streams active

For ArduCopter, here's the short form of the some of the changes, thanks to Randy and Marco:

1. MPU6000 accelerometer scaling fix (affected APM2s shipped from early May)
2. "Retro Loiter" by Adam Rivera (uses ground speed directly from GPS instead of calculating from lon/lat position). Improves Loiter performance
3. "AutoApproach" function by Marco Robustini, developed by Adam Rivera
4. APM2 support for Optical Flow
5. bug fix for needing to push reset before motors will arm
6. compass reversal problem (actually same root cause as #5)
7. Fix for Tri tail servo reverse issue as reported during testing.

  All frame types were updated in the planner including the TradHeli and Y6.  We figured for the Y6, even though the TB_Ratio (top/bottom motor speed ratio) has temporarily gone missing (but will be back in 2.6), it's more important to get this scaling issue fix out there.

Now the ArduCopter dev team will return to their focus on 2.6, which is all about performance (fine-tuning Loiter and Navigation accuracy)

Spent some time in the Alps with a friend. Lots of hiking and lots of flying.

Nice design by hardik allows you to use regular aluminum or carbon fiber tubes. Just 3D print the motor mounts and center plate clamps. All files on Thingiverse here. 

So my buddy Shad and I headed out to my flying spot to fly the Skywalker.

This time around I used my new roof-top antenna mount, with VTR and Planner PC mounted inside the SUV in the back seat.  I found a mount designed for an iPad which worked to hold the ASUS tablet behind the passenger seat headrest.  Worked perfectly.  I set the VTR on the console between the driver seat and passenger seat with the screen tilted so that I could see the video output.  While I have two video cameras sending video to the transmitter, I haven't yet recieved my video switch, not have I cracked exactly how to activate the switch, so I just hard wired the side looking camera in to see how mounting angle and field of view were.  Besides, the idea is to record the forward view in HD with the Contour camera, right?

Before we left for the field I also finished up my pre-flight checklist.  I have a terrible memory, and have forgotten to complete important steps before flight before (set home) so I wanted to establish a more repeatable procedure.

Once at the site we got all setup, mounted the antennas and pre-flighted.  Of course, my memory being what it is, I forgot to use the checklist.  Well, we used the checklist, but actually just to stabilize the wing of the plane as we calibrated the gyro...  I'm a knucklehead.

During the pre-flight, all was good except that when in FBW-A and STAB modes the lelevator seemed to have very very little control authority.  The servo pitch gain (P) was set to 300. Thats higher than the what others seem to be using, but I doubled it to 600... it was an improvement though still provided less deflection that the other surfaces seemed to have.  I need to look at the control horns and servo arm to see if perhaps I have set it up improperly.

After a brief mis-start Shad launched the plane and started recording with his iPhone.  I remembered this time to start the VTR to capture video from the flight... but although I turned the ContourHD camera on, I entirely forgot to set it to "record".  Crap.

So this time I was able get the plane into the air and gain altitude. I flew for 2-3 minutes, initially on manual then in FBW-A and STAB.  All worked very well, though the wind picked up and I was seeing some effects on the plane.  Once I was confident, I threw the switch to auto and the APM took over.  I was very happy, it flw in a very stable manner.  I had defined a very basic square shaped course.  I'm not sure that I'd say it followed the course, I'm still looking at the log data, having trouble developing an overlay so that I can see it output on google earth.  The telemetry data is showing me history that doesn't strongly suggest the waypoints were followed.  I seem to have lost telemetry at a certain point prior to "landing" as the kml terminates way prior to the "landing".  I'll post those files.

When the plane was at it's furthest point, I got worried that it was wandering off out of control, so I started nudging it home. Things were ok for a bit, then I noticed I was having less influence, it wasn't responding well to the TX.    Then shortly thereafter it started heading in, in a spin.  I gave it full up-elev, but it dropped below bush-tree level and that was it. 

Shad and I identified an azimuth to the plane and hopped into the SUV and drove over the the site - or tried to.   The terrain was too dense with bushes, we tried for 45 minutes or so to get to the site without scratching the hell out of the SUV, but couldn't find it , even after dismounting and seraching on foot.  The telemetry had halted and I didn't trust the indicated last position.  I haven't been able to build a kmz using the logs pulled from the APM, just from the tlogs.  I'm actively working this - any help????

We ended up heading back to the launch site, regained the azimuth to the "landing" site and started walking.  Found the plane just a few minutes later, we had been searching in the right direction, but too far from launch.

The plane was in surprisingly good shape when we found it. I would never have believed it.  I was able to identify the impact point (below). It hit the ground somewhat hard, but was upright, wings level and could not have had more that a 15 degree nose down attitude.

The wooden camera pod was damaged, more from the CountourHD (not recording) being popped from it's mounts and the safety wire shearing through the wooden from.  The telemetry unit looks to be toast.  The high mass of the 900mHz antenna wrenched the RP-SMA connector off the circuit board.  I think it is repairable, but not by me.  I'm seriously considering dropping the whip antenna and picking up a 900mHz cloverleaf antenna from ReadyMadeRC.com.  I've very happy with the 1.3GHz cloverleafe I use for video.I'll give it a shot at resoldering, but I'll have to do the work under a microscope and I think I'll have one shot at it.  That was a shame, of all the parts of this plane, the XBee's have been the most difficult to get.  I finally gave up on 3DR and bought directly from Digikey.  Maybe this is a good excuse to go with the new 3DR radios...

The vertical stab is torn a bit, but thats an easy fix.

Overall, after only 6 minutes of flight I'm still very happy to have another success.  Every time I have flown, even for the shortest flights, I have learned something.  I'm a big believer of lessons learned. 

I still haven't been able to download the video from the VTR, I have no Firewire capability, gotta get an adapter.  When Shad sends me the iPhone vid I'll edit and post.

Here's the YouTube video...

http://youtu.be/X1J39n79lts

Ed

I bought a PhoneDrone board a couple of months ago, hoping to use the board in order to build some sort of autopilot or  plane stabilization in conjunction with any standard Android phone that supports Android 2.3.5+. 

My idea is to use the sensors in the phone to stabilize a plane. Initially I thought about stabilizing even a multirotor, but I soon figured out, that would be way to complicated. So I´m starting with a plane. In my case I´m using the EPP-FPV from hobbyking since it has plenty of space to hold all the electronics and flies very docile.

After getting in contact with the nice folks at the 3drobotics support I was able to get some code samples and build a basic prototype connecting all the pieces. A Samsung Galaxy Nexus, the PhoneDrone board, a Turnigy9x receiver and some servos which you can see in the embedded video at the top.


 
The next step is involving the onboard gyro and accelerometer to stabilize one axis of the plane. The code is allready in the repository and I tested it very briefly but I wanted to see first how an APM2.0 stabilizes my plane. Also I´m thinking very hard about backup solutions in case my PhoneDrone-Android setups fails in the air. I´ve studied the failsafe of the APM1 and APM2 and decided to get a 
"Wireless Buddy Box System" with 
4 or 
8 channels from Hobbyking. Dedicated hardware failsafe seems like a good idea to me.

Next steps are actually getting experience with the APM2.0 to get a real feeling what to expect from a plane autopilot since I´ve only used this kind of hardware on multirotors so far. Then I will see how much of the functionality I can cover with the "IMU" that is in my phone. It´s really cool if you think about it, my Galxy Nexus Phone has all the sensors of the APM2.0 (gyro, ass, compass, gps, baro) plus a "modem" and a very handy input device called a touch screen to configure the software :) Plus it has tons of memory, dual core ARM processors and it´s own backup battery.

I´ll keep you guys up to date with my progress here on diydrones. You can also look directly at my github for changes in the code, my youtube channel or twitter.

I´ve also created a google group to exchange ideas and experiences with other people who bought a PhoneDrone board.

Stepped the wireless down to 11megabit & the range definitely increased.  It uses a lot more power because the transmitter is on longer, but the penetration is much better. 

Found another 64k of RAM on the STM32F4.  It's the fabled core coupled memory, bringing the chip up to 192k.  That increased the framerates.

640x480 color: 5fps  1.4 megabits
640x480 greyscale: 7fps   1.8 megabits
320x240 color: 23fps 2.5 megabits
320x240 greyscale: 30fps 2.5 megabits

The trick with the core coupled memory is it can't be accessed by any peripherals.  The network now needs a memcpy.  The mane benefit is there's enough RAM to have the largest buffers, all the time.  The camera can be in 320x240 greyscale for navigation, than briefly switch to 640x480 color for a photo, without having to shuffle buffers around.

There are also 320x480 & 160x240 modes.  The theory with this is a rolling shutter camera can be used in pushbroom mode, capturing a wider field of view by compressing the vertical lines.  The resolution becomes equivalent to 2 320x240 images stacked on top of each other.

320x480 greyscale: 14fps
320x480 color: 9fps

160x240 color: 30fps

160x200 is Commodore 64 resolution. 

The camera was damaged from pointing at the sun.  It didn't generate hot pixels, but made areas more blue.  Between hot air melting & sun damage, it's real fragile. 

Spending 2 days optimizing different video modes was a waste, but it might have come in handy for any job interviews.  Times have changed.  Job interviews today are straight programming tests from Google's interviewing style.  They're not interested in applications, but very specific knowledge about a programming language.  Google is presumed to be the handbook for everything.

The tasks of PWM, battery sensing, & magnetometer reading, which are the bread & butter of aviation, sure look mundane once you get video going.  The STM32F4 makes life a lot easier with pullups on all the GPIO pins & 2 32 bit timers, allowing 8 channels of 200 Hz PWM with no funky interrupt handling.

The magnetometer used in Marcy 1 & Marcy 2 was a freebie AK8975, which came at a cost.  It's sold in 32 piece minimum quantities & costs $6.  You're looking at $200 just to get started.  Almost anything is cheaper.   The HMC5883 is $4 & has an I2C interface.  It's most certain that every production run of Marcy 2's would have completely different parts.


There's actually a chance video could do the job of the magnetometer.  To be sure, Chinese toys have used video of sorts to stay in a certain horizontal position forever.

Airframe assembly begins.

It's been ages since I ever removed the photoresist or actively tinned anything.  Tinning would definitely make it heavier.

That is a heavy board.  The bottom of the camera faces the leading edge, so the scanlines cover a longer distance than a single frame.

This arrangement immediately caused the RF emissions to crash I2C.

Various attempts to defeat it failed.  Lower pullup resistors on I2c, routing the I2C away from the wifi, moving the wifi away from the motherboard didn't work.  It's just going to be limited to 40 samples/sec by the RF.  The same thing happened on Vika 1 with the XBee. 

Marcy 1 needed 112 samples/sec & got that with a long I2C cable, but a very low power radio.  Cell phones must have a lot of shielding between their I2C sensors & the RF.  The AR drone has the Wifi on the opposite side as the analog sensors.

Seem to recall having a dream about fixing I2C on this board.

After putting the copter together over a few exciting evenings, initial test flights showed some very strange control responses with pitch and roll being swapped. I could "correct" this by swapping my Aileron and Elevator receiver channels, but that made the autopilot's stabilization input completely unpredictable. I checked my wiring and documentation, and found the following:

The PDB that comes with the 3DR-B is oriented to use rotor 2 and 3 as the quad's front in x-mode. See page 7 of this doc:

http://stuff.storediydrones.com/ArduCopter3DRAssemblyInstructions

The APM2, however, thinks that rotors 1 and 3 are in the front:

http://code.google.com/p/arducopter/wiki/APM2RC

So, wiring the PDB correctly and hooking it up to the APM2 results in a copter that has its motors turned 90 degrees from its board. The solution is simple enough.

Maybe this is a well-known issue... It was news to me. Or maybe I've missed something obvious in the the build process. If your newly-built quad is behaving oddly, look into it.

...will tak place 22th to 27th May 2012 in Pałac Kultury i Nauki, Warsaw.

The exhibition will be physically located in Museum of Technology  inside this monumental building.
The Museum is recently known for organising countrywide meetings that have spin-off potential and highly technological subject.

22.05.2012   12.00  - official opening in Museum of Technology

24.05.2012   16.00 - UAV laws and flight safety seminar for registered participants

25.05.2012   A contest for the best thesis with UAV in its research scope

26-27.05.2012 Multicopter demonstration for large public inside the museum

Note: polish official acronym for UAV is BSL (Unmanned System, Flying)

Pictured: could be like Mr Hajduk's plane with analog camera circa 1997? Low accuracy guess.

Almost all polish UAV makers will have their (small) booth. Several full-scale (maybe unequipped internally) UAVs will be on display.

Therefore if you are passing near Warsaw Central Station, let the traffic jam fade and step into the tallest building in sight.

Here is the first flight of my first hexa :D used software AC2.5.4 wich gave an excellent flight (I had 2 yaw twiches) Loiter still needing some work in software or PID. I think throttle rate is a bit higher causing those ups and downs. Alt hold seemed to work better with version 2.2. RTL worked pretty well and that option to disengage auto landing it's great. Thanks Marco and dev team. The hexa and the quad behave a little different. The hexa is almost as driving a 4x4 much more stable but still agile, it needs less angle to correct position. I'm not used to it yet. I know now that all my stability problems with my quad using 2.5.4 were due to too large props in a small frame. The hexa is much more forgiving about this. X650 pro Xaircraft frame, sunnysky x2212 980kv motors and 10x4.7sf apc props, 6000mah 3s 25/50c nanotech battery about 2kgs for all, having about 15m flight time with this config.