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.
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.
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.
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.
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.
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
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.
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.
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.
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
@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.
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?
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.