Updated ArduCopter and ArduPlane code: APM2 users please upgrade!

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)

Views: 3432

Comment by Andke on May 16, 2012 at 7:51am

Hi. Unable to attach dataflash log, because AFAIK it never booted and detected the SD card, it always says; "no dataflash detected" on boot (or equivalent message).

tests, compass - does deliver good heading, (in started direction)

Comment by Andke on May 16, 2012 at 8:24am

Extra info; I get "No dataflash inserted" on every boot

and "COMPASS INIT ERROR"  - yet the compass is calibrated. and declination set (maybe the error won't appear if I boot it in correct direction ?) Anyway compass test displays  heading and XYZ values that look "good" except north is not actual north


Distributor
Comment by Dany Thivierge on May 16, 2012 at 9:58am

Andke, check (redo) the shield soldering... make sure the pins have good contact and that the shield is really pushed down as much as possible... 

I got this Compass init error (yet calibrated...) and all I had to do was to resolder the shield in place while applying more pressure. 

Let us know how it goes. 

Dany

Comment by Crispin on May 16, 2012 at 1:47pm

Hi Folks,

Now that APM2 supports the optical flow I thought I would give it a try but get "Failed to initialise ADNS3080" both when trying to enable it in 2.5.5 via the terminal as well as the test sketch. 

Checked and double checked the wiring, all seems good.

Any ideas?

Thanks

Crispin

Comment by Crispin on May 16, 2012 at 2:07pm

In reply to my own post - 

If this helps? I stuck some debug into the init for the ADNS3080 and it fails to read the product ID or the product id was not 0x17 so exited false.

Comment by Popa Stefan on May 16, 2012 at 6:43pm

Hello, 

I am looking for the servo_out variable in the newest Arduplane code and I cannot find where it's value is being calculated.

I found in the repository http://code.google.com/searchframe#iTqA9ErfVSM/ArduPilotMega/trunk/... this formula, which is impossible to find in the newest versions of the code.

servo_out[CH_ROLL] = PID((nav_roll - roll_sensor), deltaMiliSeconds, CASE_SERVO_ROLL, 1.0);  
servo_out[CH_PITCH] = PID((nav_pitch + abs(roll_sensor * PITCH_COMP) - pitch_sensor), deltaMiliSeconds, CASE_SERVO_PITCH, 1.0);
 
Can somebody help me with this? Is really important

Stefan

Developer
Comment by Randy on May 16, 2012 at 8:57pm

@Popa,

     I'm not super familiar with the arduplane code but it looks like it's stil there it's just that instead of putting the servo output into that "servo_out" array, it's being put into g.channel_roll.servo_out.  Here's the link to the equivalent place in the code.


Developer
Comment by Randy on May 16, 2012 at 9:02pm

@Crispin,

     that's a sign that it's not able to communicate with the sensor.  So when it starts up it first asks the sensor for it's product id and it should reply with 0x17.  if it doesn't (like for example if it replied with 0x00 or 0xff) then the communication line is not working.  That's most likely the MISO (master in slave out) or MOSI (master out slave in) line that's not connected properly.   Of course you've followed the wiki instructions carefully.

     I'm sure you don't have a logic analyzer so it's hard to be sure what messages are passing through the lines.

     Of course, the little red light is on, on the optical flow sensor?

Comment by Crispin on May 17, 2012 at 12:18am

@Randy

I did follow the wiki. when it boots after putting the test sketch on, I get the menu but it's preceded by the error, could not initialise the sensor. If I put 2.5.5 back on and try enable it through the CLI it does not enable and returns the error. Yes, the led is on ;)

As for the logic analyser, I don't have one but don't need much of an excuse to get another toy. I could have one tomorrow if it's going to help?

Comment by Grant Olivier on May 17, 2012 at 2:36am

Hi All

Can someone provide a short description with a photo (if possible) of how I should configure the solder bridge on APM2 (V2.4.1) to use UART2 for telemetry? Also if one does so do you lose telemetry on the UART0/2 port when the USB cable is disconnected?

Just some feedback, flew ArduPlane V 2.34 yesterday morning as my first flight after integrating the board into a  Dynam Hawk Sky. Successfully evaluated stabilize, FBW-A and RTL mode - thanks to the developers for their effort.  Still have problems with the M-TEK GPS not getting 3D-Fix when the board is powered up any way other than via the USB. I,ve just taken delivery of a uBlox GPS so I'm going to check whether it establishes lock more reliably than the M-TEK whilst powering up the board from an ESC/BEC. 

Thanks in advance.

Grant 

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

Social Networking

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.

A list of all T3 contests is here

Groups

Advertisement

© 2013   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service