search

esa / pypogs

An automated closed-loop satellite tracker for optical links with portable telescopes.
https://pypogs.readthedocs.io/en/latest/
40 stars 14 forks source link

ASCOM Camera and Mount Support #8

Open rkinnett opened 3 years ago

rkinnett commented 3 years ago

Please consider implementing the ASCOM camera and mount APIs. Doing so would enable the vast majority of modern telescope mounts and astronomy cameras to be used with this system while avoiding needing to implement APIs for specific models.

https://ascom-standards.org/

Thanks

rkinnett commented 3 years ago

I drafted a fix in PR #9.

Edit: Specifically, PR #9 implements ASCOM camera support, not mounts (yet). Tested with ASCOM telescope simulator, ZWO asi120mc, asi174mm, and QHY5Lii-M.

gustavmpettersson commented 3 years ago

Hi Ryan,

We very much welcome additional hardware support so this is great. I'm on vacation but will review in the coming weeks. Are you also working on ascom mount support? I recall briefly looking at it years ago but not in that much detail since the celestron serial interface is nice and easy.

rkinnett commented 3 years ago

Hi Gustav, this is a fantastic project! Yes, I am also interested in adding ASCOM API for mounts as well. For now, I prioritized implementing ASCOM camera support since the native Synta API should work with my telescope mount, but I do want to switch over to the ASCOM API for mounts as well, for more flexibility. It may be a few weeks before I start on the mount interfaces.

rkinnett commented 3 years ago

10 adds ASCOM mount support. Tested with ASCOM Scope Simulator V2.

rkinnett commented 3 years ago

Hi Gustav, would you be interested in adding support for equatorial mounts? Granted, they're not ideal for sat tracking, and it may be a significant expansion to add appropriate controls, limits, logic branches, and math, but it would significantly expand the set of supported hardware. Full disclosure, my interest is in imaging satellites with common astrophotography gear and bringing that capability to other folks in the astrophotography community. I recognize that's not an intended use for pypogs and will understand if you prefer not to expand in that direction.

gustavmpettersson commented 3 years ago

Hi Ryan,

I've found some time to work on pypogs. I'll review your code separately from this but generally it looks good.

I think ascom support is great to add, I'll make some accommodations for it now:

I've considered equatorial mounts before and I'm not opposed. It is however difficult to deal with both in code and practically from an alignment standpoint. Many mounts can have the polar axis set pretty near Zenith, and I've considered that as a possible workaround where most of the present mount control and alignment features could still work. Obviously, you're welcome to implement "real" equatorial support as well.

I'd be happy to support satellite photography, I've used pypogs myself to image the ISS and planets with good results. Do you have a list of key features that would be needed for that direction?

rkinnett commented 3 years ago

Hi Gustav, thanks for writing back. My apologies for a delayed response.

Thank you for checking out the ASCOM support PRs and opening the hw_ascom branch. I see you posted many good questions on the ASCOM mount support PR. I'll try and work through those this week. I agree that this will need more testing and documentation updates before merging.

In August I spent some time trying to prepare pypogs for EQ mount control, and got pretty deep into it but came to the same conclusion as you stated here, that it would be difficult to support both in code (and documentation!). I might try again at some point down the road but for now I've set that aside. I will also look into whether I can configure my equatorial mount (SkyWatcher EQ6-R) to operate as an alt/az mount with the polar axis either horizontal or toward zenith.

Somebody wrote to me this week about trying to use my fork of pypogs with his alt/az mounts and encountering some rate commanding errors. The problem was that some mounts only support discrete rates or discontinuous ranges of allowable rates, but I had neglected to accommodate this, hoping that most mounts would support arbitrary floating point rate values within rate limits. I fixed this along with many lesser ASCOM interface issues in a new "sandbox" branch of my fork of pypogs, and I have tested with a budget Meade alt/az mount.

By the way, I work for NASA, and the gentleman who is helping with testing works for MDA in Canada. Of course our involvement with pypogs is in our free time, on a voluntary basis 100% unassociated with the agencies we work for, but I just wanted to mention this because I find it intriguing that we have folks affiliated with three separate space agencies contributing to this open-source (ESA sponsored) project! :)

I added a TLE lookup feature that you might find useful. When I test pypogs, I first connect my mount to an ascom driver "hub", then connect that to both pypogs and Stellarium which displays where the mount is pointed in real time. Stellarium also has a nice satellite plugin. I can select any satellite to view information about it and get its NORAD ID, then enter that ID in pypogs to automatically fetch the TLE and send my telescope after it. Chasing satellites this way is a lot of fun! I'll setup a dedicated PR for this, separate from the ascom stuff.

One detail to consider for satellite imaging is whether it's possible to control from the fine control camera while simultaneously recording the camera's full-frame-rate image stream to video, even if the camera's frame rate significantly exceeds the pypogs control loop rate. Any idea if that might be possible? Alternatively, I can look into whether ASCOM camera drivers allow multiple clients to connect to a single camera, in which case I might be able to record the full stream with separate software while pypogs grabs single frames as needed within the control loop. A recording feature built directly into pypogs might be a neater, more general solution.

Another feature that I have been contemplating is a user-adjustable TLE projection lead/lag parameter to compensate for along-track projection error and system lag. In a few quick open-loop experiments, I'm finding that the ASCOM telescope simulator lags behind satellite positions indicated in Stellarium by several seconds. I have not confirmed this with real hardware.

Taking that last idea a bit further, for open-loop TLE-based control, it might be useful to implement both along-track and cross-track projection offsets and make these easily accessible in the main UI, perhaps using a joystick or keyboard arrow keys for example. This feature would be handy for satellite imaging, probably not so much for optical comm.

Lastly, the Celestron NexStar protocol supports a good chunk of astronomy mounts out there. Meade's LX200 protocol covers another good chunk. After settling ASCOM interfaces I might try to implement that protocol as a third mount model option. By the way, in the mount selection UI, we should consider enumerating the list of supported mount models into a pull-down selector.

Thanks for you continued dedication to this project!

gustavmpettersson commented 2 years ago

Hi Ryan,

Thanks for the details, I've also seen you've been actively working on the code which is great! Hopefully next week I can find some time to review the details. I also enjoy the collaboration, and it should be noted that I now only work on pypogs in my free time too. I'm also glad my comments didn't scare you off from continuing :)

Firstly I think adding the TLE lookup and separating the tracking rate from the recording rate are great ideas and something we could merge into master directly. Same goes for any general GUI upgrades. Regarding the tracking vs image saving I think there is a simple solution. We can add a new property (e.g. tracking_rate_divider) which is an integer for the number of camera frames that pass per frame used for tracking. In the TrackingThread _run loop we just increment a counter until it reaches tracking_rate_divider to actually do the tracking, otherwise the image just gets saved. An alternative method which may be more elegant, and especially preferable if you want anything other than raw tiff files to be saved, would be to move the whole saving feature set to the Camera class instead. At the same time we should implement a flag and a checkbox in the GUI for saving. Thoughts?

The timing issue you raise is an important one and something I ran into several times. It is in my experience only a big issue when the altitude rate switches at the highest point in the orbit, otherwise the feedback deals with it fine. I just worked around it by being connected to the internet and keeping synchronisation within a fraction of a second. There are proposed methods for predicting the timing offset (e.g. a Kalman filter in https://dspace.mit.edu/handle/1721.1/119269 Section 4.3.1.) but I'm not convinced such a complicated method is required. By taking the difference of the feedforward alt-az position (target_mnt_altaz) and the closed loop alt-az position (mount_mnt_altaz), and projecting this on the feedforward rate (target_mnt_rate), you can get a number for the timing offset directly from the tracking loop. We could then implement a new feedback on that offset, and if the bandwidth of the offset is kept lower than the alt-az tracker (ideally by a factor of about ten) this should solve that issue rather nicely. Implementing just the estimation part of this method would be the first step and from there we can see if it would work.

Supporting LX200 protocol would be great. Afaik it supports any tracking rate but only with a resolution of 0.1deg/sec. It would be interesting to see how much that affects the results.

Feel free to send me an email at gustavpettersson-live-com if you want to set up a quick call to strategise.