LibrePilot Forum
Users => Vehicles - MultiRotors => Topic started by: trust on November 09, 2020, 08:39:05 pm
-
I've upgraded an existing eVTOL aircraft that was flying fine with an Atom FC. I upgraded to a mini REVO fc, a combined GPS/Mag DJI/Nav GPS, and am using the OPLINK Air to send telemetry back so I can watch whats happening. (The Oplink telemetry is very handy BTW - and I seem to be able to modify any config parms through it as well - nice!)
Aircraft is set for Attitude mode in roll and pitch and rate in yaw.
Everything starts fine - Mag & GPS are green. I start to hover and unit starts yawing in one direction or another. I compensate manually, but it gets more and more severe until I have to land. Then although aircraft is stationary, the orientation on the GCS is showing the aircraft is spinning around in yaw, and the roll angle is way off - like 20 degrees even though aircraft is level.
GPS now has a red X over it.
If I power cycle and wait again, it returns to normal.
What conditions would cause these faults?
-
Each motor spinning in the correct direction. Each Prop the correct type (CW or CCW). Matching props. Matching motors.
For first flights I suggest that you use Basic for your Atti-Est-Algo in Attitude->Settings. That will remove mag compass as possible cause. You will also need to remove all GPS flight modes from the FMS.
If that flies fine, then there are several things about mag compass that can cause it.
- motor power wires not twisted together
- need aux mag installed AND CONFIGURED correctly
- bad mag calibration
- aux mag orientation set wrong
- a setup issue was fixed in the wrong place
- etc
-
Motors not an issue - they were all functioning properly with the previous fc. And it does hover - just not stable in yaw or until the roll tilt appears.
I've rerun the mag, gyro, and board calibrations multiple times. The mag seems to hold steady at first - even in hover. Then it begins to drift and it it starts spinning.
And then even when the power to motors is off and aircraft is level and not moving - the mag coordinates spin.
I have mag set as aux only.
I'm suspicious of the power supply. I'll check that.
-
Well this is weird. I decided to just replace the regulator supplying the 5V power to the main systems with a DIY built 3A chip, plus bypass caps and big heat sink. It seems to work fine.
On the first flite test, I was able to get it up and hovering but again, it began to spin so I dropped it. I looked at the telemetry data and the GPS was X'ed out and the heading was spinning, and roll tilted - again. I unplugged power and rebooted aircraft.
Tried again - this time I was able to get it higher, with less spinning, but it again did it and also flipped over and crashed.
Yet oddly when I took aircraft back to the laptop and checked telemetry, GPS was fine and so was Mag! Everything looked normal! I chipped a prop so didn't try to fly again but now I'm wondering if there is something flaky in the GPS/mag device - every time it has landed up till now it went into this spinning mode.
Another thing I noticed is that if I move the GPS/mag - as in tilt it in pitch - so moves the horizon. I thought the mag was only used for heading. Is it used for ALL the attitude axis?
-
Is this with Basic or GPS_Navigation(INS13) (Attitude->Setting->AttiEstAlgo)?
INS13 bad mag affects all of stabilization (bank angle and compass heading). Basic does not use mag. That is why I suggest you fall back to test with Basic and not INS13.
-
Ok. Switched to basic mode to cut out the GPS/mag and changed out the VH mode to a stab mode. To my surprise, the same problem appeared. It would start out fine, and begin to hover. But then it would spin. Even after landing, with aircraft stationery and with no throttle on, the telemetry showed the aircraft was spinning!
So unless you can think of another reason why, I suspect the FC accelerometers are defective. I've ordered another one to test.
-
Defective sensors would do that, but there are other reasons that are more likely.
If you arm it (but leave motors stopped or even running, but at idle speed) and let it sit there for 5 minutes does GCS say it is spinning? But hover with small motions only and GCS says it is spinning?
Even after landing, with aircraft stationery and with no throttle on, the telemetry showed the aircraft was spinning!
This happens when if the aircraft spins constantly in flight. Was it doing that and you let it spin many times in flight? Where you were holding the stick to keep it from spinning constantly in one direction?
One time I did a test and hung an airplane fuselage from a ceiling fan at lowest speed. It flew around in a circle at 45 degree bank for several minutes this way. When I stopped it, the GCS said it was spinning.
Strong vibrations that are worse than a certain amount affect the sensors to make the sensors think the model is spinning when it is not.
It is dangerous, and you must decide if you can do it sately but on Output page and starting with sliders all the way to the left, I would carefully use Outputs->TestOutputs and the sliders (move sliders very slowly!!!) to test model, in hand (or bolted down to a table), with props on, each motor separately, to full power. Do this to look for a motor/prop that vibrates worse than the others.
I would check for bent motor shafts and carefully balance all props.
-
It is not constant spinning. When it first lifts off, for a few moments it's fine. Then it slowly starts spinning and rapidly increases. If I try to correct it, it will stop the spinning, but then it starts to spin in the opposite direction, picking up speed of rotation. I rarely let it go more than one turn before cutting throttle and letting it drop. From then on looking at the telemetry it says it is spinning at about a revolution every 2 seconds. If I power cycle it comes up fine.
This aircraft was working fine, was balanced and trimmed with an Atom FC and worked fine with it. when it is running with the new FC, motor spin up is smooth and no problems with the esc's or motors or props. Everything looks properly trimmed and elevon throws & gyro settings are same as in previous FC version.
It strikes me that the continuous spinning appears every time the aircraft comes down spinning and I throttle off. Ie if it was spinning when throttled off, it seems to think it is still spinning even though physically it is motionless.
I'm using attitude mode on pitch and roll and rate mode on yaw.
Enclosed is the UAV settings from the GPS mode with VH version. For the basic tests I turned those off. Yaw control is through elevons behind the motors, not conventional motor differential.
-
Did you change the input reversing after running the setup/transmitter wizard? It sounds like yaw (only) stabilization may be backwards and the way that happens is when you change input reversing when you should have changed output reversing.
With it armed, rotate it by hand in yaw direction. Does stabilization move the elevons in the direction that would slow the hand powered rotation down? It should. If it is wrong, then changing the yaw reversing in both input and output (to the opposite values of whatever they are) might fix it.
That still doesn't explain GCS saying it is spinning after landing unless it was spinning very very fast.
-
That was it! Damn I should have caught that - always check the direction of the compensation to make sure it's going the correct way. I reversed the yaw input then had to fiddle with the servo gain polarities but then it ran fine and hovered in basic mode.
I then switched it to GPS mode. It's getting pretty windy here so had to cut tests short. I was able to hover it in GPS INS13 mode briefly twice.
I did see some strange things though. On one reboot, it got to 7 satellites, all went green for a few moments, then GPS went to X and the yaw started spinning again! And I didn't move anything!
I fiddled with the wiring a bit. I'm wondering if the GPS/mag connections are iffy. I couldn't find any bad connections though - I have clear shrink wrap on the connections so I can see the solder joints. All looked fine.
I let it go up to 11 satellites on one test and it seemed more stable. Altitude is definitely more stable in INS13 mode.
What happens when GPS drops? IS there a way to fall back to basic compensation mode?
-
That was it! Damn I should have caught that - always check the direction of the compensation to make sure it's going the correct way. I reversed the yaw input then had to fiddle with the servo gain polarities but then it ran fine and hovered in basic mode.
I would have expected the yaw spin-up even in Basic mode. ;)
I did see some strange things though. On one reboot, it got to 7 satellites, all went green for a few moments, then GPS went to X and the yaw started spinning again! And I didn't move anything!
I fiddled with the wiring a bit. I'm wondering if the GPS/mag connections are iffy. I couldn't find any bad connections though - I have clear shrink wrap on the connections so I can see the solder joints. All looked fine.
I would suspect the tiny connectors at the FC.
I personally have experienced some cases where it does bad things when GPS signal gets very marginal. If GPS position jumps a long distance, then GPS position modes (even Position Hold) will try to fly there. I had a case where a big GPS change like that even caused Attitude mode to bank strongly into a tree (no damage).
Imagining what it would do if the GPS dropped out completely: It would probably think that it was always at that last good location. If you started PositionHold before the dropout, it would want to be at that location, but would usually be a little wrong. That slight difference would become a constant drift, possibly getting worse and worse as the PID winds up (because it thinks it is not moving).
I let it go up to 11 satellites on one test and it seemed more stable. Altitude is definitely more stable in INS13 mode.
Manual thrust mode should feel the same in Basic or INS13. If you are using VelocityRoam (you REALLY should try it if you haven't :) ) then it is using barometer and GPS to manage throttle for you. Center throttle stick (center +- 10% is all deadband = exactly the center) in AltitudeVario thrust mode or GPS flight mode such as VelocityRoam means "manage the throttle for me to keep at exactly this altitude". In VelocityRoam GPS mode (or AltitudeVario thrust mode for non-GPS flight modes), away from center means "keep it ascending or descending at exactly this speed" where speed is proportional to stick. Very nice!!!
What happens when GPS drops? IS there a way to fall back to basic compensation mode?
In a word, no. I have heard it discussed for 'next' but I don't think it is implemented.
I think that INS13-Indoor would be a better fallback, but maybe not if mag was also broken? I forget how INS13-Indoor relates to regular INS13.
I have a long personal list of LP things I would like coded/fixed and that is one of them. :)
All the modes should degrade so something less.
INS13/GPS landing mode should degrade to Basic/Attitude (with working flight controls) with baro controlling rate of descent. Not perfect since wind/drift will allow it to move sideways while landing. This degraded mode should be available for people who do not have a GPS.
-
I got a chance to test several times today. I also tried replacing (with a recalibration) the GPS/mag unit. The results were the same.
Aircraft takes off ok, and hovers fine for 5-10 seconds. Usually the failure mode is aircraft needs more and more pitch to hold stable. Then it suddenly flips over backwards.
The GPS flag has a red X over it. The flight display shows the aircraft slowly spinning, with a tilt - even though it's not moving. Letting it sit doesn't help. I have to power cycle it.
AFter a power cycle and time to acquire sats, it's ready to test again. I never get more than a few seconds hover time.
What conditions make the X appear?
Can I turn on a log to record whats happening?
-
The red X is supposed to mean that the GPS has a hardware failure, not just a loss of satellites.
The simple first guess is that vibration has made an intermittent connector come open.
Another guess, since this model has servos, is that the 5V power supply is not strong enough and servos moving fast and strong has caused a power sag that is first seen in the GPS.
-
I moved the GPS input port from the Flex port to the main port. Did a recalibration. It seemed a little better, more stable. I did some trim adjustments on hover mode pitch that helped a lot. I was able to hover for a while then tried switching to VH mode. It didn't hold very well, but it was gusty. Started from 9 sats - seems like its taking a long time EVERY time to find enough sats.
And every time it lands - even if its moderately softly, the GPS gets an X over it and then I have to reboot. I'm surprised it can't recover from these conditions - if it is a 5V transient it should recover quickly. Can it ever recover by itself or do you always have to power cycle?
I checked the power usage - no servos moving 0.35A, all servos moving about 0.8A. The regulator is good for 3A - I checked the heat sink and its warm only 35C and it can keep 3A up to 65C. Big caps too, so don't think it's the supply. Yes, servos can spike if they get jolted or jammed, but don't think this is happening. I've seen the X appear with no movement at all. It went from all green almost immediately to X once. That was before I moved the ports however.
I have the servo power coming from a separate set of leads - there is no 5V out of the FC that's very useful.
-
I did some trim adjustments on hover mode pitch that helped a lot. I was able to hover for a while then tried switching to VH mode. It didn't hold very well, but it was gusty.
(VH mode? :) ) By the way, you should never use your transmitter trims (or at least put them back to center where they were when you ran wizard) if you have more than one flight mode. For instance, trimming Attitude mode for level will cause VelocityRoam mode to move constantly. Attitude mode trimming should be done with GCS->Settings->Attitude->RotateVirtual... Rate mode and GPS modes should never need trimming.
Started from 9 sats - seems like its taking a long time EVERY time to find enough sats.
The default for "enough" sats is 7 (and PDOP < 3.5). A long time would be 10 minutes (GPS almanac completely downloads in 12 minutes). A short time would be 1-2 minutes. My experience. Some cheap GPS don't have a super cap or battery. Any that use a battery instead of super cap are more likely to have a broken battery. Some GPS units only get USA sats, and some get other country's versions of GPS too and thus get more sats quicker.
And every time it lands - even if its moderately softly, the GPS gets an X over it and then I have to reboot. I'm surprised it can't recover from these conditions - if it is a 5V transient it should recover quickly. Can it ever recover by itself or do you always have to power cycle?
DJI/Naza GPS should recover because they do not require initialization, so power off and on should simply work again. The default is that Ublox GPS gets inited, so power off and on requires init again. (But you can use GPSSettings->UbxAutoConfig=AutoBaudConfigureStoreAndDisable one time to permanently remember settings so that Ublox GPS also don't need initialization after power on.) One problem is that power transients might leave it locked up instead of rebooted. After you get a red X, you could try unplugging the GPS and plugging it back in, instead of unplugging / replugging the flight battery. is any of your FC mounting hardware metal or carbon that could touch something in a hard landing? A cracked trace in the FC or GPS could do it too.
I checked the power usage - no servos moving 0.35A, all servos moving about 0.8A. The regulator is good for 3A - I checked the heat sink and its warm only 35C and it can keep 3A up to 65C. Big caps too, so don't think it's the supply. Yes, servos can spike if they get jolted or jammed, but don't think this is happening. I've seen the X appear with no movement at all. It went from all green almost immediately to X once. That was before I moved the ports however.
I have the servo power coming from a separate set of leads - there is no 5V out of the FC that's very useful.
I would gently smack it and/or wiggle wires to see if I could recreate or narrow it down.
-
VH - velocity hold - a cross between position hold and velocity roam! Haha - no, actually its VR I've been testing.
The trim issue has to do with how much travel the elevons have to effect pitching forward or backward or effect yaw. I normally don't touch the trims on the xmtr when setting up - they stay centered. In this case after switching FCs the neutral position shifted enough to create a tendency to pitch backwards. Although the electronics can compensate for this somewhat, it reduces the aircraft's ability to deal with transients or excessive wind. Its easy enough to manually adjust the pushrods to fix this.
Another FC arrived so I'll test that also.
-
Rainy and windy here so haven't had a chance to flite test, but did some static testing outside to try to find connector faults. Partially cloudy skies.
Inside I could not get GPS lock.
I was able to get stable GPS of 7-9 sats, but note that PDOP shifted around from 3.2 to 4.5. Every time it went over 3.5 the GPS would go orange.
I did not have RC xmtr on, but figured that didn't matter for GPS lock issues. mag stayed steady green at all times
I banged on GPS, flight controller, plane components and wiggled connectors - could not get it to go GPS X at all - only occasionally orange.
If I put my hand over GPS I can get it to go orange. But not red X
Also tested for first time video xmtr - no issue with interference that I could see to the GPS or mag.
How does the FC go to red X GPS? Loss of signal from data stream? High PDOP? It'd be useful to know exact conditions that FC uses to determine this.
Power to the GPS comes from the FC, and the FC gets power from the rcvr, which has the 3A regulator driving it. Wire size from rcvr to FC is smallish, but plenty large enough for these small loads. The OPLINK also gets powered through FC. But the servos are all powered from the regulator directly, so they should not cause V drop to the GPS - not directly anyway.
-
Inside I could not get GPS lock.
That is normal and some GPSs are better than others for this. I actually use this as a test for which GPS units I buy more of and which ones I stay away from. Even the ones that don't work indoors after an hour will still work well enough outdoors that I don't bother changing them out for the better ones even though I have a stock of about 5 new and unused GPS units.
I was able to get stable GPS of 7-9 sats, but note that PDOP shifted around from 3.2 to 4.5. Every time it went over 3.5 the GPS would go orange.
...
If I put my hand over GPS I can get it to go orange. But not red X
The default GPS settings say that GPS is green when it has >= 7 satellites and PDOP is <= 3.5
Stabilization will only go green when all sensors are green.
It will not arm until stabilization is green.
Once stabilization goes green, it will stay green even if sensors turn yellow (orange).
So if sats goes less than 7 or PDOP goes more than 3.5 the GPS turns orange.
It generally is still flyable if some sensors are orange.
How does the FC go to red X GPS? Loss of signal from data stream? High PDOP? It'd be useful to know exact conditions that FC uses to determine this.
The red X is supposed to mean that the GPS has a hardware failure, not just a loss of satellites.
The red X is supposed to mean that the GPS has a hardware failure, not just a loss of satellites.
I wrote that code. Before that, you could not really know what the X meant. Now it means that FC is not receiving any readable packets from the GPS.
If satellite count is low or PDOP is high, you still get satellite update packets coming from GPS. Depending on quality of GPS lock, you will have green square, orange square, or red square. Red X means something is broken because we are not getting any data.
After you get a red X, you could try unplugging the GPS and plugging it back in, instead of unplugging / replugging the flight battery.
So recreate the issue and leave the flight battery plugged in and try unplugging the GPS and plugging it back in. If it is a DJI GPS (or you have done the previously mentioned "save settings into the GPS" for a Ublox GPS) after that the GPS should reboot and start sending again. If it stays red X then something is wrong inside the FC? If it starts working, then the GPS gets glitches that are related to hard landings and that sounds like intermittent connectors or cracked PCB trace.
-
I added a 10uf tantalum cap on the power leads going to the GPS and rebuilt the connector.
Now it seems to be able to hover more smoothly and I can land it without loosing GPS lock.
I tried briefly VR mode, which started out ok but then began to swing from side to side, so I turned off VR mode and landed.
I'll try it in a larger test area when I get a chance, but this is an improvement.
-
Just information: PositionHold mode and VelocityRoam mode are exactly the same when sticks are centered in VR mode. They use the same code in that case. Oscillation in VR means oscillation in PH.
There is an oscillation issue when using DJI/Naza GPS. It happens because this GPS smooths the data and thus delays it. I have made a patched 16.09 firmware that helps the issue.
firmware:
https://forum.librepilot.org/index.php?topic=3012.msg21154#msg21154
instructions:
https://forum.librepilot.org/index.php?topic=3012.msg21173#msg21173
-
Ok. Uploaded dirty firmware successfully. Will test outside later. Thanks.
FYI - I got in some new min OPOSD cards and tested one - these work properly and have the correct charset after uploading firmware and charset.
Bought from here:
https://www.ebay.com/itm/MinimOSD-Mini-OSD-Module-KV-Team-MOD-for-Racing-F3-CC3D-Naze32-Flight-Controller
Will system run properly if I don't have the ground station OPLINK in use? For many tests I can use the OSD to see GPS status.
-
Will system run properly if I don't have the ground station OPLINK in use? For many tests I can use the OSD to see GPS status.
Two areas to consider:
- Will it fly? I have flown many telemetry missions (a handful of these had OSD too) where the telemetry went out of range for short to long times and never had problems. I answer yes it will fly, but we have seen some oscillation related to OSD-telemetry packet rate and that makes me wonder a little bit. I should probably not mention this as it may make you worry, but I want to let you know.
- Will the OSD work? I have heard issues where the OSD stops updating if the OpLink telemetry goes out of range (or is switched off). This is because they are both telemetry streams and it seems that stopping one stream can stop them both. This may depend on whether you use MinimOSD or MinOPOSD protocol. I suggest that you test this before flying.
-
Got a chance to test system in a big field today. Lite 4-5mph winds.
Hovered nicely most of the time. But as soon as I switched to VR mode, it seemed to try to hold position, but would then drift downwind.
I could easily manually hold it in position (attitude mode on pitch and roll, rate on yaw). It would hold altitude and yaw angle well, but unless I tilted it into the wind it would drift. But it didn't take much control input to hold it in place - maybe 1/4 stick deflection in the direction of the wind. I recorded the OSD data and from that the tilt was never more than 10 degrees to hold it in place - but aircraft under VR wouldn't go that far. I see the VelocityRoamMaxRollPitch is 20 degrees, so well under that.
I do notice the TreatCustomCraft is set to FixedWing - how does that differ from VTOL?
This aircraft is really both- take-off is more like VTOL/quadcopter, but horizontal is more like a fixed wing, and there are modes that are a blend of both.
Trying to see what I can do with adjusting existing parameters.
-
Switch on transmitter. Power with flight battery. Plug in USB. Go to GCS Input page and look to see if your Flight Mode Switch actually changes into the modes that you think it does. (FMS and RC tabs) Sometimes Input Min / Max might need to be adjusted or transmitter switch stuff adjusted to get it to do what you want.
-
Pretty sure the flight modes are switching instantly and being recognized by FC.
1) Mode Shows up in OSD video when I flip switch settings
2) In VR mode I can't change throttle - STAB modes I can - if I try to change throttle in VR mode nothings happens. And I tried that in flite tests. Often just a reflex if its falling so very obvious when nothing happens. It's definitely getting in VR mode.
Is there a difference in how the FC processes if VTOL vs Fixedwing mode?
-
What type of model do you have set on Vehicle page? I would guess / suggest Multirotor. If you use Custom, then System -> Settings -> VtolPathFollowerSettings -> TreatCustomCraftAs should be VTOL.
If that is correct, then throttle should work, but it now controls vertical velocity and full throttle is 2 meters per second.
-
I have a LibrePilot quad with an authentic DJI brand GPS. I plugged in only USB so GPS was not powered. GPS health showed red X as expected. I added battery power to get the GPS to work. It did not work. Still red X (like you were seeing after a hard landing). Leaving battery power plugged in, I unplugged the GPS from the MainPort and plugged it back in and the GPS went to "red block" and eventually orange and finally green.
It looks like the GPS gets into a locked up state. Probably if there is voltage on the data pin(s?) but not on the power pin.
-
I switched the TreatCustomCraftAs to VTOL. I ran a test in a large field - got to moderate height, there was some wind so it was drifting some when I switched to VH mode. Heading was N, aircraft drift was west. It did a vert fast roll inverted. I switched it out of that mode back to attitude mode which rolled it back, but I lost so much altitude it crashed. Not too much damage, repaired.
I added 3 100uf 10V caps - one on the connector going to the GPS/mag unit, one on the 5V main power regulator, and one on the OPOSD PCB. This seems to have helped the stability some, and improved the noise on the OPOSD - though not completely gone when under power and hovering. I think I may need to add a cap on the 7V supply going to the camera, or run it off battery.
I ran a test in the street - some lite wind <5mph. After getting it in a hover and fairly still, I switched to VH mode. Aircraft pointed NW. It began to rock east-west fairly strongly - about 10-15 degrees roll. It did a couple oscillations - at least it seemed to be trying to stay in place. I switched back to attitude mode and landed it. I'll need a better day and a field test to see if the rocking decreases over time - at least in this short test it did not seem to be stopping or damped.
-
After getting it in a hover and fairly still, I switched to VR mode. Aircraft pointed NW. It began to rock east-west fairly strongly - about 10-15 degrees roll. It did a couple oscillations - at least it seemed to be trying to stay in place.
There are two oscillations, the fast one has a period of about 1/4 second. The slow one has a period of about 4 seconds. Since you say it did only a couple oscillations, you must be talking about the slow oscillation. The slow oscillation is the one that the special DJI GPS firmware is suppose to help. Were you running this "DJI fix firmware"? I can't say that it cures the problem completely, but it does help.
-
I seem to get both the fast and the slow oscillations, but at different times. Yes, I am using 1609-dirty firmware mod.
I'm PM sending you link to video clips showing two tests & description gives the times when VH mode was on. I can hear the fast oscillation as motor pulsing.
-
On the Vehicle page is your Vehicle a Custom or a FixedWing or a MultiRotor? I had assumed that you are using MultiRotor, or if using Custom that VtolPF->TreatCustomCraftAs is set to MultiRotor.
I would get it hovering well first. That probably means you should use MultiRotor. I think that your slow oscillations can be tuned out by then adjusting the VtolPFS PIDs. @Karla says to drastically reduce VtolPathFollowerSettings->HorizontalPosP
https://forum.librepilot.org/index.php?topic=3999.msg32548;topicseen#msg32548
He reduced it by like a factor of 7 or so (.25 to .035) and that sounds drastic to me, so I think that looking into the other PIDs there (VelocityRoamHorizontalVelPID for VR) is warranted.
-
I am using Custom aircraft type VTOL.
I have both yaw on the motors and elevons move to effect yaw. They effectively sum power in yaw.
I tried cutting the HorizontalPosP .25 value down to 0.035, and cut the VelocityRoamHorizontalVelPID Kp value in 1/2 to 6 m/s
I tried a test in poor conditions, bit windy and turbulent. But I had it hovering in place somewhat.
As soon as I flipped it to VR mode, it flipped over and crashed.
-
I'm going to try cutting the 4 VR Pid values to 20% of their default values. What is beta?
Do the VtolPathFollower settings (besides the ones above) affect Velocity Roam? Or are they only for waypoints?
-
Beta. Really stretching my memory here. :)
Executive summary: Don't bother to mess with it. It is only a stick feel / flight smoothness thing, not a stability thing (unless you need help keeping your stick motions smooth to avoid problems with a marginally stable aircraft ;) ).
There are several forms of PIDs. We use two for historical reasons shall I say... This form of PID has a setpoint weight called beta. Setpoint is like "my throttle stick is at 70%" vs. 60 or 80 which says it is calling for a multirotor climb at say 1 meter per second instead of 0 or 2 (yes GPS mode throttle stick from 40 to 60 is zero, for the deadband).
Beta is usually less than 1.0 and is a multiplicative factor, so 1.0 is basically 100%
If it is set to zero, then when you change the climb rate suddenly it ignores your P setting and only responds slowly, as the I term determines over time that the climb rate is wrong and winds up to adjust it. Note though that if the environment changes the climb rate (imagine a sudden downdraft) that it responds with both the P and I terms. As you can see with it almost 1.0, it has very little of this effect.
Now I will try to imagine a use for it. I have VtolPFS velocities set above stock and I notice that when I try to start slowly from a fixed hover, that it jumps into forward flight fairly hard. If I adjusted my HorizontalVel PID Beta to a lower value, I imagine it would be smoother.
-
Under VtolPathFollowerSettings are HorizontalVelMax VerticalVelMax CourseFeedForward HorizontalPosP VerticalPosP then HorizontalVelPID - also with 4 parms Kp Ki Kd and Beta.
Do these affect VR mode or are the only related to Path Follow mode?
-
My guess without combing the code is that the generic PIDs affect any generic GPS flight mode. The ones with a GPS flight mode as part of their name are specific to that flight mode. If I were going to be playing with PIDs anyway, I would find it just as easy to flight test for as to grok from the code. Just cut any P in half to see if that PID is active in that flight mode.
-
I turned the VR mode PID values to 20% of their defaults, left Beta alone.
Tested in light winds - climbed to 30 feet, hovered, switched to VR mode. It began to rock side to side (vehicle facing south, east west roll, lite wind <4 from north), did about 3 full cycles with amplitude increasing to 20 degrees of roll (from saved video OSD data), before I stopped it.
After landing, I switched batteries and tried again. For some reason the mag would not allow arming - mag alarm on the OSD. Unplugged and replugged twice, GPS was working fine 13-15 sats - so I know mag was getting power. Took it home, tried again in the house later, it worked fine. As we say, more mystery meat.