Blogs

Developer

Arducopter 2.0.50 preview

Posted by Jason Short on October 31, 2011 at 8:19pm

2.0.50 is a work in progress, but this video highlights the Altitude hold progress in the latest code. 

  

 

 

Changes include a faster Baro filter to reduce latency and temperature induced noise. Alt hold control using the throttle has been upgraded to have a faster and proportional response. 

 

Acro mode has been enhanced and now has it's own duplicate set of Rate PI's for more flexibility.

I'll have this posted in the next two days to GIT and the mission planner.

Jason

 

 

 

Tags: arducopter
E-mail me when people leave their comments –
Follow

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • Developer
    Jason Short November 1, 2011 at 10:29pm

    Thanks for that. The log files indicate something went wrong in the DCM. I'm looking at it more closely and will get back to you.

    Jason

     

     

  • Jeff E November 1, 2011 at 10:08pm

     

    Jason, not sure if this is a bug or what:

    - Just installed v50 ( I had a successful flight in v48 just a few hours ago and been in that version for a while with good results except waypoints)

    - Noticed on mission planner there's a lot a modes but I selected the normal once for testing

    RTL

    LOITER

    STAB+Simple
    STAB

    ALT_Hold+Simple
    ALT_Hold

    - first 2 min in flight I cant seem to get into alt_hold and my ardustation still indicates stable mode

    - brought the copter down and tried to check one by one the modes it seems only loiter/stab_simple/stab/alt_hold+simple is recognized

    - I thought it would be just a change in values like when simple was removed from modes so I wanted to try alt_hold+simple or loiter

    - less than 2mins into the flight (total of 3m50secs since i didnt power down the quad since first flight) the quad flips

    I know I havent flipped the mode switch yet as I am trying to hover but I am not 100%sure

    I know my quad is perfectly fine as I have had 3hrs flight time in v48 alone this has been flying since v38

    STAB/RATE P was changed the rest is default

     

    On the bright side nothing was damage,Also the camera stab seems to be working fine, i set the DZ and G for both pitch/roll. I tried to check if esc motors are working fine they seem to be but noticed motor 3 is spinning more

     

    here is the clip

     

    here is the log file

    by the way all pre-installation/upgrade has been done. erase eeprom, radio, esc calibration and proper leveling. CLI test shows everything worked fine. Also most part of the flight it was flying well.

  • Developer
    Jason Short November 1, 2011 at 2:24pm

    I'm not the right guy to ask...

  • Developer
    Jason Short November 1, 2011 at 2:22pm

    Aurelio R. Ramos has a working Z accel implementation, but he's reworking it now. It's not trivial and involves inertial modeling and a dead reckoning system. Getting it to run at 50hz and reducing the memory footprint is what he's doing now.

    Jason

  • Vincent Mees November 1, 2011 at 2:12pm

    Or perhaps a complete new APM ????

  • Kirill November 1, 2011 at 2:08pm

    As I understand, under refactoring you mean complete transition from 1280 to 2560?

    Yes, it would be good to have final version running on 1280.

  • Developer
    Jason Short November 1, 2011 at 2:03pm

    Z accel is not implemented yet and may need to wait till after release. It's a memory and processor hog right now. But it will come relatively soon if the refactoring goes well. 

    I'm trying to make a complete feature complete version run well on the 1280 before making clean break and requiring the 2560.

  • Kirill November 1, 2011 at 1:52pm

    Great! Maybe I even don't have to buy a sonar sensor.

    By the way, Jason, could you tell, please, is Z-accel readings used simultaneously with baro sensor readings? Or it's just well-filtered readings from baro? 

  • 100KM
    u4eake November 1, 2011 at 1:30pm

    Also looked at the new alt_hold altitude changing code and it looks promising.  If I understand correctly, altitude change should be proportional to stick movement below 180 and above 650 (throttle ranging from 0-800).  And between 180 and 650 nothing should happen, which is a large part of the throttle range.  Personally I think that's a bit too large of a 'dead zone'.  I always feel a bit akward when moving my throttle stick down and nothing happens, nothing happens, nothing happens, (damn, I'm nearly at zero throttle) oh and then it starts descending. :-)

    Would it be a good idea to reduce that dead zone in the center ?  Maybe like 280-550 ?  Would also give a finer control over the altitude change, no ?

  • 100KM
    u4eake November 1, 2011 at 1:10pm

    Jason, just had a look at the new code and noticed that there's still a bug inthere with the USERHOOK_MEDIUMLOOP in arducopter.pde.  (it's right below the extra barometer.read(), that's why I noticed)

    The medium loop hook is now executed at 50hz instead of 10hz because it is outside the switch statement.  It should be in 1 of the 5 cases to make it run at 10hz.  

    I already told this to agmathews but I guess it got lost somewhere.  Would be nice if it could be corrected in 2.0.50.  Otherwise the userhook code seems to work nicely for my custom ledshow.

This reply was deleted.