Anyone have knowledge or experience with ArduCopter systems?

[granelli]

I'm wondering how difficult the arducopter system is to get working on a single rotor helicopter compared to systems like helicommand gps/ DJI w/GPS/ or other higher end stabilization systems?

Thanks

[Wesley888]

Arducopter require quite a bit of tuning. It's a hobby product. You really have to enjoy fussing around stuff to get it runs like the commercial product. Lot of testing and tuning and testing again.

With DJI Naza-H, I went through the setup wizard for under 30 mins. With the default setting, it was already up and running, and hands off hovering.

[R_Lefebvre]

Yes, the Arducopter system is quite complicated to get up and running, but once you have it running, the performance is only comparable to a $13,000 Ace One multi-waypoint setup. Even then, there's features which we have that not even the Ace One has.

Part of the reason for this is because it's open source, it basically has become a "wish list" for people. For example, I just created a mode where the copter will always yaw to look forward in the direction of GPS travel automatically. This will be good for FPV flying so you can better judge which direction you're going, or for doing high-speed chase video filming.

I wouldn't even call it a "hobby product" it's actually becoming more of an academic or full blown professional UAV product. We haven't attempted to shield the user from any of the inner workings, or dumb it down. So, there's more stuff to look at when setting it up, this makes simple setups harder. But on the other hand, it also allows you to make it work with a system that otherwise wouldn't work. For example, the DJI Naza-M is easy to set up, if you have a standard system. But some people have been completely unable to get it to fly their multirotor because they have an usual setup.

[R_Lefebvre]

A couple people have asked me for more info in PM's, and I just want to put the info here so everybody can see rather than writing the same PM reply multiple times.

I should also preface this all by saying that yes, I am a developer, but this is open source project I'm just working on for fun. I don't make any money or anything off of it. I do no promote it. My writing may not be a great sales pitch, and there are two reasons for that, first, I'm not trying to sell it. But second and more important, I don't want people jumping in with false expectations and being disappointed or suffering a crash and coming back to blame me. This is not a commercial product. It's not polished and user friendly, and it's really not suitable for 3D. But, it's lots of fun, and offers the only entry into full UAV functionality for regular people. If you don't like to tinker, it's probably not for you.

Also, I'm a mechanical engineer, and I take this system VERY seriously. I don't want to see anybody get hurt. That's why you also won't hear me saying it's safe, easy and fun for everyone! I try to be precise, and accurate, and not sugar coat anything.

Now, what is the current status of Arducopter:

In the past, Arducopter has been guilty of "putting the cart before the horse" so to speak. We had a bunch of higher level functionality, which nobody could use because the darn things just didn't fly well to start with (and this goes for multi-rotors as well as helis). This changed in a big way around June this year with the release of FW 2.6. Then in August and October we had some really good releases with 2.7 and 2.8 which made the Multi-rotors fly really really well.

Helicopters were still held back a bit because of a few persistent problems. One of the biggest problems is we just don't have as many users, or developers. I'm now the only developer working to make the program work on helicopters. It's not so bad because 90% of the code is agnostic to how many rotors you have. I just have to adapt some things. But more importantly, there was a control issue which meant that we could only get them to fly well in Stabilize mode. There was no rate based acro mode. But more importantly, there was a problem where vibration seriously affected the Flight Controller (aka: IMU). Basically, if you had any vibration, the IMU got confused and would make the heli uncontrollable. I suffered a number of crashes because of this, which is the #1 reason I didn't actively promote the system. This was somewhat of a phantom problem which I did not understand completely either the mechanical problem, or what to do about it in the program.

But a few things have changed recently. First, I figured out the cause. Bearings bearing bearings. Simply put, the system is very sensitive to bearing problems in the main and tailshaft. Maybe this is true of all FBL controllers, but I couldn't judge if we're worse as I just haven't experienced other systems. What I've found is that you can have a bad bearing which is messing up the IMU, but otherwise you wouldn't know anything was wrong, so it was hard to diagnose. It's not that it's so sensitive that it's impossible to fix, you just really have to CHECK your bearings and be picky. If they feel notchy, replace them. I've had brand new Align bearings that were bad right out of the package. Hobby King bearings are even worse. I now only use high quality Boca bearings or similar.

This situation is not helped by the fact that we simply have nothing in the program to help diagnose or even detect the issue. No vibration measurement and graphing.

However, with the upcoming release of FW 2.9, this issue is greatly reduced. We are employing digital filtering in the IMU which really helps. I've done back to back testing with bad bearings, turning the filter on and off, and the problem is 90% gone with the filtering turning on. You still have to pay attention to your mechanics, but it's not a killer problem anymore.

The other big thing coming is that I've solved the rate control problem, and we now will have a working rate mode for helis. I'm really happy about this as we've worked on this for a long time. This will make FBL helis more stable, more responsive, and give us a working Acro mode, though I caution that it's probably still not suitable for 3D.

Where do you go to learn more:

The project home is:

http://www.diydrones.com/

There's a forum there, but the software sucks. There's this subforum:

http://www.diydrones.com/forum/categ...istForCategory

And this one:

http://www.diydrones.com/forum/categ...istForCategory

I'd be more than happy to lead a discussion here if you want. Ultimately, I'm really interested in getting some more helicopter users to try the system. But I would suggest that you try it out first on a "squadron hack" rather than your nice big shiny favorite heli. There's a lot to learn, and honestly I'd like to get some more miles on the clock on this thing before people risk their really expensive helis. My main testing machine is a HK450Pro FBL, and I've also used an HK600GT. I've retired the 600 and am now building up a Frankenstein 550-stretch heli.

What about hardware?

The hardware is the best part.

First, it's really cheap, which is what makes this fun to play with on a cheap heli. It's not that the hardware is "cheap", but basically you're not paying for the expense of the software development since that is all done by volunteers. Also the processor we use is really simple and inexpensive. Some other people criticize us based on that (it's a simple 8-bit Atmel), but it's actually a badge of honor IMO that we have it working as well as it does. It's taken some pretty amazing software design to get this far. The upshot, IMO, is the old Atmel processor is reliable as a hammer and as tough as an anvil. And the software code is *tight*.

Anyway, details are:

http://store.diydrones.com/APM_2_5_A...r-apmpwrkt.htm

Only $145 if you don't include the power module or GPS. I have never used the power module myself. If you are going to get a GPS, I recommend the Ublox for $70, at this point it works much better.

Oh, and you don't have to buy there. There are several vendors in different places, but this is the OEM's store.

What do you get for that price? The basic unit includes the FC, the IMU, Compass and Baro all-in-one. It also includes a dataflash chip which we use for data logging. This is actually a BIG deal. I don't know why nobody else offers it. It greatly helps tuning as well as fault finding.

We've had a few "Flip of Death" type problems, but generally only one person has to suffer it, or a few, and they get solved pretty quick. Unlike DJI where, they had no idea of figuring out what was going on and tons of people suffered. We've got some REALLY smart guys on the team and I've seen forensic analysis that would make the FAA proud.

Oh yeah, the compass? We actually take account of magnetic declination, so you don't have to worry about "clocking" the GPS unit depending on your location. What a silly thing to have people do when the solution is so simple. You can enter your declination manually, or just let the system figure it out automatically for you based on your GPS location!

I also really strongly recommend people buy a telemetry kit:

http://store.diydrones.com/3DR_Radio...try-3dr915.htm

This is needed for the full UAV experience, but it also makes tuning far, far easier with no need to plug in except to update the firmware.

More later.

[R_Lefebvre]

Here's a great example of where Arducopter is at. We have most of the basics down, and are going after fairly advanced stuff. We can make good use of data logs to find error-states, and try and prevent them. So here's a great example of what I mean by error-state.

This is the case of a quadcopter, which was doing an intentional RTH, but hit a tree near the site (not really the fault of the system). It hit the tree, lost control and landed upside-down nearby. On impact, the Rx was ripped from the machine, so the Arducopter state went from intentional RTL to failsafe RTL. There's a subtle difference there. Since it entered failsafe RTL within 15m of "home" (we check for that) it went into automatic landing mode instead of trying to fly exactly home.

When the user ran over to it, it was upside-down, at full throttle. The first problem was obviously the CFIT. But we consider the post-crash full-throttle a failure too. The data logs are a great help tracking down these issues, and here's an example of that. This graphic is annotated by a lead developer as we discuss it. I'm just showing it as an example of how seriously we take this stuff, and how much datalogging helps eliminate failure points. I do not know how anybody builds flight controllers without it. In this case, it shows how the inertial navigation system got confused about the altitude because of the impact, and then being upside-down. We will try to build a "crash detector", because ideally we want the motors to shut down, for safety and to protect the machine as much as possible.




On Saturday I was doing some test-flying of my 450, and the pitch slider broke in-flight. It started spinning, but I was able to emergency land it successfully, only broke the landing gear. The Arducopter stabilization works really well.

[R_Lefebvre]

Last night during testing, I pushed my little 450 heli up to 107 km/h. Straight line, no tailwind. In the dark. Thought that was pretty cool!

[R_Lefebvre]

Did a full waypoint mission today, from take-off to almost landing, with no diving or altitude problem. Making progress!

[R_Lefebvre]

So, we now have altitude hold working very very well. It employs the Z-access accelerometer instead of simply using the barometer, so it is very precise. In my experience, it can hold height within about +/- 1", even in a 30 km/h wind with a 450.

The next step is getting the GPS position hold working better. Currently it holds in about a 1m box which is pretty good. But we are building an inertial navigation system to make it even better. Leonard is one the lead guys on this and just put together a little demo to show how it's working.

Keep in mind, this is not simply GPS position hold like GPS Atti. This is a full GPS guided flight. So it's more like GPS Cruise in the Ace One. Your stick inputs give a velocity request, not an attitude request. Most of the flying you see there is in this mode, that includes the high speed banked turns and stops.

He is talking about compass error, but don't be mislead. Our compass calibration is quite good already, but the faster you fly in this mode the more of an effect a small error has. So that's what you're seeing.

We're not quite done yet, but IMO, this represents the best available GPS guided flight available in the sub-$50,000 market.

[ame]http://youtu.be/nYMcT9wZgtU[/ame]

So the new Alt Hold controller code should be pushed out by the end of this week, and hopefully this GPS controller should be just another few weeks after that.

I think then we will work to make this new guidance controller improve the Waypoint performance even more. At that point, I think development for the Atmega platform will be pretty well complete and we'll be focusing on pushing the new PX4 STM32 platform even further.

[jolyboy]

I'm so glad you guys have got this sorted. The first step should have been rate flight, instead of starting with all the add-ons first
Congrats on all you progress Rob, its really impressive

[R_Lefebvre]

Well, technically this is an add-on, and we still don't have a mode capable of 3D acrobatics yet.

It MUST be understood that Arducopter was developed as a UAV controller first and foremost. It was never really intended to be an acrobatic FBL controller. However, some of the devs, myself included, do like to actually FLY so we are pushing back in the direction of high fidelity flight.

You also have to understand the history of the program. Ardupilot was developed first, which is an airplane autopilot. When the Arducopter program was started, they merged the autopilot features of Ardupilot with an unfinished open source multi-rotor flight controller. That's why it appeared to have all these advanced capabilities while it still didn't fly quite right.

Leonard has only been working with us a few months, but really helped with most of the basic flight performance because he's extremely smart, and he can also really fly and didn't like the existing performance.

But that reminds me, I'm sure we will get full 3D flight capability working before we sign off on Atmega development.

On the weekend, I shot some video of the quasi-acrobatic controller. Keep in mind when you watch it that I cannot fly 3D. I have only flown classic acrobatics in an aeroplane. This is my first real world flip in a heli. Also keep in mind this is a VERY heavy Hobby King 450 heli.

[ame]http://youtu.be/VrLyPCnInVE[/ame]

[zeeflyboy]

This is very interesting stuff, and I'll be following it with interest and trying to learn more.

I'm currently building a rather expensive and work intensive scale FPV project, for which I am currently using the Naza-H. Perhaps I will at some point build a test rig and use this, if I can get it flying satisfactorily and without killing my heli I'd be very interested in the features you have going here for this current build.

[R_Lefebvre]

Yeah, in the past, I have dissuaded people with expensive helis from using it. I've been bashing Hobby King helis for a year, and didn't want to see somebody wreck a nice heli. There were some reliability problems, and the performance wasn't good. In particular it was very intolerant of vibration.

But that is behind us now. The final thing was the upcoming 2.9 release brings in usage of some better digital filtering, so vibration performance is much better.

I would still estimate that our vibration performance is not as good as DJI's. They do have a really nice internal IMU damping system on all their units, and we do not. We have to manage it with digital filtering. I believe this is what most of the other FBL controllers are doing as well. I'm not sure, but I haven't seen any tear-downs to show the internals, and they are rather small so it doesn't leave a lot of room.

But at this point, it appears that if your helis is well setup, and most importantly the main shaft and tail shaft bearings are good, then it's working great on electric helis.

However, piston powered helis... I dunno. I've seen a DJI Ace One flying a gasser with the IMU mounted on the same plate the motor is. That is very impressive.

But other than that, I would now say that Arducopter is more reliable than some of the other stabilization systems on the market. For sure, some of the features are much better thought out. And the failsafe modes just blow away everything else.

[George_Bevan]

These are some amazing videos! I work on applications of photogrammetry for geomorphology and cultural heritage at Queen's University. We're posed to begin work with single rotor helicopters to collect aerial data. We're starting small but hope to be up to a TREX 800 with a gimbal in a few months. After that, if the funding is in place, we may move to an ever larger gas-powered platform like the Copterworks AF25b.

The largest cost I see in this venture is the flight control system. The Arducopter would represent significant savings over the $11k DJI Ace. Once we're up and running we'd be happy to be guinea pigs for your development!

[salience]

Originally Posted by R_Lefebvre

A couple people have asked me for more info in PM's, and I just want to put the info here so everybody can see rather than writing the same PM reply multiple times.

Also, I'm a mechanical engineer, and I take this system VERY seriously. I don't want to see anybody get hurt. That's why you also won't hear me saying it's safe, easy and fun for everyone! I try to be precise, and accurate, and not sugar coat anything.

<snip> It's not so bad because 90% of the code is agnostic <Snip>
More later.

Agnostic? I'm a believer!";>) Certainly not indifferent...
Thanks Rob for the very interesting rundown. I'm definitely decided, and am prepared to install this in a 600. It will take quite some time however, but I'll let you know my progress. By the time I'm ready for testing I'm sure you will have made even further progress, considering how well it is going to date.

As for vibration, I've found a lot more problems with torque tubes and their 6 noisy and fragile gears, than with bearings. I was astonished at how smooth and silent-running my 450 was after the conversion - a photo on the other thread. Just about ready for first testing of a Trex500 with tail motor. This one has HC3-SX already, so the APM will have to wait for the 600, which I also intend to equip with a tail motor.

[R_Lefebvre]

Originally Posted by George_Bevan

These are some amazing videos! I work on applications of photogrammetry for geomorphology and cultural heritage at Queen's University. We're posed to begin work with single rotor helicopters to collect aerial data. We're starting small but hope to be up to a TREX 800 with a gimbal in a few months. After that, if the funding is in place, we may move to an ever larger gas-powered platform like the Copterworks AF25b.

The largest cost I see in this venture is the flight control system. The Arducopter would represent significant savings over the $11k DJI Ace. Once we're up and running we'd be happy to be guinea pigs for your development!

Hi George, we should talk, because I'm quite interested in work such as you're doing, I'm also failry local to you.

I should also like to update this thread with the news that I recently completed an entry in the T3 Cube competition with my quadcopter. It involved flying a cube pattern in automatic mode, loitering at each vertex for as long as possible. The intent is to simulate an automated building inspection, but you can imagine other uses.

It was done in full auto mode. I only had to take-off manually because a few times the landing feet got stuck in the snow and it flipped. So I took it up to 5 feet manually, popped it into Auto, and literally turned off the Tx. It flew the auto mode for 24 minutes, and did a fully auto landing within 3" of the launch point, with the Tx turned off. It loitered for 2 minutes at each vertex.



I did this with my quad, but there's no reason that it couldn't be done with a heli, as the relevant code bits are the same. The only part I wouldn't recommend yet is the full-auto takeoff and landing in a heli yet. I'm working on both of those.

[swsc4133]

Good Job Rob.
Im still waiting on parts.
After watching your videos again, Id like to know what head speed you are running?

[R_Lefebvre]

I'm not sure on the head speed of the 600, but I was targeting 1800. I just never measured it. On the 450, same kinda deal, I think around 2800, but I'm not sure.

[R_Lefebvre]

Yesterday, I did my first fully auto waypoint mission with Arducopter, including fully auto take off, and landing. You can't really see it in the video, so you'll just have to trust me but I had no control inputs for the entire flight. I only had my finger on the Throttle Hold switch just in case.



So now it is possible for a complete RTL on radio loss. Fly right back home at a defined altitude, and then autoland if you want. Alternatively, you could have it RTL at say 30m altitude, and then descend and hold at 2-3m until you regain control or the battery dies. This is potentially a safer method depending on your operating conditions. But full auto-landing is working.

[alcastan]

Rob, is it possible for the arducopter to control a FBL heli?

Regards,

[R_Lefebvre]

Absolutely, that's what the majority of users have. And both my helis are FBL now. No need for an FBL controller, it does it all. But again, at this point, it is NOT an acrobatic FBL system. Jolyboy and I are working on it. But you don't buy it with that in mind.