Comment by Tim - Arduino for Visual Studio on May 17, 2012 at 4:27am

Danny. Nice promo video, plug plug :) not really inside, not above your own car and not very stable :)

John: That is very nice position hold

Martin: Agreed, it's the best hold I have seen :)

Comment by John Moore on May 17, 2012 at 5:04am

@John

As expected from a $1200 flight controller.

Developer Comment by John Arne Birkeland on May 17, 2012 at 8:52am

Btw. just to clarify, not my video. Just one of many example of what you get if you throw money at the problem. :)

Comment by Tim - Arduino for Visual Studio on May 17, 2012 at 9:56am

JohnB: Question. Do you have any insight into why apm doesn't perform with the same stability? 

Developer Comment by John Arne Birkeland on May 17, 2012 at 11:53am

Fab: Difficult to say exactly why, but my personal opinion is to many features on to little hardware. This means that some corners has to be cut to get things done with the processing power available. Not being able to use all the available resources in the Invensense MPU-6000 chip, because of licensing issues also does no help. So at the moment we are doing "everything" with a single 16mhz 8-bit Atmel chip. In comparison the DJI wkm use 2x Atmel SAM3 32-bit chips running at 100mhz each and has less features then the APM.

Comment by Tim - Arduino for Visual Studio on May 18, 2012 at 5:31am

You both seem to make good points. I have always thought that one cpu should read gps, one handle telemetry and one for everything else. I know that the parrot uses one for navigation + one for motor and all other functions.

I have to say that $1200 isn't that expensive when we consider the different renditions of products like ap and apm simply because they are discontinued before achieving this stability. It all adds up!

In some cases, I also question the need for waypoints before stability especially considering that in my country (UK) we have to fly in line of sight which seems to negate the need for waypoints.

It might be helpful for new users to have access to a chart of the currently available systems and their relative strengths. The reason being that we have a diverse set of users who might be looking for different features. This is clear from what John B and others have said but it is not currently clear as to which equipment users should buy.

I guess the first step is gathering a list of what everyone is doing (or would like to do) with their kit. For example...

• Rock solid stable easy fly or camera platform
• Acrobatics
• Waypoints

Can someone come up with the full list? It would be very useful.

Thanks

Comment by Tim - Arduino for Visual Studio on May 18, 2012 at 6:02am

Jason

Yes, I am not sure how many people really use waypoints with a copter. They seem to make more sense for a plane.

I think the arduino can handle it but the huge amount of telemetry data causes too much processing. It would be better for a 2nd processor to simply be passed (two way) summary info from the main cpu via i2c or spi or ano mechanism. I also question the need for such fast rates of telemetry output. Once airborn, do we really care how responsive the attitude indicator is? The craft is always in line of sight so most of it is pointless?

Developer Comment by R_Lefebvre on May 18, 2012 at 6:36am

My opinion on this subject:

I disagree that the Arducopter firmware cannot be stable in a basic flight mode. (stabilize).  I've seen plenty of examples of really good flying machines.  And I've experienced it myself.

However, that's not to say that people's *perceptions* that it doesn't fly well is incorrect.  I think the problem is that due to the lack of processing power, as well as the lack of professional aerodynamics and/or controls training of the developers (myself included) all that we have done is create a simple PID control system.  PID control systems are typically used where you are not able to, or do not care to,  develop a proper physical model of the process being controlled.  PID's are sort of dumb.  They can work, but they take a lot of tuning, and the vast majority of users do not know how to tune PID's, so they struggle.

The net result is so many users not developing a good tune, and not being satisfied with the system.

Other systems which have professional development teams, and more processing power, might not be using PID's at all.  They could be running a much more sophisticated model, and/or they might be running PID's with really good auto-tuning programs. 

I've seen this type of scenario myself.  I have a trackday car with a highly modified motor, and I'm running a Pectel racing engine mangement system.  It's a very simple system, just stacks and stacks of lookup tables and PID's.  It requires a LOT of tuning work, and it's VERY easy to blow up your motor if you don't know what you're doing.  Also, if you make any little change to any mechanical part, you have to start all over again.

Compare that to Ford's engine management system on which I was trained, and it's like night and day.  They have an accurate physical model of the engine process, and the users simply input some parameters like engine size, sensor types, and a few simple lookup tables for targets (so, desired output, not feedforward inputs like the Pectel).  And then it just *works*.

As to the idea that the waypoint functionality of Arducopter is taking away from the performance of stabilize, I disagree.  In the grand scheme of things, I don't think it takes much processing power at all.  Our main attitude system is running about 500hz.  I don't see a lot of improvement potential just by turning that up.  Now, running a completely different attitude system like Kalman Filter (I don't really even know what that is, but I hear it talked about a lot) might help, but we just don't have the power to run that, even if we weren't running Nav functions.

The thing that I can see which could validate the idea that the Nav functions are hurting stabilization performance, is just the simple fact of where we are focusing our efforts.  The Dev team spends their time doing other things.  I think there's a perception that the current stabilization program is "good enough".  And I don't disagree, though I think that full implementation of Adam's "Pretty Good Gains" auto-tuning would be awesome.

One place where Navigation definetely hurts stabilization, I think, is with the Compass.  The compass is used even in the stabilization program, to correct heading, and we have a problem with magnetic field noise from out motors.  This can upset the yaw control and make the craft do funny things.  The Naza (probably?) doesn't have a compass.  Turn the compass off in your Arducopter, and you will lose navigation ability, but will eliminate the possibility of magnetic field anomalies on your yaw control.

At the end of the day, I think the developers have done an AMAZING job of creating a very light-weight system that does pretty well on very inexpensive hardware.  It's not perfect, but it usually works, and the only serious downfall is the difficulty of user setup.

Comment by Tim - Arduino for Visual Studio on May 18, 2012 at 6:56am

@r_l yes that's the problem and the difference some of us are trying to avoid. Unless you dedicate your life to tuning, apm won't fly stable and if it's a tussle between easier/better control and waypoints ++ I vote for control :)

Developer Comment by R_Lefebvre on May 18, 2012 at 7:15am

@Jason, yes, then I think we agree.  The Nav part is not taking away from our stability in any way, from a firmware/hardware perspective.  As a breakdown, the bits of code are running at:

Attitude Determination: 500hz

Attitude Control: 50hz

Navigation: 10hz

I think I remember somebody doing a test, and finding out that the 10hz loop pieces were using some very small amount of processor power, less than 1%.

I didn't know Bill P was working on Copter stuff, that will be interesting!

@Fab:  The other side of the coin is that it seems like some of the users are not taking it upon themselves to learn what they need to learn to do the tuning.  This is "DIYDrones", not Plug and Play Drones, or Open Your Wallet Drones.  I think a reasonable attempt has been made in the wiki to explain the tuning process, and there is a link to the good Wikipedia page on PID control, etc.  yet I continually see questions that would seem to indicate people who have not even begun to take it upon themselves to figure this stuff out.

6 months ago, I'd not done any programming, except for some BASIC in high school 20 years ago.  Now I have actually contributed some code to the program which is written in C++.  Just some simple stuff, bells and whistles, basically.  But I've come a long way, and really enjoy learning.  I can't stand classroom learning.  I learn by doing, and this has given me that opportunity.

Comment

• ‹ Previous
• 1
• 2
• 3
• 4
• …
• 7
• Next ›
• Page