Altitude hold tuning - PSC values

Finally i have the heli pitch,roll and yaw functioning correct without fluctuation and prompt response.
Now i’m doing the ALT HOLD and POS HOLD tuning …
seems that the altitude command is rapidly drifting up and i have to compensate by taking down the command yill i have to disengage the mode and go back to stabilized which is a bit cranky, as i have to flip quick up the collective command.

I found no process notification on the tuning document, is there one ?
following is the graph that shows the collective (c3) command and servo behavior


And here is the data on the PID the altitude target is getting up ??

@ZvikaF Please provide a log so we can better help you. Thanks!

@bnsgeyer Thanks a lot, appreciate that
following is the link to the log

https://drive.google.com/file/d/1QnC6oNm8F2IsG_jln2bSRKyU9MBLpgU4/view?usp=sharing

@bnsgeyer, According to the wiki, there should be “MOT_HOVER_LEARN” parameter to help adjust the hoovering throttle/collective. This parameter is not included in the firmware i have (4.0.3), also “MOT_THST_HOVER” is missing … I suspect it has to do something with the throttle calibration.
In the recorded flash data i see that “CTUN.ThH” is on 0.5, while my hovering stick is about 60% …
I suspect those contribute to the problem.
Heli Collective setup : Min: -3 , Max: +12 , hovering at about +6 :slight_smile:

PS: found that in order to be in hover at mid collective had to change IM_STB_COL_3 from 60 to 80 …
( I had took it down previously from 75 to 60 thinking it will stop the altitude gain the heli did …)

best regards

@ZvikaF Tradheli does not use have that feature and that is why those two parameters are not in Tradheli parameter list.

CTUN.ThH is not the signal to be looking at to determine your collective for hover. CTUN.ThO is the throttle output which for heli’s is the collective output. the full range is 0 to 1 where zero is the collective at H_COL_MIN and one is the collective at H_COL_MAX. I looked at this signal for your log and it is near 0.75. So if your min collective equates to -3 deg and max to 12 deg, this means you are hovering at roughly 8 deg collective. What rotor speed are you flying this heli at? Your hover collective should be near 5 deg. I would recommend either reducing your heli’s gross weight or increasing your rotor speed.

Regards,
Bill

@bnsgeyer, Thanks a lot Bill, you are a treasure.
I could not make sense out of the parameters.

Measuring the rotor RPM with both RPM sensor i have, did not work.
I had set the RPM to the minimal i felt good with.
As the heli is heavy due to the instrument i installed ( its about 860 gr.), the only option to reduce the collective pitch, is having more RPM as you suggested.

I did it, and tried hovering in ALT-HOLD mode, in one occasion, i had the heli fast gaining altitude, and in the second one it was surprisingly level. where in the parameters or in the PIDA can I find the reason for such behavior ?

Thanks again for your help.

best regards
Zvika

I think the first thing to do is ensure you were not commanding the hieght change. Check RCIN3 and make sure it is within THR_DZ value of 1500 or whatever you have set as trim for RC3.
If it was not commanded, then you can look at PIDA and compare PIDA.tgt to PIDA.act. Basically looking at the target value and actual value. If you did not command it then it most likely is the Baro drifting. This is not uncommon.

@bnsgeyer Thanks again.
Checked RC3 and found that MAX is 2006 MIN is 984 and TRIM is 984.
I suppose this might explain the desire to gain altitude, changed it to 1540 which is the hovering position. will try it later :slight_smile:

looking at the data ( see the folowing chart) I see CTUN.Dalt drop from 0 to -1.78 and immediately jump to 0,67, I started to lower the colective command (RCIN.C3) but the DAlt did not change ?
should it ?
CTUN.Alt shows pretty good the heli behavior of altitude gain so i suppose the baro is not drifting.

@bnsgeyer worked like a charm :slight_smile:

Tried hovering after updating the parameters… flies great,
I’m doing the hovering tests in a confined area in my back garden but I could almost leave the sticks :slight_smile:

Now i can advance to loiter and navigational modes.

Thanks

I was wrong about the RC3_TRIM. It does not have to be set for the center throttle stick position. I think the firmware choses the center of the throttle stick control throw and then uses the THR_DZ to determine the dead zone. Just beware that THR_DZ of 100 is pretty large band and it is deceiving sometimes. For the multicopter users, they typically have the throttle stick spring loaded to return to center because they may only use modes that use the althold controller instead of modes that have manual control over throttle (multicopter).
So I guess I’m saying that I don’t think it was really the RC3_TRIM parameter change that has fixed your drift problem.

Regards,
Bill

Real puzzling, i had more than 30 seconds of hovering in ALT-HOLD without touching the left stick.
Is the THR_DZ of 100 10% headband ?
I could feel it during the previous ALT-HOLD attempts as there was no response in the middle of the stick.

folowing is a chart of the data during the ALT-HOLD hoovering

The parameters are confined into a narrow stabilized band.

Also the PIDY parameters look calm

I will try more ALT-HOLD flights to check if it holds.

Thanks for your elaborating information and know-how :slight_smile:

Best regards
Zvika

@bnsgeyer, did a couple of flights, ALT-HOLD works great. could control the altitude well.
The collective dead-band of 100 is indeed too much, so i took it down to 75.
Tried to find out in the firmware source (mode_althold.cpp) if RC3 MID is used… but did not find yet :slight_smile:

best regards
Zvika