Parameters related to battery chemistry

[jstroup1986 (Joseph G Stroup Jr)]

I’m considering changing the battery chemistry on my copter.

Is there a list of parameters associated with battery chemistry?

Note - battery chemistry is a selection on the setup parameters page - but other than perhaps the failsafe voltages, I’m not aware of the what all parameters depend on the battery chemistry.

Many thanks!

[dkemxr (Dave)]

@jstroup1986

I’m not aware of the what all parameters depend on the battery chemistry.

Only the voltage based thrust linearization parameters:
MOT_BAT_VOLT_MAX/MIN

[xfacta (Shawn)]

Here’s the whole run-down:

Batteries	Hi	Crt
Lipo	4.2	3.3
LipoHV	4.35	3.3
LiIon	4.1	2.8

These are the generally accepted values. Some LiIon cells may have a slightly different critical voltage, but all Lipos are the same.

In MissionPlanner Initial parameters (and the spreadsheet)
BATT_CRT_VOLT = (bat critical voltage + 0.2) x no. of cells
BATT_LOW_VOLT = (bat critical voltage + 0.3) x no. of cells
BATT_ARM_VOLT = (no. of cells - 1) * 0.1 + (bat critical voltage + 0.3) x no. of cells
MOT_BAT_VOLT_MAX = bat high voltage x no. of cells
MOT_BAT_VOLT_MIN = bat critical voltage x no. of cells

Initial parameters.xlsx

[jstroup1986 (Joseph G Stroup Jr)]

Thank you @xfacta - This is a helpful review.

As I see it - these parameters fall into two categories - Failsafe and Scaling.

MOT_BAT_VOLT_xxx are for scaling.

BATT_xxxx_VOLT are for failsafes.

I was primarily interested in parameters that affect flight performance - so that would be the scaling parameters.

Interesting about the BATT_CRT_VOLT parameter - it can be disabled by setting to “0”. I’m not setting that failsafe for now.

Do you have thoughts on the BATT_FS_VOLTSRC parameter - the choice between raw voltage and Sag Compensated Voltage?

Although I’ve not read it stated - my assumption is that Sag Compensated Voltage is the “resting voltage” that can be charted on the Mission Planner BIN charts.

This is all very helpful - thank you both @dkemxr and @xfacta .

[xfacta (Shawn)]

I thought I’d throw everything in there for you

I’ve found the battery settings are most needed during testing, there’s no real detriment to setting them correctly from day 1. As time goes on you rely on them less and they are there to cover the unexpected problems.
If they cause unexpected failsafes, or you cant arm, then there’s a battery voltage issue you need to investigate.

Usually I just use the raw voltage value. The sag-compensated value is good if your current monitoring is very accurate and for low C batteries.
To adjust the sensitivity change the BATT_LOW_TIMER

[jstroup1986 (Joseph G Stroup Jr)]

My DIY 5000 mAh Li-Ion pack is able to keep my Hexsoon EDU-450 aloft for 20 minutes before failsafe.

To get the 30 minutes I’d like to achieve, I’d need about 7500 mAh - which would mean a 2P pack - and I think I’ll put that off for another time.

One interesting thing - the datasheet for my cells says full charge is 4.2 volts - and my charger only goes up to 4.15 volts. So I leave a little on the table - but have a margin of safety.

As Li-Ion cell’s voltage drop off more severely than Li-Po cells, it’s interesting to see the current rise as the copter maintains constant wattage.

Thanks @dkemxr and @xfacta for your help on this project.

[jstroup1986 (Joseph G Stroup Jr)]

I’m testing a new 6500 mAh High Voltage LiPo on my Hexsoon EDU-450. I’ve have goal of 30 minutes flight before triggering the battery failsafe.

I used @xfacta 's “whole run down” parameters - thank you Shawn for including LipoHV.

I found that using your suggested parameters I got 19:30 minutes of hover flight before battery failsafe - consuming 4293 mAh - 66%.

Changing BATT_FS_VOLTSRC to “1” to so the failsafe would occur at the calculated resting voltage, the hover flight improved to 26 minutes - consuming 5783 mAh - 89%.

Cell voltage at the failsafe was 3.51 volts. It recovered to about 3.7 volts for all cells.

This failsafe might ordinarily be too low. My intention is to plan survey missions of 20 minutes - giving me 10 minutes of margin - if I can achieve the 30 minute goal I’m hoping to achieve.

I’m hoping that after a new PID tune for the extra 50g of battery weight and a simulated photo survey mission that I’ll get a minute or two longer flight time.

I’ve uploaded the BIN files for these two hover test flights in case anyone wants to examine the details.

HV LiPo Hover Tests - EDU-450 V2

[xfacta (Shawn)]

I think you could safely set
BATT_FS_LOW_ACT,2
to initiate RTL instead of Land.
Also see related params
RTL_CLIMB_MIN
RTL_CONE_SLOPE

This is a bit on the unusual side, but OK if you like it like that.
ATC_INPUT_TC,0.42
I usually use around 0.22 but it can be related to the aircraft “snappiness” , the use case and user preference.
Just so you are aware in case it was erroneously set to be too soft.

You can safely set
ATC_THR_MIX_MAN,0.5

Any particular reason to set this one so low?
INS_ACCEL_FILTER,10
You have nice low vibrations so it could easily be left at 20, the default.

Change
FFT_MINHZ,80 to 48
and recheck FFTs

MOT_SPIN_MIN,0.06 is very low, I’d probably try around 0.1 to ensure the motors have enough authority to stay spinning during descents and similar. Just do some dynamic test flights and check logs to make sure you are not hitting the new minimum frequently.
Also do some descent testing in Stabilise mode and find a maximum stable descent rate (in logs) and set
LAND_SPEED_HIGH. It can be unnerving when there’s been an RTL for battery and the craft is taking forever to descend because you never set the correct land speed params

MOT_SPIN_ARM can be left nice and low, it’s good to be able to see the props all turning in the correct directions, as long as it is reliable.

Since there’s only Loiter and no Althold, it’s a bit hard to compare, but there does seem to be some movements of position in Loiter. I would halve these params to the values listed here
PSC_POSXY_P,0.5
PSC_VELXY_D,0.25
PSC_VELXY_I,0.5
PSC_VELXY_P,1.0
and retest, do a flight with AltHold and Loiter.

After all that I’d be inclined to run Autotune again, especially if the HNOTCH/FFT works out better.

[jstroup1986 (Joseph G Stroup Jr)]

Thank you @xfacta for taking such a detailed look at my logs. I really appreciate it!

Please allow me to comment on your remarks item by item - as it may clarify my settings - or the changes I may need to make:

1. I use “land” as my failsafe when testing at home where my yard has trees. I have enough space for hovering and short flights - but not enough to safely use RTL.

2. RTL_CLIMB_MIN & RTL_CONE_SLOPE. A good opportunity to review. I usually set RTL_CLIMB_MIN to the mission’s final altitude. And I leave RTL_CONE_SLOPE “steep” - because we have trees here in Atlanta.

3. ATC_INPUT_TC - I was unaware of this parameter - and appreciate your bringing it to my attention. I see it can be set by Mission Planner and Qgroundcontrol on these screens:

I had erroneously thought those screens controlled changes to the PID’s. Thank your for helping me clear that misunderstanding up.

As it happens - I try to fly only automated missions except when testing - so the “mushy” setting has worked fine for me.

4. I haven’t looked at ATC_THR_MIX_MAN in a long time - and as I recall I haven’t changed it from the firmware default of 0.5.

What symptom would a copter display that might suggest changing ATC_THR_MIX_MAN to a higher value?

5. I had to check where INS_ACCEL_FILTER was set - and I think it was set following the initial setup instructions.
   
   

I never saw any material that described changing this value - so I haven’t. If I were to change it, I’d like to see some documentation on how much to change it, and maybe a little about why.

Can you refer me to anything that describes the benefit of changing this parameter - and how much of a change?

6. Regarding FFT_MINHZ - When I implemented FFT on this copter a few weeks ago it was the first time I’d addressed FFT in about a year. It seemed like a lot about FFT had changed, and virtually all of the settings were done automatically now once FFT was enabled properly.

To crystalize my understanding of the new process and to benefit others I wrote up what I’d done: Technical Article – Notes on ArduPilot FFT Based Harmonic Notch Filter | Copter Cam Tech

As such, I haven’t set FFT_MINHZ directly. The harmonic notch filter parameters, now nicely displayed on the Mission Planner Extended Tuning page - are all parameters that the FFT function set on it’s own.

Have I missed a step somewhere? I don’t recall reading anything in the FFT docs that suggested updating the value of FFT_MINHZ directly. I’d like to get FFT right - so I’d really appreciate some guidance here.

7. I set MOT_SPIN_MIN and MOT_SPIN_ARM according to advice that I received when I implemented Dshot-600 with a BLHeli32 4-in-1 ESC.

With that in mind, do you still recommend a change to MOT_SPIN_MIN?

8. LAND_SPEED_HIGH - I have this set to “0” so that it defaults to WPNAV_SPEED_DN. So far - the RTL landings - both fast and slow stages, have worked really well.

Do you recommend a change?

9. MOT_SPIN_ARM - agreed about the setting - and noted above was set reflecting a Dshot ESC.

10. Regarding the PSC_xxx_x parameters - the docs don’t mention that autotune changes these parameters.

Have I missed something about this?

I do plan to do a new autotune this afternoon - to update the tune for the heavier battery. After I do and run a test survey mission - I’d be really grateful if you’d take a look at the log file again.

Many Thanks!

[jstroup1986 (Joseph G Stroup Jr)]

I completed another autotune this afternoon with the new battery.

I then flew about 5 minutes worth of my standard test mission - I’m curious if the PSC_xxx_x parameters seem more reasonable to you. I pulled up these from an old flight - and compared it with the flight after autotune today. It appears that autotune did not change these parameters.

The log file for today’s test flight after the autotune is uploaded here:

Partial TM grid after autotune - 2022-10-27 13-59-29.bin

[xfacta (Shawn)]

• 1. and 2 yes, fair enough. Remember to change the battery failsafe and RTL params when you move away from testing in confined spaces
• 3. 0.15 is default and makes for very snappy control inputs, which often suits small quads and similar. Usually up to 0.3 would be as far as I’d go in terms of softness, just in case you do need a quick reaction near an obstacle.
• 4. the tuning guide recommends setting ATC_THR_MIX_MAN to 0.1 for initial flight to maximise attitude control and help reduce the risk of fly away. Normally you would return it to 0.5 (the default value) once you’ve confirmed there’s reasonable stability and minimal risk of fly-away. It can be adjusted to suit the use case. Check the description in the all parameters list.
• 5. INS_ACCEL_FILTER is probably only listed as a first-flight safety thing. Normally you’d only lower this from the default (20) for very large copters (hollow monocoques spring to mind) where it may be impossible to do more to reduce vibrations. As I said you should have this at 20 since it can filter out useful movements if set too low.
• 6. Check your FFT graphs, vibrations are clearly creeping in well below the FFT_MINHZ. Just because it’s automatically set to something by default doesnt mean it suits your aircraft. An EDU450 with minimal takeoff weight will have a hover frequency of around 80 to 85 Hz typically - right on FFT_MINHZ.
     That doesnt mean the frequencies dont ever go below that, in fact for quite some critical stages of flight (descent, attitude control) motors could very well be below hover thrust (and frequency). This is why we set INS_HNTCH_REF to somewhat less that hover thrust when using throttle based harmonic notch filtering. As a reference the formula for that is:
     INS_HNTCH_REF = hover_thrust * (min_freq / hover_freq)^2
     When using DSHOT and having the RPM data logged you can easily convert that to frequency too.
     Hz = RPM / 60
     Estimate you lowest normal RPM from motor/prop data or logs of dynamic flights and see if that matches with you minimum frequencies recorded in FFT or included within FFT_MINHZ and FFT_MAXHZ.
• 7. Yes the normal old fashioned way of setting MOT_SPIN_MIN is MOT_SPIN_ARM + 0.03 but that really only applies to old fashioned conventional PWM ESCs where the arming RPM was quite high and could not reliably go any lower. That method typically gave a value of about 0.10 to 0.13.
     BLHELI ESCs are a whole new bucket of worms, able to run the motors more reliably over a much wider range of speed and torque. You may need to test for MOT_SPIN_MIN using dynamic flight and descent rate tests (stabilise mode) but what you do not want is a value so low that descent or wind disturbances can stop the props or cause desync. I’m confident a BLHELI ESC could recover BUT you dont want it to have to recover, you just want it to stay working and contributing to attitude control.
     MOT_SPIN_MIN should be as high as you can get it without hitting that value during normal dynamic flight.
• 8. and 9 - yes, but do test for maximum stable descent rate. WPNAV_SPEED_DN might need to be different to LAND_SPEED_HIGH in a lot of situations. If you then add a payload such as a gimbal you might want to reduce the descent rate to ensure stability.
     As I said a bad choice, or even the default LAND_SPEED_HIGH, can be very unnerving if the quad is descending very slowly during a battery failsafe, especially when you know it could descend faster and still be stable.
     I know a well tuned ED450 can descend like a rock and still be stable - it’s quite something to see!
• 10. Autotune doesnt change any PSC params at all, I’m not sure what you expected.
      If you had a test flight including both AltHold and Loiter we might be able to more clearly see if there’s any issue with the PSC params. there is additional logging if you ever need to get in-depth, but no need at this stage.

So running Autotune again probably wont change anything unless you change at least the FFT_MINHZ and INS_ACCEL_FILTER as I suggested.

All parameters list for reference
https://ardupilot.org/copter/docs/parameters.html

[jstroup1986 (Joseph G Stroup Jr)]

Excellent @xfacta - This is really a great thing you’re doing.

1. Resolved

2. Resolved

3. Resolved - I changed ATC_INPUT_TC from 0.42 to 0.15. Yes - the copter is now “snappier.”

4. Resolved with documentation issue - I changed ATC_THR_MIX_MAN TO 0.5. No issues on a test flight. I found nothing in the docs (parameter list or tuning guide) that said that the default for this parameter was 0.5. And I could find nothing in the tuning guide to direct this parameter be reset to its original values after using 0.1 for initial testing. The parameter list also lists this parameter for “advanced users” which raises caution.

5. Resolved with documentation issue - As in 4) above, I found nothing in the docs that stated the default for this parameter - or direction to reset it after initial setup and testing. And this parameter is also listed as for “advanced users.” I did an quick test flight just to make sure nothing strange occurred - all OK. I’ll look at it more closely when I examine the notch filter more closely.

6. Follow up question - I re-ran a FFT data collection flight with all the parameter changes thus far on this list. I graphed the result and “boxed” the area below 80hz, which is the setting for FFT_MINHZ.
   

   
   
   Is the area that caught your attention the small shoulder that is at about 70hz?

I haven’t addressed bi-directional Dshot yet - so I’m not looking at RPM data yet. But I may do so in the future - for the reasons you outline.

7. Resolved with a follow up question - I doubled my MOT_SPIN_MIN from 0.06 to 0.12. That’s still slightly less than the listed default of 0.15. I’ll keep an eye on it - but so far I’ve had not trouble. Maybe when I increase my RTL descent speed it may come into play.

Regarding getting it as high as possible without hitting that value during normal dynamic flight - how can I tell what values occur during normal dynamic flight?

8 & 9) Resolved - LAND_SPEED_HIGH had been using 150 cm/sec - as it was set to use WP_SPEED_DN. I’ve increased it to 200 cm/sec. I’ll increase to maybe 250 if all goes well.

10. Tabled for later - There’s no guidance I’ve read for PSC_xxx_x parameters - I don’t know how they’re initially set - or the procedure for evaluating them. I can see by reading the parameter descriptions that they’re involved in tuning.

Any guidance you can offer about them would be appreciated.

The subsequent autotune parameter did change - which I expected because of the 50g heavier battery. Some of the values were set out of range according to Mission Planner. Any thoughts about that?

This spreadsheet shows the progression of autotune parameters. The column on the right is the one I just completed.

If you’d like to look at the log from the autotune flights, I’ve uploaded them to dropbox. I did pitch and roll on one flight - yaw on a second flight. Both flights are in the same BIN file.

Autotune - 2 flights - 2022-10-27 13-43-05.bin

I really feel like I’m accomplishing something - many thanks to you!

[xfacta (Shawn)]

6 basically from 50hz upwards is what you want filtered, going by your pic.
The frequencies below 20 are getting into attitude control that ardupilot needs to know about.

7 if you were getting down to MIN in flight you would see the PWM representation in RCOUT getting flattened at the bottom (flat lining). It can happen, but if it is frequent or sustained, that’s a problem.
MOT_SPIN_MIN should also be lower than hover thrust.

10 correct, there is not much out there about tuning PSC params. Usually we would leave them all alone unless there’s an issue. A test flight with Althold and Loiter can show up problems if they exist. Lately I’ve seen some issues so I’m checking closely.
Using values I gave (half of defaults) doesn’t compromise the ability to hold position, it just reduces the severity of movements when trying to follow a wandering GPS position, for example. Issues can also manifest as oscillations in Loiter even while moving.

“Out of range” doesn’t really mean what it says anymore. Those are more like old suggestions in MissionPlanner that could be removed.
You can see that PIDs can easily go to values never dreamed possible a few years ago. Better ESCs, FlightControllers and vast software improvements have changed some of the old rules.

[jstroup1986 (Joseph G Stroup Jr)]

6. I’ll set 50hz and see what I get.

7. Dshot doesn’t generate RCOUT data.

The copter does fly pretty well with these “out of range” PID’s.

I wish I’d gotten better efficiency from using BLHeli32 and Dshot-600. But I’m pleased with the simplicity and responsiveness.

[xfacta (Shawn)]

In logs there is RCOUT represented as PWM even if you are using DSHOT

[jstroup1986 (Joseph G Stroup Jr)]

Here’s the new FFT charts with FFT_MINHZ set to 50.

It was weird - the copter flew great - but when I armed it, the copter wobbled on it’s legs until the RPM came up a bit.

I think I’m going to bring MOT_SPIN_ARM up a little bit.

[jstroup1986 (Joseph G Stroup Jr)]

My plots of RCOU are all 0.

I must be doing something wrong.

[xfacta (Shawn)]

That FFT is excellent, in-flight FTT and HNOTCH working as planned!

Sometimes Yaw RAT p and I can contribute to that arming shake, I’ll check more.
(working solely on mobile phone at the moment)

[xfacta (Shawn)]

Check output 9 10 11 12

[jstroup1986 (Joseph G Stroup Jr)]

Yep - of course, because they’re on Aux ports. Brilliant!