[JustAPilot]

Hi there,
I have noticed the automatic configuration is different than the manual configuration (M8N Gps). The manual configuration can be used with the Revo I suppose? The manual configuration activates 4 messages whereas the automatic one activates only 1 message (which is not one of the 4 of the manual one).
Which one is better(more accurate), auto(with 1 message) or manual(with 4 messages)?
Thanks in advance for your feedback.

[TheOtherCliff]

The single and multi message formats are equivalent.  One of the multi messages is a timestamp for the other messages, but there is an ID field in each multi message that allows you to match the several messages into a single chunk of data that was taken at the same time.

CC3D only knows how to understand the multi message format.  Older GPS units only know how to send the multi message format.  The original OP code was written for the multi message format.

[JustAPilot]

Hi TheOtherCliff,

Thanks for your feedback.
Maybe it's essential to let users know what the auto config sets, so they know it is set correctly, if they check. I did not expect it to be different than the manual config. I thought my GPS was not remembering the manual settings I saved. But it was the auto config writing a totally different setting than the manual one.
Thanks for your time. I'll be having more questions
Regards,
JAP

[TheOtherCliff]

Revo automatic GPS configuration detects whether the (Ublox) GPS is old style (Neo6- only knows multi message format) or new style (Neo7+ knows both formats).  The default Revo settings tells the GPS to temporarily set it's configuration to either the multi message set or the single message set (depending on GPS version).  FYI: There are other messages even in what I've called the "single message" format here.

So it does not change the GPS's internal configuration permanently.  This means that with one GPS you can fly different firmwares that need different protocols.  Revo sets it to what it needs temporarily on each boot up and so it has it's different, permanent configuration when you boot it when it is attached to different firmware that needs the permanent configuration.

There are other Revo settings, for instance, you can have the Revo change the GPS's configuration and make it permanent in the GPS.  This is helpful if you have a Neo6 GPS that you want to use with CC3D.  Connect it to Revo this way one time and it will work on your CC3D (CC3D doesn't have GPS auto-config) from then on.

[JustAPilot]

Wow,..you really know a lot about this and I'm glad I've kept my Revo with LibrePilot. I have two questions. If need to ask these somewhere else please let me know.

1. Is there a way to make the copter fly nose in when in RTB mode? It would be awesome if it flew nose in and when it stops to start descending (ReturnToBaseNextCommand) it rotates and points in the same orientation as when it took off, and then starts descending and lands.

2. When in VelocityRoam mode and I do a bank or pitch and let go of the stick (instead of gently helping the stick to it center position) the copter levels itself too quickly and oscillates 4 to 5 times before it levels, like a crazy bee. It only happens when the stick goes quickly to center. The oscillation is not gentle, it uses quick revs while doing this. When do I need to adjust this? I cannot eliminate it from the general PIDs settings. I only fly in three modes: Attitude, VelocityRoam, RTB.

I'm almost done tuning everything neatly. Thanks in advance for your time and response.

[TheOtherCliff]

I wrote some of the GPS code. 

Sounds like you want it to fly RTB like a DJI/Naza does RTH. 

System -> Settings -> VtolPathFollowerSettings
has YawControl, which has these options:
Manual,Tailin,MovementDirection,PathDirection,POI
defaultvalue=Manual

As you can see there is a Tail-In but not a Nose-In.  PathDirection is close to Nose-In though.  And it does not rotate to takeoff heading for landing at all.

You should test these carefully some of them act a bit crazy when the quad is hovering motionless (if you have a fast yaw configured).  For instance, with MovementDirection yaw jumps around randomly when hovering motionless.  The small motions are random this way or that and so it yaws this way or that.  Manual is always safe though.

Oscillations during PH are known to happen with authentic DJI/Naza GPSs.  Most (some?) DJI clones don't have that issue.  If you are using a DJI/Naza GPS I suggest that you try the firmware here and see if that helps.
https://forum.librepilot.org/index.php?topic=3012.msg21154#msg21154

[JustAPilot]

Ah,..so that's why
I will only try the PathDirection one. This means that when I activate RTB (with PathDirection selected) all stick input is disabled? It would be great if I could override the Yaw with stick input while it's moving towards Base and when I let go of the yaw stick, it smoothly rotates back to its PathDirection.

The GPS I have is a uBlox M8N. The problem is not related to the GPS I think. I managed to tame that jerky correction movement by lowering the Responsiveness (Attitude) to 30. The whole time I was tweaking the Rate (Inner loop) PIDs and didn't notice any difference  . I don't fly Rate at all, so I guess I should not tweak anything related to Rate.

[TheOtherCliff]

In waypoint/RTB I recall that yaw is not user controllable except when using the manual yaw option.  You suggest an attitude mode for yaw.  This is easily doable, but would require tuning or at least checking the attitude yaw PID.  I suggest using manual for yaw.  If you can see (FPV) enough to turn and look at something, you can turn it back or just leave it there.  It flies correctly either way.

At one time, zero throttle would stop the motors, but I would test it.  I forget if the current code does this.

Rate mode is inner loop.  Rate mode only uses inner loop.  Attitude mode is outer loop which uses inner loop as well as outer loop.  So if you use Attitude mode, both your inner and outer loops need to be tuned acceptably well.  The easy way to get both inner and outer tuned well (works for most quads but not all) is to use AutoTune.
https://librepilot.atlassian.net/wiki/display/LPDOC/AutoTune

[JustAPilot]

About the inner/outer PID loops. Will this be a good approach to tune both inner and outer manually?
1. fly in rate mode and tune only rate PIDs. When copter flies satisfactory then proceed to step 2.
2. fly in attitude mode and tune only attitude PIDs.
Done. I should have both inner/outer well tuned.

I've tested autotune before and I find it makes the copter too snappy for my (sight seeing) purposes. Maybe I should auto tune it and then tame it to my liking. (it's not a race quad)

[TheOtherCliff]

You manual tuning method should work OK ... but

AutoTune has a SmoothQuick slider that adjusts PIDs to be smoother or quicker ... but

Many people assume that they should reduce the PIDs in order to slow the response down.  That isn't the correct way to slow response down.  The PIDs should be as high as possible (such as produced by AutoTune) and be adjusted towards smooth only enough to reduce jitter because you want smooth video.

Reducing PIDs just to reduce response makes it handle worse in some ways that you really don't want.  For instance if you descend vertically you need those PIDs high to avoid the problem of instability when falling in your own downwash.

The right way to reduce response it to adjust Responsiveness on the Stabilization page (Basic or Advanced tab).

You should try AutoTune again and reduce Responsiveness on the Stabilization page. 

[JustAPilot]

That's exactly what I thought at the field today. You don't degrade the gas/oxygen mix on the carburetor of car to make it more docile, you adjust how the pedal reacts to the carburetor/fuel injector.
I'll try that autotune again and adjust the responsiveness.

I did try the PathDirection in RTB today. It worked but even though I don't have high Yaw deg/s it starts with an excessive force for a fraction of a second. The actual rotation speed is moderate, this is fine,..but how it starts this turning is with too much force. Scary.  How to tame this transition?
When I am in PH and I switch to RTB, the transition is also a bit too sudden. It's not like a human would do it with the sticks. It's too "binary".

I have the exact same copter+hardware but with Betaflight(Omnibus F4) and ESCs (BLHeli) set to Damped Light. No issues.
The exact same copter but with LibrePilot(16.09 on Revo mini) when I set the ESCs to Damped Light, the motors suddenly start making a scary noise,..as if someone is drilling with a hammer drill. So I have to set the ESCs to Low (instead of damped light). This buzzing/drilling starts randomly while flying, most times during switch to PH. Any hints?

You've been and are being very helpful and I thank you for this.

[TheOtherCliff]

I did try the PathDirection in RTB today. It worked but even though I don't have high Yaw deg/s it starts with an excessive force for a fraction of a second. The actual rotation speed is moderate, this is fine,..but how it starts this turning is with too much force. Scary.  How to tame this transition?
When I am in PH and I switch to RTB, the transition is also a bit too sudden. It's not like a human would do it with the sticks. It's too "binary".

I'm going to make a guess as to the most correct way to adjust that.  I think that this is actually running yaw in attitude mode, which is uncommon so there is no place to adjust it in the GUI.  (Assuming you are using bank1) Reduce the System page StabilizationSettingsBank1 -> YawPI -> P.  Cut it in half for a test.

... but with LibrePilot(16.09 on Revo mini) when I set the ESCs to Damped Light, the motors suddenly start making a scary noise,..as if someone is drilling with a hammer drill. So I have to set the ESCs to Low (instead of damped light). This buzzing/drilling starts randomly while flying, most times during switch to PH. Any hints?

I liken the sound to throwing a medium sized stick into the prop at about half power.    Are you using the same ESC protocol in both cases (LP and Betaflight) (say OneShot125)?  Can you test with Output page "Test Outputs" (props off) at full throttle to make sure it can go to full throttle without stuttering?  If OK, I would make a second test with it tied down to a wooden deck with props on (please be very very careful), and also using the Output page.

This is caused by the ESC loosing sync with the motor (especially when the ESC is commanded to change the motor speed a lot in a short time).  This can be caused by props that are too big but more often are caused by old firmware that has this issue.

Bad ESC firmware?  Props too big?  Signal protocol isn't matched well (between ESC and FC)?  Or maybe you have adjusted some uncommon settings in the ESC firmware?  I would start by updating it to the latest ESC firmware, checking prop size, and using stock ESC settings for your selected protocol.

[JustAPilot]

About the ESC.. it's an ESC manufactured in end 2016. I have flashed it with the latest BLHeli firmware. Everything is in the latest Released version.

The way I tested both Quads (LibrePilot on Revo and Betaflight on Omnibus F4) is:  By the way my non-FPV quad is a 3D quad with motor reversing.
fasten quad to heavy platform.
put 1 prop on a motor and connect its ESC to servo tester. The ESC has bidirectional activated in BLHeli and motors with bi-directional props.
power up and start turning gently on the servo tester to see if the motor spins up without too much jitter and then I reverse the direction also easy. I repeat this and gradually increasing the amount of power, going both directions and with even faster transitions.
On both quads all motors+escs work perfectly (with servo tester as throttle signal provider). So I'm confident the motor + esc is working flawlessly.
On the Fpv quad I disable bidirectional after testing. 

But on the Omnibus there is no desync. On the fpv quad I have to disable Damped Light otherwise there is this buzzing/drilling sound.

I'm asking myself if LP is pushing to much confusing throttle commands or if the throttle signal/command is different than on Betaflight.
Adjusting timing of motor to try to fix this is masking the rootcause.

[JustAPilot]

Latest Update:
I just tested on the bench. Damped Light=ON
Quickly raising the throttle via GSC causes that desync issue.
Using servo Tester and quickly raising the throttle there is No issue, no desync.
In LP the motors are set to onshot125 protocol

[TheOtherCliff]

servo tester probably has smoothed response

servo tester uses PWM width pulses

it could be related to oneshot125, maybe try pwmsync