Copter-4.0.2-rc3 available for beta testing

ArduCopter Copter 4.0
,
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:

29

Maybe we could add a parameter to configure direction?

30

I just updated my CUAV v5+ cube to 4.0.2-rc3 and lost my serial ports. After booting the board ussually I have com18 and 19 (19 is SLCAN)

After loading the rc3 beta I no longer had those, only a single STM32 on port 10.

I was not able to connect mission planner at all via USB. I was able to connect via telemetery radios on tele2 port.

I reloaded a couple of times and same issue.

Then I grabbed the “latest” (4.0.2-dev) apj file and loaded that. Thankfully that worked and restored all my com ports and mavlink was able to reconnect via USB.

Just FYI

31

@vosair,

Thanks for helping us test this beta and reporting back. So this pre-arm message is to ensure that the ACRO_BAL_ROLL/PITCH parameters are smaller than ATC_ANG_RLL_P and ATC_ANG_PIT_P. This makes me think that autotune came up with very low ATC_ANG_xxx_P values. With such low values I wonder if it will fly ok.

FYI @Leonardthall

32

@smartdave,

Thanks for the report. If the CUAVv5+ isn’t working then this is definitely a serious problem that we need to fix.

I’ve tested with a CUAVv5 (not the plus) and found:

  • CUAVv5 works using Copter-3.6.12, fmuv5 or CUAVv5 firmware
  • doesn’t work with Copter-4.0.0, 4.0.1 nor 4.0.2-dev using either fmuv5 or CUAVv5 firmware

In cases hwere it “doesn’t work” the LEDs do light-up on the board so it’s alive but it doesn’t seem possible to connect using USB.

I’ve added this to our Copter-4.0 issues list

EDIT: I’ve now got my CUAVv5 working after a parameter reset (I loaded plane onto the board and it worked and then I went back to Copter and all was fine). This may mean there was some parameter value causing problems… @smartdave, if you’re happy posting your params somewhere that might help. I may also have my params saved in a logfile somewhere.

1 Like
33

I have installed AC4.0.1 on CUAV V5+ and flown frame type as DJIX very efficient performance then normal x configuration. there is a significant different when DJIX configuration
And seems there is no usb serial issue.2020-01-30 17-02-30.log.param (17.9 KB)https://drive.google.com/file/d/1oaNmqx0z4-8ZRoE7EygERnPJaUeAE1x2/view?usp=sharing

1 Like
34

Here you go

https://1drv.ms/u/s!AplYZe-uqPEBgu0HxkHdmICGP24Msw

Keep in mind that the system did work, it just seems like the usb serial port drivers didn’t load/work since I still was able to access it via telemetry radios

And then loading 4.0.2-dev (latest from last night) fixed the issue and it kept my parameters

1 Like
35

@vosair
We had the same thing happen to our large hexcopter this summer. The ATC_ANG_RLL_P and ATC_ANG_PIT_P returned by the auto tune were very low and we got the same Acro warning. Similarly we changed the value to 0 to allow it to arm. On takeoff the drone pitched into the ground almost immediately so I would NOT recommend flying with those auto tune numbers. Being that it is a small quad you may have a different experience but I would exercise extreme caution.

1 Like
36

For the most part it flies ok. The biggest issue I noticed is if you give it big stick inputs it wants to oscillate on that axis. Here’s a log of the flight https://drive.google.com/open?id=1p8UyPc56orX-goPDXp6BxJQwIch_r-Pj

37

I have a question:

If I set RC_OVERRIDE_TIME= -1, does the FC accept standard PPM input UNTIL it gets a Mavlink command? And if the copter is is being controlled by Mavlink and if PPM signals suddenly appear, does the FC revert control back to the PPM signals?

38

Good autotune and short test flight. d300

  • 300mm wheelbase AUW 1.5lbs
  • 2206-13 w/ 6in props and 3S 1500
  • Luminier 36A esc’s w/ BLHeli 32.7 (Auto Timing enabled) and ESC Telem
  • PixRacer w/ mRO Hall power module and HolyBro Micro GPS Module
  • FrSky X4R w Passthrough Telem
  • 400 main loop, DShot150 and dynamic hnotch enabled

Full params and logs of each axis autotune and follow-on short test flight…
https://drive.google.com/drive/folders/1fk-8pMvyiEApRKgoljqiRk3rkNWlGoU5?usp=sharing

1 Like
39

Nice job with the setup and tuning on this craft! The after Autotune flight characteristics are excellent.

40

Thanks! Even I could look at the desRoll/Pitch/Yaw vs actual and tell it was working, and I suck at analyzing logs. Vibes could be better but I am testing a 3D printed TPU mounting system for devFrame. For a heavy 6in with unbalanced cheap props I think it’s OK.

@rmackay9 @tridge @andyp1per @Leonardthall and the rest of the team did all the hard work and should be pretty damn proud. I know the 4.0+ release has had some bumps but once you get it setup with the new dynamic notch filters it’s pretty amazing.

1 Like