Comment by ThomasB on January 16, 2012 at 11:40pm

Sounds like a good roadmap. More structure in the code is really needed due to the grown complexity.

Comment by Gareth Rens on January 17, 2012 at 1:14am

Autonomous "follow me/look at me" control

Sounds AWESOME!

Comment by Fabien Bruning on January 17, 2012 at 2:08am

Sounds great, will the code also become more portable due to the elimination of global states? E.g. if someone wanted to switch the control algorithm. (though I suppose it's very possible now, haven't looked at the 2.0 code in a while)

Developer Comment by Randy on January 17, 2012 at 2:52am

@Fabien,

     Basically yes,  Making the code more modular should make it easier for people (with programming skills) to change the control algorithms (or other parts of the code) without having to worry as much about unexpected impacts on other bits of the code.

     It is actually possible to some extent to switch the control algorithms but it's not too straight forward.  For example if you look in Arducopter's config.h  you'll see lines like this:

#ifndef ALT_HOLD_RP 
# define ALT_HOLD_RP  ROLL_PITCH_STABLE
#endif 

..what this means is that the Altitude Hold flight mode uses Stablilise Roll/Pitch controller...and then inside of ArduCopter.pde you can see where it has a big switch statement to decide which roll-pitch controller to call...and then finally in Attitude.pde you can see the actual control functions that are actually called.  Inside these controllers you'll see it accesses global variables.

so you could write your own control algorithm and fit it in there, and also update some other functions like reset_nav() and reset_rate_I() and it would work...but my understanding is that in 3.x we would try and make it so that you'd mostly just have to write one class and it's be more obvious what needs doing.

Comment by Anish on January 17, 2012 at 6:26am

this is awesome even some architecture, :) we are seeing near professional quality in all the processes involved. Congrats to everyone on the team

Developer Comment by Adam Rivera on January 17, 2012 at 7:43am

This is great. I have definitely been hoping for a more organized (class/interface, indents) code base. Thanks for the update Chris.

Developer Comment by R_Lefebvre on January 17, 2012 at 10:58am

"ArduCopter: Autonomous "follow me/look at me" control with handheld GPS groundstation"

Now that's what I'm talking about!  One of my main reasons for getting into this is for shooting video of outdoor activities.  Having a feature like this would be amazing!

Comment by Jeb Bailey on January 17, 2012 at 11:49am

I would REALLY like to see a more robust auto-takeoff/land system for ArduPlane.  The current code is basically turn on/off the motor and hope for the best.  A successful ROG takeoff is a rare thing without RC interevention.

While flaring is important (and I'm excited to see it on the list), I think that definable heading on takeoff (controlled by rudder) and landing (instead of locking in whatever heading it's on) is VITAL to truly successful operation of an advanced ArduPlane.  It seems to me that auto-takeoff/land cannot be called "feature complete" without this functionality.

3D Robotics Comment by Chris Anderson on January 17, 2012 at 12:46pm

Jeb: Almost all small UAVs are hand or catapult launched--there are very few ROGs out there in this space (do you know of any?). We could certainly implement nosewheel steering, but it's a tricky thing to get right and generally not a priority for most users.  

Comment by Jeb Bailey on January 17, 2012 at 2:21pm

I don't know of any in the commercial sphere, but that's mainly because anyone who can afford something that needs a launcher can afford to buy one.  Most of the larger sUAS do actually land conventionally, and the commercial AP's I'm familiar with have the ability to define runways for use.  For instance, the Senior Telemaster is a great airframe, but needs ROG or a large and expensive catapult system.  Even an airframe as small as a .40 scale trainer is difficult to hand launch.

The real issue in my mind is the inability to preset a takeoff heading, and likewise a landing heading.  In both cases (currently), the heading held is automatically set to the current heading when a set of parameters are met.  While this my be a simpler way of doing things (I'm a novice coder at best), it seems like these modes have been put in as an after thought to an already very precise system.  Especially with the new APM2 having a built in compass, it seems silly not to utilize it for something that (at least to me) seems like it should be standard.

Comment

• ‹ Previous
• 1
• 2
• 3
• …
• 5
• Next ›
• Page