I have been trying a few things to find a solution that helps everybody. The only thing that did make quite a big difference was to put ferrite rings around the servo cables (both sets). That cut down the jitter by about 70% but a small amount is still there. I also swopped out the tilt servo for a Savox SH-1290MG to see what would happen. (No Change). A single spring pulls the camera in roll and pitch. this also helps a lot. Interestingly when the spring was pulling the camera up at the front on the tilt axis it caused a bad roll jitter but when it was pulling down that went away, leaving just a slight tilt issue. The noise is coming from a single direction of rotation it would seem. This could be a multiple ground issue.
Photohigher skyline rsgs
- Thread starter 1001 Copters
- Start date
Aviator
Member
Yes what you say about deadband is correct, I haven`t tried just with servos? I will see if it is not too difficult? ( Have all my cables taped up..)
With the tilt servo working in slew mode the servo deadband will be there at all positions. it has to have some deadband or the servo would just oscillate back and forth and be impossible to park. The mechanical backlash has a bearing on the IMU resolution which is not the issue at this stage. It is related to the way in which the IMU mimics the pots. resistance. The standard servo pot. set up has three wires and this system only uses two of them. The signal wire from the IMU has a lot of noise which is improved by the Ferrite rings but there is something else causing this.
Last edited by a moderator:
I'd go "belt & braces" on this: twist the wires, >5 turns through a ferrite and a cap across the +/- connections inside the servo. The suggestion here is that the RSGS is radiating some nasty EMI and the servos are picking it up.
I've seen this issue with 7990's - their magnetic encoder is super-sensitive, reporting every tiny change to the controller (i.e. a similar situation to the RSGS reporting tiny changes) and causing this oscillation. If you put another spring pulling the other way it should kill the jitter in both directions (though you're still likely to get a little jolt as it reverses direction). A rotary damper opposite the servo should work, too.
I'm more convinced than ever that this is an algorithm issue (plus some nasty EMI).
Aviator
Member
Is anyone having success with other stabilisers? I need a solution and fast... If that means trying to get my money back on the Skyline and buying another stabiliser then so be it.. I have work coming up and cant afford it to look shoddy, and neither can anyone else i dont expect? My reputation relies on my flying skill and the quality of images, if either one of them is below par it doesn`t bode well for me?
A modified servo working with a locked pot, yes - but that's not happening here: the RSGS is the servo's pot. No?
If that was the case then the spring wouldn't alter the behaviour
Two wires should be okay here - the third connection to the built-in pot would be tied to ground and since the RSGS is supplying a ground to the servo then it should be redundant. To test if this is causing any of the EMI issues it should be simple to add the third wire (and twist it with the other two) and connect it to ground at the RSGS.
EDIT: my last suggestion: better check with a multimeter first to verify what the existing two-wire setup is carrying!
Last edited by a moderator:
Mmmm.... interesting thought - if the jitter is varying cyclically (when the system is at rest) then that further indicates an algorithm issue. In a PID-controlled system, a decaying oscillation suggests that the "I" is set too high (relative to the "P"). Does varying the gain in the setup tool (which would be equivalent to the "P" gain) alter the timing of the oscillation? i.e. does it make the jitter last longer/shorter or change the gap between its little "fits"?
The wind has an effect on all gimbals even a Zen, it is a question of how much.
This issue is not related to that in any way. Only two things can alter the servos position. One is the PWM input and the other is the resistance at the potentiometer. To have jitter one or both of these values must have some electrical noise that effects the way in which the servos amplifier board resolves those values.
Multiple grounds can be to blame if other devices are using the same path.
What is clear is that the roll PMW input has an effect on the tilt and also the tilt PWM input has an effect on the roll. Just disconnect that single wire on either and the problem goes away. It is also a time based effect, if you leave the mount for several minutes with one PWM disconnected then when you reconnect it will initially be OK for a few mins but then it starts to build up. Like an accumulation of errors.
Last edited by a moderator:
No difference that I could measure. But then I can't go past 300 or it will jump off my table...
I've dug a bit deeper, looking again at the RSGS manual.
First off, the instructions for modifying a servo are disturbingly vague about how to do it and how to verify that you've got it right. I suspect that some users will have it wired wrong. What is clear, though, is that two wires is fine - they are using "ground and wiper", so what they feed to the servo is what the servo would expect to see - a voltage varying from 0-1V (or whatever). There can't be any ground issue there - but that voltage could be causing radiated EMI, though I doubt that it would be strong enough to be causing these kinds of issues. Nevertheless, the first thing I'd do myself would be to modify the supplied harness to extract the pins from the one end or the other, split all the paralleled wires, twist them in their respective sets and reassemble.
In the original software the Gains tab gave access to "Position Gain" and "Velocity Gain" but the new version (1.6) has only "Position Gain". What we don't know is whether they just removed access to the "Velocity Gain" (i.e. its value is hard-coded in the firmware) or they re-worked the algorithm to combine it into a new parameter (whilst still calling it "Position Gain"). Unfortunately "Velocity Gain" is probably a misapplied term here - I suspect this is the Integral (I) gain and what they call "Position Gain" is the Proportional (P) gain. It's likely the processor is running "PI" controller, i.e. no "D" - makes sense.
Forgive me for not reading back over this entire thread to check, but (using the latest firmware/software) can you stop the jitter by dialling down the gain? On a "P" only controller, the classical method of tuning would be to increase P until oscillation occurs then reduce P to half that value. On a PI controller, you'd now increase I to correct the steady-state error (the difference between the target setpoint and the achieved setpoint).
I see, too, on the 1.6 software that there is a Monitor tab - can someone confirm if this works and what is it giving feedback on? If it's active, it might give some clues as to what is varying when the system is oscillating.
The "cross talk" between Roll and Pitch channels could indicate a "bug" in the firmware. It's entirely possible that the roll and pitch channels are in some way connected within the mathematics - the RSGS is mounted on the pitch axis, so it must be deriving discrete values for the pitch and roll attitude from a compound movement. When you disconnect one of the axes from the RSGS it will know that there's an open connection on that axis, i.e. the inputs to the algorithm may change in such a way that the system instability (oscillation) will not occur (for the current P gain). Does this happen for any P gain setting? Most interesting, though, is your revelation that the instability will re-occur without any disturbing input once you reconnect the second channel. This suggests that it's an Integral (I) term issue in the algorithm - the Integral is the sum of errors over time: if the algorithm is seeing system noise in a steady-state system (and backlash in an active system) as valid errors then they will, indeed, accumulate over time and force the servo to react. Again, it would be interesting to see if different P gains affect the time-to-onset of this oscillation and/or it's frequency/magnitude.
Just fishing around here, in the hope that something I say may trigger a Eureka moment with somebody who a) has one of thee things in front of them and b) understands more about system controllers than I do.
First off, the instructions for modifying a servo are disturbingly vague about how to do it and how to verify that you've got it right. I suspect that some users will have it wired wrong. What is clear, though, is that two wires is fine - they are using "ground and wiper", so what they feed to the servo is what the servo would expect to see - a voltage varying from 0-1V (or whatever). There can't be any ground issue there - but that voltage could be causing radiated EMI, though I doubt that it would be strong enough to be causing these kinds of issues. Nevertheless, the first thing I'd do myself would be to modify the supplied harness to extract the pins from the one end or the other, split all the paralleled wires, twist them in their respective sets and reassemble.
In the original software the Gains tab gave access to "Position Gain" and "Velocity Gain" but the new version (1.6) has only "Position Gain". What we don't know is whether they just removed access to the "Velocity Gain" (i.e. its value is hard-coded in the firmware) or they re-worked the algorithm to combine it into a new parameter (whilst still calling it "Position Gain"). Unfortunately "Velocity Gain" is probably a misapplied term here - I suspect this is the Integral (I) gain and what they call "Position Gain" is the Proportional (P) gain. It's likely the processor is running "PI" controller, i.e. no "D" - makes sense.
Forgive me for not reading back over this entire thread to check, but (using the latest firmware/software) can you stop the jitter by dialling down the gain? On a "P" only controller, the classical method of tuning would be to increase P until oscillation occurs then reduce P to half that value. On a PI controller, you'd now increase I to correct the steady-state error (the difference between the target setpoint and the achieved setpoint).
I see, too, on the 1.6 software that there is a Monitor tab - can someone confirm if this works and what is it giving feedback on? If it's active, it might give some clues as to what is varying when the system is oscillating.
The "cross talk" between Roll and Pitch channels could indicate a "bug" in the firmware. It's entirely possible that the roll and pitch channels are in some way connected within the mathematics - the RSGS is mounted on the pitch axis, so it must be deriving discrete values for the pitch and roll attitude from a compound movement. When you disconnect one of the axes from the RSGS it will know that there's an open connection on that axis, i.e. the inputs to the algorithm may change in such a way that the system instability (oscillation) will not occur (for the current P gain). Does this happen for any P gain setting? Most interesting, though, is your revelation that the instability will re-occur without any disturbing input once you reconnect the second channel. This suggests that it's an Integral (I) term issue in the algorithm - the Integral is the sum of errors over time: if the algorithm is seeing system noise in a steady-state system (and backlash in an active system) as valid errors then they will, indeed, accumulate over time and force the servo to react. Again, it would be interesting to see if different P gains affect the time-to-onset of this oscillation and/or it's frequency/magnitude.
Just fishing around here, in the hope that something I say may trigger a Eureka moment with somebody who a) has one of thee things in front of them and b) understands more about system controllers than I do.
"Forgive me for not reading back over this entire thread to check, but (using the latest firmware/software) can you stop the jitter by dialling down the gain? On a "P" only controller, the classical method of tuning would be to increase P until oscillation occurs then reduce P to half that value. On a PI controller, you'd now increase I to correct the steady-state error (the difference between the target setpoint and the achieved setpoint)."
No, I can't. I've set gains to 20 and jitter is still present
"I see, too, on the 1.6 software that there is a Monitor tab - can someone confirm if this works and what is it giving feedback on? If it's active, it might give some clues as to what is varying when the system is oscillating."
It seems to monitor position of the controller. I've disconnected power and pot cables from servos, and values still change when the gimbal is tilted in different directions. I have not been able, though, to use the "Download CSV" function. It triggers an "Unhandled exception" error.
/Pär
No, I can't. I've set gains to 20 and jitter is still present
"I see, too, on the 1.6 software that there is a Monitor tab - can someone confirm if this works and what is it giving feedback on? If it's active, it might give some clues as to what is varying when the system is oscillating."
It seems to monitor position of the controller. I've disconnected power and pot cables from servos, and values still change when the gimbal is tilted in different directions. I have not been able, though, to use the "Download CSV" function. It triggers an "Unhandled exception" error.
/Pär
I now have it working OK, I will fly it this weekend to check it out properly. Completely new wiring loom. Spring system and balance. I would say that this is about as good as it will ever be. If it were possible to access the PID then there could still be an improvement. With the state of mechanical inefficiency I doubt that it is really worth more effort.
Last edited by a moderator:
chris hornby
Member
Just fishing around here, in the hope that something I say may trigger a Eureka moment with somebody who a) has one of thee things in front of them and b) understands more about system controllers than I do.
Maybe someone at PH will read this and have a Eureka Moment. They seem to have been very quiet since the 1.1.6 release and there have been plenty of suggestions, modifications (bodges) and feedback here on this forum. The $64K question is would 2 skylines solve the crosstalk issue? Has anyone tried it yet?
I would buy another if I could be sure that I would then have "rock steady" stabilisation. I still have faith in it, surely it cant be rocket science to solve a bit of jitter? Felt washers, springs, capacitors and ferrite might improve things, but they can hardly be regarded as a fix for a commercially available product.
Photohigher, we still have faith in you. Let us know how you are getting on and work with us! Let us know a few areas we could experiment with until we get our final rock steady solution!
Interesting to read that disconnecting the servos and reconnecting them solves the jitter for a while. I have experienced this and it is illustrated in an earlier video I posted. Maybe this could be automated/emulated in the software. If the jitter occures in cycles of say 5 seconds, do a momentary disconnect every 4. (just grasping at straws)
chris hornby
Member
Please post pics. I have also done springs but not sure that they help and my wiring looks like a knitting lesson now....
The most helpful thing I have done is felt washers, they reduce jitter but slow the response time. Should be OK for calm conditions but not for turbulence.
I'll do that after I have flown it as It may need more work. I don't like the idea of a friction brake to stop the jitter, that is the opposite way that this needs to work. Mass balance would be useless in that scenario.
DucktileMedia
Drone Enthusiast
I am curious to hear from those that chose the Skyline over the Hoverfly gimbal. I have a very short period of time left to get my gimbal in tip top shape and I feel everyday I wait for an answer to arrive on the PH there are more issues. I am not an electrical engineer and dont really have the time to be a guinea pig for the product. I would love to see it work, obviously, or I would not have purchased it! But facts are facts and I dont feel as a paying customer I should have to hack wires and spend endless hours trying to figure it out. Thank god for you few on here that do take the pride and pleasure in trying to fix this. but has anyone had great luck with the Hoverfly gimbal? I know i posted this on the hoverfly thread but just want to make sure before buying another board.
1001 Copters
Member
Hi,
about the PID discussion: the velocity gain was acting as a DAMPENING function. So it's not a PI but a PD regulation as you describe it.
Photohigher have simplified the software interface to avoid user problem using the skyline.
About using 2 skylnes: one of my customer have used this solution succesfully for a shooting in mongolia. As you have seen, using only one servo avoid most of the jitter problem.
He have placed both skyline on a cinestar gimbal.
Best regards,
Cédric
about the PID discussion: the velocity gain was acting as a DAMPENING function. So it's not a PI but a PD regulation as you describe it.
Photohigher have simplified the software interface to avoid user problem using the skyline.
About using 2 skylnes: one of my customer have used this solution succesfully for a shooting in mongolia. As you have seen, using only one servo avoid most of the jitter problem.
He have placed both skyline on a cinestar gimbal.
Best regards,
Cédric