Copter-4.0.2-rc3 available for beta testing

ArduCopter Copter 4.0
,
9

I had not tried it before but saw it in the beta update so decided to check it out. Cheers Marty!

1 Like
10

Verified the tones and lights for the GCS Failsafe are working as intended.

1 Like
11

Hey @rmackay9, on TradHeli today I still had the seemingly-reversed version of Circle, where when I pitched “forward”, the radius would increase, and when I pitched “rearward” the radius would decrease.

12

On the FC MATEK F405 CTR I have baro bad health if RGB led connect to led pad on FC

13

@rmackay9
Hi Randy,
unfortunately a negative on the RNGFND1_OFFSET fix. Still the same behavior with 4.0.2RC3 like with 4.0. Any inputs for the offset are ignored. (its working well with AC 3.6.12 NuttX)

The PX4FLOW seems to work now, at least I get non-zero readings now for opt_m_x, opt_m_y and opt_qua.

Other issues and observations:

  • Battery voltage is displayed on the GCS (MP, QGC and Solex) about 3 volts higher than in reality (voltage meter mesurement). AC 3.6.12 displays battery voltage correctly when I downgraded again.
  • Altitude is always zero via FPV telemetry but ok on the GCS. Is working well with AC 3.6.12. It seems like the DEV_OPTIONS parameter did not get migrated during the update - I had to set it manually to 3 (Dev_OptionVFR_HUDRelativeAlt was disabled)
  • also ADSBMavlinkProcessing was disabled in DEV_OPTIONS - could this be a reason that others were complaining about no aircraft detected?
14

@rmackay9 Willing to test this if you think it helps as there may be other esc sync issues. I started another thread to find out as it could be something I am missing in setup.

15

@mtbsteve,

Thanks for the report on the RNGFND1_OFFSET. Indeed there’s a problem with the change so this will unfortunately mean we will need an -rc4. Thanks for the report though! I might come up with a test build so you can give it a try earlier than the next release candidate.

I’ll have a look into the other issues you’ve reported as well. The battery voltage one surprises me but I have two theories:

  1. the scaling parameter values are different between the two versions. This can happen because we only do the parameter conversion once so if the vehicle is moved back and forth between the versions. We can check this if you’ve got an onboard log on 3.6.x and 4.0.x.
  2. one version is reporting a sag compensated value and the other is reporting a raw value.
16

@aMax52,
Thanks for the report. I wasn’t aware of this issue and it wasn’t on our Copter-4.0 issues list so I wasn’t tracking it. I think it’s very unlikely to be resolved in this beta but hopefully one of the other devs can tell me which patch we need to back-port to get it working.

17

@mtbsteve,

Could you try this firmware for CubeBlack to see if it resolves the PWM RangeFinder offset parameter issue?

18

@rmackay9 are you likely to merge my dataflash fixes? I can do a separate PR if it helps.

19

@andyp1per,

I was planning on including them in a point release but perhaps not 4.0.2 because we’ve got this serious AutoTune issue to get out. If it’s not in master yet then we should probably tag it as a DevCallTopic so that it gets reviewed at the dev meeting tomorrow. If it’s already in master we just need to set it’s project to, “Copter-4.0 backports” and then I’ll remember to merge it into the next point release.

20

Hi Randy,
4.0.2dev fixes the problem with RNGFND1_OFFSET. That works now as in 3.6.

However the voltage and Current scaling issue still persists.
Here is an image showing the real values measured with a Jeti sensor and the measurements of AC 4.0.2dev coming from a 3DR sensor. Again, in 3.6 the voltage measurements of the Jeti sensor and the 3DR sensor are equal.

IMG_7380
IMG_7380960×1280 333 KB

Here is the link to the log file:

EDIT: Link to 3.6.12 log added:

Next problem:
With AC 4.0.2dev, there is NO telemetry anymore to my Jeti RC. Something must have been broken from 4.0 -> 4.0.2dev.

21

@mtbsteve,

Great. thanks for confirming the RNGFND1_OFFSET fix. This will go out with -rc4 perhaps as early as tomorrow.

I had a look at the logs and the issue is the default BATT_VOLT_MULT has changed. In Copter-3.6.12 it was 10.1 but in Copter-4.0.x it is 12.02. This seems to be a change made on purpose. I’ll double check with @bugobliterator if BATT_VOLT_MULT = 12.02 is a good default value for the Hex Cubes but on my particular CubeOrange it seems close.

I think for now you could manually change BATT_VOLT_MULT back to 10.1 or we have a wiki page here which also shows how the calibration can be done.

Re the JetiRC, thanks for the report. Whatever has changed won’t be included in Copter-4.0.2 so we can tackle the problem when it shows up in a future beta.

22

It’s in master. I can tag the changes - there are three of them.

UPDATE: ok done

2 Likes
23

Thanks Randy. I calibrated BATT_VOLT_MULT and it displays the correct voltage now.
I will wait for 4.0.2RC4 and then recheck the Jeti telemetry issue again.

1 Like
24

Solved. MiniPix 1.0 V1 / Copter-4.0.2-rc3_heli
Previously I got the the tiny currend values only when the board was at the usb port…?? After several tries I managed to get my data into the column messured currend ,but I had to switch several time from " others" to the upper listed currend sensors before the misson planer accepted this and it was not lost or altered after the next boot.
Now there is even my voltage reading up to date.

1 Like
25

Are these fixes on rc3 or on the next release?


26

Those went out with Copter 4.0.2-RC1

1 Like
27

So it turns out it was actually the way everyone wanted it to begin with originally… pitch stick up, forward, reducing radius. Pitch stick down, backwards, increasing radius. I messed up and thought it was the other way around because I forgot pitch PWM is the reverse of the stick direction. So in fixing it, I unfixed it. So I fixed it again. In the -RC4, which is hitting the streets today, it should work as desired. For real this time. :slight_smile:

9 Likes
28

I have 4.0.2 installed on a small quad with a Omnibus Nano v6. Everything seems to work as it should except for this strange issue I ran into today. I successfully completed an autotune. When I landed it saved the new values and I tried to arm to do a test flight. I ended up getting this message PreArm: ACRO_BAL_ROLL/PITCH. I checked the ACRO_BAL_ROLL and PITCH parameters which are both at 1 which I assume is default. Everything I found when I searched the message was from pretty old posts saying that the value needed to be 1. Any idea what’s going on?

[EDIT] I changed ACRO_BAL_ROLL/PITCH from 1 to 0 and it allowed me to arm. Considering we aren’t using ACRO flight mode I figure this shouldn’t be an issue. If anyone knows why this isn’t a good idea feel free to let me know :slight_smile: