About collective pitch ！
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.
Just wondering if anyone has a time line on RC3 being released?
In particular the fix to external I2C hangups, as this is holding back further testing.
BTW, everything else is just great with ChiRC2.
Have not tested all modes but in a grossly overpowered quad the stock PID’s flew it fine, it just breezed through autotune the new loiter is just rock solid.
Love the braking in loiter now, very nice addition.
Have not checked Auto yet. (weather)
Hi Pete,
-rc3 will be out in a couple of days and will include auto building of the mini-revo firmware. thanks for testing!
Brandon,
Txs for the report on the choppy loiter using ChibiOS. It definitely surprises me and I 50% suspect environmental issue but ChibiOS is new so it’s very possible that it has some problems. I’ll give it a try and see if I see anything. -rc3 will be out soon and I know Tridge & Co have fixed various things so maybe it’ll be better…
I did test a few times going from the nuttx rc1 that you made me and the Chi versions rebuilt the copter a few times to make certain it was not a random setup. The odd thing is Nuttx 3.6rc-1 is stellar! will try it when the new build is out.
The FC is the mRo 2.1
1 Like
Great, Thanks,
I will flash to that and see if i can get to the to bottom of this compass issue and report back
1 Like
Hi,
is there anybody else here with issues to invoke simple mode? everything else works fine but after several tests and switches to 3.5.5 and back to 3.6 rc2 it is same - if vehicle powered first and then radio is turned on then simple mode turns on even with ch12 switch not up, if radio is on first and drone powered next then simple mode sits off and does not respond to switch to turn it on until super simple mode turned on by ch9 up (with ch12 up as well), then after super simple mode turned off it turns on simple mode as its switch is still up. it is quite ridiculous and i cannot find what drives it. re-calibration of radio did not do any difference. 3.5.5 works fine.
features on other channels work fine and get invoked with no issues.
1 Like
I had a odd issue as well depending on how i started the craft battery or usb with battery the radio would stick in binding mode and the craft would have major shakes. I was told to remove some of the redundant wires on the radio and that seemed to fix it. It was reproducible.