Copter-3.6.0-rc2 available for beta testing

I did some digging on the rc-1 page. here is a response a similar question: dkemxrDaveApr 29

“This is simply because the parameter name has changed in 3.6 and Mission Planner has not caught up. Functionally it’s still works as the values you had previous to updating were transferred. If you want to change this value do it from the Full Parameter List BATT_AMP_PERVLT (note the change?)”

how could I solve this?

@rmackay9

Randy !

My helicopter T-rex500 uses the Pix+FBL mode, which works well on the 3.6rc1, and is a great Loiter. However, when I brushed the firmware to 3.6rc2, no parameters were changed, and the helicopter’s total distance became very small, almost 2-5 degrees, and it was about 12 degrees before! Moreover, I tried to change H_col_max, but did not improve, still a small total mechanical distance.

Yes, that parameter was set in my setup. I see it now - looked at logs again, for reasons that are difficult to comprehend what used to be section CURR in logs is now named BAT, and it has Volt and Curr tags in it. MP is not aware of any of that so it does not show nothing.

It also screwed up FRSky telemetry outputs mappings, it looks like, as yaapu9 lua script now gets garbage instead of proper Curr value, but somehow still gets proper voltage. I will try to look at it tomorrow, if it is something easy enough to fix or not, for new taranis it is a PITA to deal with those scripts and pre-compile them into libraries…

@rmackay9

Confirm that the problem is indeed 3.6rc2 FW, I brush back to 3.6dev on April 22, 2018, without modifying any parameters, the maximum helicopter distance is normal! This suggested developers are looking for where the problem lies.

…when I brushed the firmware to 3.6rc2, no parameters were changed, and the helicopter’s total distance became very small, almost 2-5 degrees, and it was about 12 degrees before!

… the maximum helicopter distance is normal!

What kind of distance do you talk about?? collective pitch? or what?

Please post your parameter file. If I had to guess, I’d say your swashplate servo trims were not close to 1500. The change that took place in 3.6-rc2 corrected an issue with the swashplate servos that keeps their max travel the same regardless of where the trim is. I could see that on one side your cyclic would decrease significantly if you originally set your cyclic based on that side. However now your cyclic be equal on both sides regardless of where your trim values are (as long as you aren’t hitting servo limits).

About collective pitch !

here:
Pixhack nano 3.5.5 Black K8 3.6rc2 fist.param (14.1 KB)

I see that you are using an H1 swashplate. Any reason that you have trim on servo 3 set to 1095? I will have to try this to see what effect this has on collective. The code was written assuming that trim for collective was at or very near the center of servo throw (1500 pwm). So I’m interested to see what setting trim to 1095 does. Set servo3_trim to 1500. That should give you back full collective range and should not affect trim collective position.
EDIT: @zhangsir I also noted that you have H_COL_MAX set to 2100 which I thought was strange. I’m assuming the param list was not adjusted at all for 3.6-rc2. This high value of Collective max makes sense with how you had servo3 trim set. with it set to 1095, you would have to have a very large collective max to get the full range of collective because with the servo trim set at 1095, all of your collective movement would be to one side of the servo throw.

@zhangsir
So you will need to set your collective max after you set servo3 trim to 1500. If you are running FBLs downstream then it may be worth talking to @ChrisOlson about his setups for downstream FBLs.

@ChrisOlson I think we need to fix the servo3 trim to 1500 for H1 type swashplates. It would keep users from having the same issue as @zhangsir.

I have a switch set to a ch12 with value ‘3’ to activate old classic simple/headless mode, separately from the current flight mode chosen .
it is no longer working with 3.6. it worked fine with 3.5.5 - and i did not change my radio and i can see how it sends this ch12 data into copter same way as before, but there is no reaction back from it and no message plays ‘simple mode on’ and in reaction to controls it is visible - it is not in simple mode.

PS. it must be a glitch in the 3.6 code. i altered my controls to use super simple mode also now on channel 9.
so, if channel 12 is on - there is no reaction. if channel 9 is on by itself, there is also no reaction.
if channel 12 is on and then channel 9 goes on - the copter activates super simple mode. if then channel 9 goes off (with channel 12 still on) - it switches into simple mode. if channel 12 goes off - it remains in simple mode ignoring switch off. it is quite ridiculous.

Yes, using the H1 swashplate mode is because I’m a PIX+FBL and downstream is an FBL unit.

H_COL_MAX set to 2100 is because the original set 1906 can not increase the maximum collective pitch, so I tried to increase the value of Col_max, but no effect, has not changed back.

Servo3_trim became 1095, this is not right, I did not pay attention to see, but I am using the 3.6rc1 parameters directly used, I also compared the original backup 3.6rc1 parameters, did not find all the difference between the servo_xx parameters .

I try to adjust servo3_trim to 1500 and go to fly again. It is probably the problem here.

Thank you very much @bnsgeyer

I uploaded my 3.6rc1 parameter in the attachment. The 3.6rc1 T-rex500 flying under this parameter is very good.Pixhack nano 3.5.5 Black K8 3.6rc1 last.param (14.1 KB)

Unless I’m missing something t should actually default to 1500. That comes from the servo library and it would have to be manually set to have it at 1095.

Also, with downstream FBL you should not be reversing any servos in ArduPilot unless your dowstream FBL does not support reversing servos. If the normal setup for your FBL is to reverse a servo in the RC to change direction of one, then reversing it in ArduPilot is right thing to do. Different ones are different in this regard.

It may be caused by the default value, because when I test v5 3.6dev, after calibration RC, the Trim value of the channel that is not calibrated is the same as the min value, you need to manually set the value of the channel at about 1094 , 1500, 1934 this range, which is the common PWM channel of futaba.

After I tried to modify Servo_Trim to 1500, the collective pitch returned to normal. I was surprised that there was no such problem in 3.6rc1 before. Then, when I tried to test the flight, I found that after the plane took off, it oscillated and returned to the ground to observe the rudder movements of the three swash-plate servos and found that the left-front servo and the other two servos moved. Differently, when you stop the cycle rocker, it will swing itself near the neutral point. After troubleshooting, I found that the steering gear itself had a problem and I sent it back to the manufacturer for repairs. After repairing, I will continue to test 3.6rc2 and report the results of 3.6rc2 in time. Thank you @bnsgeyer, thanks@ChrisOlson

This was only noticed recently by Bill. There is another servo related PR in the works at present, but Bill made sure this problem does not happen again in the new PR. That PR is not merged yet.

Yes, thank you, I will follow the firmware version update, carry out the actual flight test, and provide timely feedback.

Flew ChibiOS today located http://firmware.ardupilot.org/Copter/latest/fmuv3/ on a Pixhawk classic noticed craft flew ok Loiter mode was ok Flew the craft in ground effect bromator ok. " blew some leaves" then back to Loitor. Craft started to drift it wanted to go back to its imperial homeland. Landed craft did a calibration Compass was 180 degrees off. Rolled back to Nuttx RC1 and compass was corect mounted due North. BTW compass cal only recognized one compass under Chi, also beeping was off.
Installed chibiOS off mission Planner ArduCopter V3.6.0-rc2 (2a4b7805) " beta" and i compass seems ok.

Note after plugging the craft in a few hrs later the compass has reversed one more time pos horizon flashing and bad compass health. I will have to wait on Chibios until the next build for this bird and the mRo vx 2.1.

I like to conclude my testing of the following crafts I tested and made.

mRo pixhawk classic with ChibiOS flys well.
mRo vx.2.1 flight controller ChibiOS stableise flight mode ok Loiter flight mode very bad.
Pixhawk classic import clone. flys ok but compass setting morph into the dark side after a few boots. north and south poles reversed. drift and GPS flyaways noticed.
Cube 2.1 with custom carrier board flys well.
all crafts are excellent in 3.5 and 3.6 nuttx rc-1 love the new loiter flight mode but tends to drift off center more than Nuttx. in tight 360 maneuvers. I hope my testing and donations has helped.

Omnibus F4V3 3.6.0RC2 hardware with IST8310 connected to I2C2 (at UART3 pins)

The compass is not found. What do I need to set, so the compass is found?

I disabled the arming precheck for the COMPASS, because I wanted to test the motor order and arming, but
arming is not possible. Compass not healthy.

What do I need to do to solve this problem?

I have also the RC9-16 trim error message as another user above, but I could solve this by not checking the RC Control at the arming check.