search

la1k / flyby

A satellite tracking program
GNU General Public License v2.0
39 stars 8 forks source link

Azimuth rotor errors #77

Closed bjorgan closed 6 years ago

bjorgan commented 7 years ago

Currently uses the azimuth from libpredict for controlling the rotor, but this goes directly down from 0 to 360 degrees, which will lead rotctld to turn the rotor all the way around the other way. Need to utilize negative angles better.

Close to 90 degrees elevation, there will be problems with https://en.wikipedia.org/wiki/Gimbal_lock#Gimbal_lock_in_two_dimensions (see also https://github.com/la1k/libpredict/raw/master/examples/passplot/pass_properties.png, where the required change in azimuth is almost discontinuous), which will make the rotor use some time to turn around at zenith, causing data to be lost.

JackToaster commented 6 years ago

I'm personally working on using this software to control my custom telescope mount, so I've had to deal with both of these issues.

I don't think the discontinuity from 360 deg to 0 deg is an issue with flyby, since any decent rotor control software will take the shortest path between two angles (even if it crosses 0), or purposefully turn the other way to avoid twisting wires. The alternative is to use values from -180 to +180, which still has a discontinuity, or use continuous values, which could cause issues by returning angles >360 or <-360. If there's a specific use case where you're having issues with this, could you share that with us?

As for the gimbal lock issue, there's nothing that can be done here, since that's a hardware issue.

I don't think that these issues are really issues with flyby, but rather with hardware/software being controlled by it.

bjorgan commented 6 years ago

Thanks for the insightful comment, and sorry for the delayed reply!

Yes, you are right, a decent rotor controller should be able to handle this. :-) I thought that they didn't, and that the satellite tracking software had to handle it, but it turns out that all our rotor controllers at LA1K's club locales actually handle it decently by themselves. The cause of my confusion was that our MD-01 rotor controller rotates the full turn from 0 to 359 degrees if issued a command for turning to 359 degrees azimuth when starting at 0 degrees azimuth, but it turns out that we had just forgot to enable it to use the shortest path in the settings.

As for gimbal locking, I agree. The thought here was to alleviate the issue by doing some tricks like avoiding the critical region and turn using a different path in order to reach the satellite again at the other side of the discontinuity at an earlier time than would have been possible if we headed dead-on for the discontinuity, but it doesn't become very well-defined, so I'll just close this issue. Thanks again!