[trust]

Recently I updated my Sk450 quad system equipped with a tiltable gopro to add the mini OPOSD, and updated some of the telemetry update times from 1000ms to 250ms. Oddly, this seems to have improved one of the problem areas I've had with velocity hold mode, where it tended to oscillate over a second or so interval which would increase to where I would need to flip back to normal stabilized mode.
Yet it still seems to vibrate or oscillate - now at a much higher frequency but over a smaller angle.
I wouldn't think the telemetry update times should have anything to do with the stability.
Am I missing something?
To see what I mean, look at 00:18 to 00:50 in this video. You can easily tell when I've switched modes - it starts vibrating. You can hear it in the motors too.

For reference also enclosed are the uav settings

[TheOtherCliff]

Several things come to mind:
- When you add a camera or actually any time you change weight or power (like different battery or different props) you need to retune the PIDs.  But in particular, any time you make it heavier, less powerful, or slower to respond it is closer to oscillation.  If you tune it when it is in it's lowest performance configuration (e.g. heaviest weight, least powerful props / battery) it won't oscillate if you go to higher performance configuration.  The slight down side with this is that it will be a little less "locked in" since you are flying it with detuned PIDs.  You may not even notice it.
- If you are using a DJI / Naza GPS, there is a known issue because these run in a mode that slightly delays the GPS data and that causes oscillation.  I wrote some firmware with a partial workaround in it that most people say works better.  I have had this "faster oscillation visible inside a slower oscillation" that I seem to see in your video.
- ALL your power wire pairs must be twisted together or it might do this.  Battery to connector, connector to PDB, PDB to ESC, ESC to motor.  Also, try to route these wires away from Revo board.

[trust]

I tuned this in its heaviest configuration.
Are you suggesting detuning it to try to reduce the faster oscillations appearing in GPS mode?
yes, it already has the firmware update you indicated as it uses the GPS that seems to have the delay issue.
Can you recommend a GPS unit that doesn't have this delay issue?
It seems very stable when NOT in a GPS guided mode - so it seems to me other potential issues such as PID tuning or power cables should not be a factor, as it is stable otherwise, and the GPS is working fine. I have it separated by a 8" from everything (mounted on a balsa mast above the unit), and the mag and GPS seems to be stable even when motors are running.
What are the minimum times I could set for telemetry? Can I go down to 0 from the 250ms it's at now?

[TheOtherCliff]

I tuned this in its heaviest configuration.
Are you suggesting detuning it to try to reduce the faster oscillations appearing in GPS mode?

If you tuned it in it's heaviest configuration, it should not need different tuning or a further reduction in PID.

Can you recommend a GPS unit that doesn't have this delay issue?

DJI is the only one that has this issue.  LibrePilot should be able to tune this out, but I was not able to in my testing, that's why I wrote and posted the changed DJI GPS firmware.  Any other GPS with mag needs two ports, one for GPS and the other for mag.  That is why DJI is good, only one port.

It seems very stable when NOT in a GPS guided mode - so it seems to me other potential issues such as PID tuning or power cables should not be a factor, as it is stable otherwise, and the GPS is working fine. I have it separated by a 8" from everything (mounted on a balsa mast above the unit), and the mag and GPS seems to be stable even when motors are running.

I would still carefully twist the power cables.

What are the minimum times I could set for telemetry? Can I go down to 0 from the 250ms it's at now?

- Not to zero.  250 is 4 times a second (which looks like the faster oscillation???).  100 is 10 times a second.  0 is infinity times a second.    You may try raising (/lowering) the telemetry baud/data rate too.
- Your finding that telemetry rate can affect it is very interesting.
- I am very interested in hearing what your testing shows about this.
- I have a test to request and I assume that you are using normal RC for control (not OpLink control):  Turn telemetry completely off and see if that changes the problem.

Note to self and other devs: Is this possibly high priority telemetry timing upsetting the high priority stabilization task (those delta T's should be real values, not forced to 2ms)?  I tried tuning this out with Stab PIDs and VTOLPF PIDs, but was unsuccessful.

[trust]

I change the 250ms values down to 100ms. Ran a quick test out in the street - bit windy and turbulent.
But the fast oscillation seems to be gone completely.
It did drift a bit with the wind. But as the number of satellites increased - at 14 it held fairly solidly in place.
Not a very good test but having the oscillation gone is a big step.
If I add the OPLINK telemetry, so I can send waypoints through the GCS, is there anything else I need to set on these telemetry timing values?
I've tested out the OPLINK on another miniREVO so I have it working already.

[TheOtherCliff]

I have a test that I would like to request you to do.  It may help me figure this oscillation issue out.  I am guessing that your OpLink is completely disabled in the setup.  Let me know if it is not.  I request that you set the OSD telemetry back to 250ms, test to make sure that the oscillation problem comes back (it should), then (leaving it at 250) disable the OSD telemetry so that Revo does not send to OSD, and retest.  Disable OSD telemetry on the Hardware page.

It did drift a bit with the wind. But as the number of satellites increased - at 14 it held fairly solidly in place.

If PIDs are set well, it shouldn't drift more than maybe a meter or so in gusty wind.  In fairly steady wind, it should come back if it drifts a little.  If it doesn't, it may be just GPS location drift, especially if it is adding or removing satellites the GPS location will change.  You can see that by watching the GCS map with it sitting on the ground so you know it isn't moving.

There is GPS data that it receives called the almanac which lists which satellites it should be able to "see" and how to tune them in.  The first flight of the day may take up to 12 minutes after GPS fix to download the almanac.  Most GPS units have a super cap that acts like a rechargeable battery to save this for 6 hours or so.  Best practice has first flight of the day sitting powered up on the ground for 12 minutes before the first flight.  This does not waste a lot of battery because flight motors are not running.  Later flights that day probably only need 2 minutes or such because it already has the almanac.

If I add the OPLINK telemetry, so I can send waypoints through the GCS, is there anything else I need to set on these telemetry timing values?

You know the most about these timing values and how they affect your oscillation.  Telemetry really is nice to use for sending waypoints and for seeing where the quad is by watching the GCS map.  A real treat is using the OsgEarth PFD which actually gives you an artificial FPV view which has real hills, but you can see that trees and houses are just painted on the ground or hills if you are close to the ground so do not use this for obstacle avoidance.  You can actually send waypoints with a USB cable if you want to.

If your GCS has this feature built in, you can enable it on Flight Data page by:
- Window -> Edit Gadgets Mode
- PFD : PFD (ArcGis) (or PFD (ReadyMap))



Dev note:  Is it a serial issue where the serial interrupt is taking too much time to completely fill the hardware transmit queue?  Is it an issue with scheduling the OSD telemetry?

[trust]

Ok. Performed tests.
Changed three value - ManualControlSettings Meta Telemetry update period - change from 100 to 250 ms
Also same for GPSPositionSensor GPSVelocitySensor
Test flew - the oscillation was definitely back.
Then, disabled telemetry on Main port.
Oscillation gone
Changed the 3 parameters back to 100ms, enabled telemetry
Oscillation gone

[trust]

FYI - I notice these Meta values are not reloaded from a UAV file. It would be nice to have some mode which saves ALL of the parameters, so they can be reloaded and saved.

[TheOtherCliff]

Your test (turning off OSD data stream) has confirmed that we are on to something for that.  There have been these small oscillation issues for literally years.  Normal tweaks (PID changes) don't help.

Yeah, long ago I ran across that the metadata is not saved.  I mentioned that there is no way to reset it to default.  The answer I got was a good work around.  Save your settings to a UAV file.  Erase settings.  Restore UAV file.  That resets all metadata to default.

[trust]

Glad to help. You've certainly helped me a lot over the last few years.
I noticed that when I update the parameters using the upload/save button, the meta values will get saved in the current version of the GCS as well as uploaded to the FC.
I had to upload and save for each change, or I wasn't sure it was changed.
They're also not downloaded out of the FC automatically when you first plug in either. So one can't really tell what values are in the FC.
Unless you follow the procedure you mentioned.

[TheOtherCliff]

They (metadata) are also not downloaded out of the FC automatically when you first plug in either. So one can't really tell what values are in the FC.

Hmmm.  From what I recall they should be downloaded from FC almost immediately after plugging in the USB.  OpLink telemetry can add a second or so to that.

Note that you must press the Red up arrow button for them to be saved.  The green button uploads, but not permanently.

[trust]

Well, it's always good to run more tests. I did a more thorough test with the values set to 100ms.
The oscillation is still there, although seems somewhat smaller in amplitude.
This video is from the ground based video recorder, so it includes the telemetry. You can readily see the mode in the lower center.
Question on RTB - does the algorithm first move to location over base at same altitude? Does it ever descend? It did not seem to do that in these tests. I have the RTB set altitude as 50m.

[TheOtherCliff]

Well, it's always good to run more tests. I did a more thorough test with the values set to 100ms.
The oscillation is still there, although seems somewhat smaller in amplitude.

I was guessing that.  You just change the frequency of the oscillation and it doesn't have as much time to move from one side to the other.

Question on RTB - does the algorithm first move to location over base at same altitude?

Yes, at MINIMUM of current altitude or your configured 50m, so it will climb to 50m if needed.

Does it ever descend? It did not seem to do that in these tests. I have the RTB set altitude as 50m.

There is a setting for that (ReturnToBaseNextCommand).  Hold or Land, and the default is Hold as I recall.

[TheOtherCliff]

In the video in the first post at time 0:18 to 0:30 when you see the small oscillations, I see a larger slow oscillation left to right.  Can you tell me, was model facing north then (or maybe south)?  And the slow oscillation was east-west?

Another question: Was your quad tuned using AutoTune?

And finally: Which telemetry objects did you change from 250ms to 100ms?

Thanks!

[trust]

Yes, quad is facing north. And yes on both oscillations.
No, quad was not tuned with autotune.
I changed the 3 items meta data items listed on the wiki page -
ManualControlCommand meta telemetry data
GPSVelocitySensor
GPSPositionSensor