Stuck tuning and I want to learn more about flash logs

Does this mean setting INS_LOG_BAT_OPT to 4? That would sample pre and post filter.

I am going to start from default because I just enabled the current sensor and I want to get my stuff a bit more organized so that I know what every parameter represents and their job. I got kinda lost when I started auto tuning.

I have also been watching Andy Pipersā€™s videos so I think I have a better grasp on what is going on. In the 2022 Dev conference, he mentions incrementing the LPF by 10.

I didnt answer your questions properly :frowning:

image

In your case the huge peak at about 85Hz is the motor frequency that we do want to filter.
The second Gyro graph is the post-filter output, showing that the filtering is working as planned.
The value we set in INS_HNTCH_FREQ (and BW too) does scale with throttle input, so it works over a broad range of flying condition. The trick is getting the value correct (not too high) to cover those wide throttle variations.

Your INS_ACCEL_FILTER will never need to change, and INS_GYRO_FILTER and some associated parameters will only ever have to change if you replaced your motors and props with something very different.

The HNOTCH settings should be good for a range of flying and purposes. SInce you are using throttle based filtering, you may need to adjust INS_HNTCH_REF if you hover throttle changes much, due to payload or similar. Short term changes probably wouldnā€™t need any adjustments, like throwing on a different camera just for one flight.

Andys videos could be considered advanced tuning - they are very good to study, however tuning can often be simplified:

  • Voltage and current monitoring
  • Initial Parameters
  • Set up HNOTCH first if possible
  • Test flight to gather data
  • Improve filters or set up filters
  • Autotune

Using that process weā€™ve tuned copters with just two flights - 1 test and 1 Autotune - thatā€™s not always possible with all copters, but sometimes you are lucky.
Luck = good component choice, more time spent getting parameters correct before flying.

My spreadsheet can assist with setting some HNOTCH params before flight if ESC RPM is not available.
This was the basis of the Initial Parameters calculator in MissionPlanner. The spreadsheet started life based in Leonard Halls tuning guide. Itā€™s evolved a little over time, due for more updates, and so is the Initial Parameters in MP.

1 Like

@xfacta, thank you very much for that very enlightening response! I think in the back of my mind I was trying to simplify Andyā€™s tuning process, but was getting confused because I didnt realize he was doing more of an advanced tune. That and of course the breadth and depth his videos cover. I really enjoyed studying them though and will continue to do so.

However, regarding the notch and friendsā€¦

Is making the switch to 10 inch props from 9450 built-in-nut props considered very different?

So in order to get the optimal INS_HNTCH_FREQ (and BW too), we do bullets 4 & 5 from your simplified guide, correct?

Also, I am upgrading ESCs today. New ESCs will solve a couple issues I am facing, but I am having trouble choosing the right set. I am still shopping around and I asked someone on getfpv.com about blheli32 esc and they said I can also just get any blheli_s esc and flash them with bluejay to get everything blheli 32 has, it just wont be as fast, is this correct?

One thing I should have highlighted is INS_HNTCH_FREQ (and BW too) does scale UP with throttle input, which dictates the very careful selection of FREQ, BW and REF.

Maybe just a test flight and adjust of filters, but probably a new Autotune would be needed. Some builds handle this type of change with no noticeable difference, and some need a lot of changes.

Correct.

I mispoke before too

we have actually done EDU450 copters with 1 flight for Autotune, then 1 flight just for testing and becauseā€¦
Subsequent EDU450 builds just had 1 test flight to verify they worked using the same tuning params.

I would prefer BLHELI32 over BLHELI_S - go for the proper full implementation not the cut down version for even tinier under-powered CPU chips. BLHELI_S is more messing around with changing their firmware versions, and itā€™s much more of a compromise with some features missing.
Use a 4in1 ESC unless you have a specific need to use individual ESCs.

How about the BLHELI_32 individual esc compared to the the BLHELI_32 4in1, they should be the same, no? The main advantage is the ARM chip, which both should have, correct?

Im just trying to weigh my options because I am running out of room on my craft and I would ideally like to place the esc on the arms to replace the clunky SimonK. On the craftā€™s top level plate, I have a pixhawk1 stacked on top of a RPi. That stack has the anti-vibrate platform in between it and the plate. Then, I have a RPi cam and leddarOne lidar on the undercarriage, which leaves me with the middle compartment to insert my battery. After that, space is a bit limited.

I could probably stick a small 20x20mm 4in1 to the front lip. I attatched a pic of the front lip (I have the telem attena on the rear lip).

I would probably need some protection for it, idk.

I would appreciate your thoughts on the component placement.

4in1ā€™s are 4 individual ESCā€™s on 1 board most with with a common shunt resistor (some with 4 shunt resistors) for current the analog signal of which is typically available as an output. Single ESCā€™s usually have a shunt resistor also and this signal is usually available via telemetry. If itā€™s in the telemetry stream it can be used and summed with the battery monitor function. These things depend on the individual ESC.

I like these for single decent price ESCā€™s:
Single BLHeli_32 ESC

1 Like

Interestingā€¦ these also come with a programmable led, which is a nice touch imo. I wanted to add led but I didnt want a ton of them, this is perfect.

It also says that it has the ability to have a capacitor soldered to it. Is this feature for large batteries? I am flying with 3s, so would I need a capacitor as well, or are they good to go out the box for 3s battery?

6S battery for sure but no harm in using them in any case.

So I have replaced the readyToSky 2212 920 motors with SUNNYSKY 2212 980 and the old SimonK ESCs with BLHeli_32 RDQ ESCs. I was wondering what parameters I should take a look at with this new configuration. It seems like MOT_THST_HOVER has decreased a bit and I believe that I have to now update the MOT_SPIN_ARM and MOT_SPIN_MIN.

I performed a couple test hovers and the craft is unstable. It hovers decent, but after about a minute I can see very subtle oscillations and they continue until it is no longer stable in which case I try to land. Luckily Iā€™ve only hovered very low to the ground so I simply disarm to land lol. Would I be correct in simply looking at yaw and decreasing those PIDs? I will attach a log file of the hover because I am a bit lost on what params I should be looking at to update for the motor replacement.

Motors 1 and 2 seem to be having some trouble, both are CCW. There is no major signs of instability before those two motors start having trouble, and there is no individual pitch or roll instability - itā€™s just a case of those two motors having some issue and Yaw is most affected since the two motors are both meant to be spinning CCW.
Check their props are definitely on tight. Also check the motor wiring. Bullet connectors can give trouble and should be replaced with soldered/heatshrinked wires between the motor and ESC.

Check your BLHELI settings in the ESCs and ensure you have

  • Low RPM Power Protect = OFF
  • Low Voltage Protection = OFF
  • Motor Timing = Auto

I would alter these PIDs just to settle things down a bit and standardise:

ATC_ACCEL_Y_MAX,26000
ATC_ANG_PIT_P,10
ATC_ANG_RLL_P,10
ATC_RAT_PIT_D,0.0048
ATC_RAT_PIT_I,0.12
ATC_RAT_PIT_P,0.12
ATC_RAT_RLL_D,0.0048
ATC_RAT_RLL_I,0.12
ATC_RAT_RLL_P,0.12
INS_GYRO_FILTER,46

These should not change attitude control much and hopefully we will get a better idea of whatā€™s going on next flight.

If you can get all the ESC Telem wires joined into one and connected to a spare serial port that would be very handy. Such as Serial5 RX pin. Then set:

SERIAL5_BAUD,115
SERIAL5_OPTIONS,16
SERIAL5_PROTOCOL,16

I see your existing params say you have a rangefinder on Serial4 and RCin on Serial5 but the photo shows RCin on the normal RCin port. If Serial5 is not really used for RCin then itā€™s a bad idea to have it set for that. So you might be able to use Serial5, or move something to Serial2 (Telem2) if itā€™s not used, or just use Serial2 for ESC Telem.

If you can get that ESC Telemtry working you can adjust the HNOTCH too:

INS_HNTCH_MODE,3
INS_HNTCH_BW,30
INS_HNTCH_FREQ,70
INS_HNTCH_REF,1
INS_HNTCH_FM_RAT,1

Shoot! I had that ā€˜Low RPM Power Protect = ONā€™, changing it now. Also, for some strange reason, anytime I am connected to MissionPlanner via radio telem and then connect to BLHeliSuite via USB/COM, I get a ā€œPreArm: Internal error 0x1ā€¦0 I:174 Imo_resetā€ from MissionPlanner, is that normal?

Do you think that this could be a twisted frame issueā€¦ are you looking at the COUT graphs?

I will also solder the motors and get a four-to-one ESC telem wire connected, but I am waiting on a CAN NODE because I have the Rx telem (FPort) on SERIAL5, the rangefinder on SERIAL4 and have run out of UARTs. I have the radio telem on TELEM1 and RPi on TELEM2. I couldā€™nt figure out how to utilize the RPiā€™s USB/IO ports e.g. turn them into extra UARTs, so I ordered a CAN NODE. There has to be a way to utilize the RPiā€™s I/O and create extra UARTs in the software as oppose to adding more hardware so I will keep searching, but for now ig I will use the extra hardware, since its only an extra 3.7 grams.

I will also update those PIDsā€¦ on the last couple of hovers it felt like the craftā€™s stability sort of ā€œruns away,ā€ if that makes sense. It hovers beautifully at lift off, but then she gets away from me the more input I give.

Before the motor and ESC swap she did the same thing only when I did a quick circle with the right stick. Iā€™ve noticed that that quick and little circle motion of the right stick reveals hidden oscillations because I thought I had a helluva tune, due to very tight and responsive manuevers in dynamic flight, until out of no where I tried the quick, right stick circle motion. Then she would lose total control instead of gracefully mimicking the motion. I believe that the drone should move like a hulahoop with that type of command i.e. a wave.

I will make those changes and report backā€¦ thank you!!!

No, not unless the frame suddenly twists at some point in time.
Itā€™s like those particular motors or props have a physical issue.

Ah I see. Well I did fly with the same props that I crashed with and I did see them hit the concrete a bit, but I visually inspected them and didnt see anything. I got a brand new pair I will try as well. Ive changed all the params and will do two hovers in the morningā€¦ one with these props and one with the new props to see if anything changes.

These parameters definitely made a difference! I didnā€™t see any oscillations, but I only flew three times because I forgot to charge my other batteries. In the air, the craft is stable and control was pretty tight, tbh. The hula-hoop motion didnā€™t confuse the controller and when there was no wind, her hover was like a loiter!

However, after arming, I gave about 15-20% throttle and noticed pretty strong trembling/shaking. Some of the motors started off with the heavy trembling/shaking right before take off. I would leave the throttle constant, at about 15-20%, when they started trembling until they settled down and they did. They eventually smoothed out and only then I gave more throttle and the drone immediately lifted off smoothly. It was different motors each time too. And the second time, the shaking did not last as long. Could it be my BLHeli params? I am thinking that maybe I should update the MOT_SPIN_ARM and MOT_SPIN_MIN params because I havenā€™t changed them to account for the motor and ESC swap.

The logs are a bit concerning thoughā€¦ idk why the COUTs arenā€™t aligning. Before the rebuild, they were overlapping, which is very confusing. Maybe the component placement has something to do with it? I shortened some wires and rearranged some components to try to distribute the weight evenly, but I only eyeballed it. Frick, I think that might bite me.

Anyways, I did two hovers, one with the old props and the other with a fresh pack. Can you identify which is which or should I just say?

hoverA and hoverB

BLHELI settings look OK.

HoverA - yaw is all over the place and cant be properly controlled, pitch and roll is slightly affected by that.

HoverB - yaw is tight, and correspondingly pitch and roll is much better - I doubt you will need any further tuning unless there are specific issues you can identify.

Harmonic notch filter is still working as planned.
There is only a tiny amount of difference between motor outputs, nothing to worry about.

EDIT:

I doubt you will need any further tuning unless there are specific issues you can identify.

I take that back - there is some more tuning that can be done to sort out attitude control around the neutral/level position.
Probably just run Autotune.

1 Like

Wow, this is so interesting. Iā€™m going to have to put these props under a microscope then because I really want to know the issue here lol. I cant spot anything on the prop that would deem it unusable. The crash mustā€™ve affected some very subtle aspect.

So I am re-reading the wiki and I noticed that I have been doing the accelerameter calibration all wrong. Thats what I get for merely skimming alongā€¦ I have been blindly pressing all three buttons on that page and I wonder if that has anything to do with the level position attitude control. I usually calibrate in all three axes, but then I also leave the craft level and keep going down the line, so I think that by pressing the Calibrate Level and then the Simple Accel Cal I am overwritting the important 3-axis calibration. I will fix it and try again.

What params/plots should I look for when tunning attitude control around the neutral/level position i.e. how did you spot the room for improvement?

Calibrate Level can be important for those amongst us that have done the whole accel calibration process with the flight controller ā€œon the benchā€ rather than fitted to the copter. Or if the whole calibration process was done in a ā€œnear enoughā€ fashion, as it normally is.
Also it can help if you notice a horizontal drift to one side when the copter should be hovering in one place (if RC inputs are not the issue).

You level the whole copter, across the top of the ā€œprop discā€, by packing under the landing gear. Just sitting the copter on the ground or some flat surface does not mean it is level.
Use a spirit level to get the diagonals level across tops of the motors, and also side to side and front to back. The idea is you are not levelling the flight controller, but levelling the part of the copter that does the actual flying (frame and motors).
THEN you hit the Calibrate Level button!

I do the accel calibration like everyone else does, moving the copter to the approximate positions by hand and eye-balling the angles.
Then I do the Calibrate Level in a much more accurate fashion.

I did some more tuning today and was wondering if you could take a look to see if this was addressed:

Yaw is pretty difficult to get right for me and idk why. I tried running autotune in the YawD (after regular Yaw) axis, but it turned out to be Roll (the autotune did roll twitches and even said that roll gains were saved when AUTOTUNE_AXIS = 8), is this correct? I am very confused by thatā€¦ does yaw normally not have a D term?

This is the hover log that resulted from todays tune. All in all, she feels good and tight except for yaw. I get a little over shoot in that axis.

You probably wont need to run the Yaw D autotune, or at least leave it until last. Just do the regular yaw autotune.

1 Like