Add Alpaca (ASCOM Alpaca) driver support for cameras and mounts#1368
Add Alpaca (ASCOM Alpaca) driver support for cameras and mounts#1368joeytroy wants to merge 8 commits intoOpenPHDGuiding:masterfrom
Conversation
This commit adds initial support for the ASCOM Alpaca protocol, allowing PHD2 to connect to Alpaca servers for camera and mount control over HTTP. Features: - Camera driver (cam_alpaca.cpp) with full image capture support - Mount/telescope driver (scope_alpaca.cpp) with pulse guiding support - HTTP client implementation (alpaca_client.cpp) using libcurl - Configuration dialogs for host, port, and device selection - Support for standard Alpaca API endpoints Implementation details: - Default port set to 6800 (standard Alpaca port) - PUT requests send parameters in request body with proper Content-Type header (application/x-www-form-urlencoded) - GET requests use proper HTTP headers (Accept: application/json) - Comprehensive error handling distinguishing network, HTTP, and authentication issues - Extensive debug logging for troubleshooting - Cookie handling enabled for potential session-based authentication - Flexible URL building supporting both /api/v1 endpoints and root-level endpoints (management/, setup/, etc.) - GetBool() handles both boolean and integer (0/1) responses for server compatibility - Graceful handling of setup dialog cancellation The implementation follows the ASCOM Alpaca API specification and includes robust error handling and diagnostics to help users troubleshoot connection issues with various Alpaca server configurations.
agalasso
left a comment
agalasso
left a comment
There was a problem hiding this comment.
This looks great! Thanks for the PR!
Would you mind separating out the ascom error logging changes to a separate PR since those are unrelated to alpaca as far as I can tell. We can merge those to master first and separately to make this pr smaller and a tiny bit easier to review.
|
@agalasso Thank you, you bet! In terms of the ASCOM error logging change it was added because PHD2 still spins through the ASCOM enumerators every time the gear dialog opens. Even when you only want Alpaca. On machines without the ASCOM Platform installed that code would throw “could not instantiate ASCOM profile class” exceptions, littering the log even though nothing was actually wrong. The change simply checks whether ASCOM.Utilities.Profile can be created; if not, we log one line (“ASCOM … not available, skipping enumeration”) and exit quietly. That keeps Alpaca-only setups from misreporting errors while still allowing ASCOM enumeration to run normally on systems where the platform is installed. |
|
Thanks for your interest in the project. I've taken a very quick look at some of this and I don't think it's ready to be merged - not at all. Or maybe I don't understand what you're doing. I decided to take 5-10 minutes to look at your scope_alpaca implementation, fully expecting it to be a mirror image of scope_ascom. But of course it isn't. I think there are a number of mistaken ideas expressed in your code and source comments - here are just a few: I don't mean to be harsh here, perhaps you're just submitting this as an initial framework for a follow-on, industrial-strength implementation. But adding something like this is a significant project and I would prefer to see a top-down discussion first. I'd like to see a document that covers the following points: Motivation - On Windows, PHD2 can already connect to Alpaca drivers with no work done on our part. That was a key part of the Alpaca initiative, client applications are insulated from the communication plumbing changes associated with Alpaca. So the current scope_ascom will work fine interacting with an Alpaca telescope driver. That basically insulates us from having to debug and support all the immature Alpaca drivers that will emerge over time. Why do we want to forgo that benefit and reinvent that wheel? What is the deployment use-case you are worried about? What are your plans for unit-testing all the device-dependent parts of PHD2? What are the current Alpaca device drivers that are available to you for that? How many live, non-simulated Alpaca drivers are out there and what are the prospects for being able to use them for both unit and field beta testing? What is the implementation strategy? For example, how can you avoid mirroring all the capabilities and behaviors of scope_ascom including debug logging, error-detection, and alerting? Why would there be any need to modify any of the *_ascom source files? As I said, this is based on only a very quick look at the telescope side of things, I haven't even looked at the camera-related changes. But I don't see any reason to be in a hurry with this kind of implementation and when we do decide to pursue one, it needs to be bullet-proof. |
|
@bwdev01 Thank you the response! Don't worry about the harshness at all, I appreciate your feedback and looking this over 👍 So lets break this down with some bullet points
When connecting to PHD2 it does not see anything in terms of my gear no camera, no mount, no nothing. For what it's worth I am running Windows 11 with N.I.N.A and I have not installed ASCOM on my Laptop or any drivers like ZWO, iOprtron, etc. as all the drivers are being handled by AlpacaPi Server keeping a nice small footprint.
For right now if you have any more feedback or things I should look at I would really appreciate it. I will go back to do some more work on this and see how INDI is executing everything in terms of handing control off to PHD2 so I am not creating new files and using what is already in the code base. |
This commit adds comprehensive support for the ALPACA protocol, allowing
PHD2 to control cameras and telescope mounts via HTTP-based Alpaca servers.
This enables cross-platform device control without requiring platform-specific
drivers.
New Components:
1. AlpacaClient (alpaca_client.cpp/h)
- HTTP client implementation using libcurl for Alpaca API communication
- Supports GET and PUT requests with JSON parsing
- Handles authentication, error codes, and response validation
- Helper methods for common data types (bool, int, double)
- Robust error handling and debugging support
2. CameraAlpaca (cam_alpaca.cpp/h)
- Full camera implementation following GuideCamera interface
- Features:
* Connection/disconnection with device selection
* Image capture with subframe and binning support
* Cooler control (on/off, setpoint, status monitoring)
* Pulse guiding support for onboard ST4 output
* Exposure control (start, abort, stop)
* ROI (Region of Interest) support
* Automatic axis detection and correction
- Capability detection for optional features
- Comprehensive error handling and user feedback
3. ScopeAlpaca (scope_alpaca.cpp/h)
- Full mount/telescope implementation following Scope interface
- Features:
* Connection/disconnection with device selection
* Pulse guiding with async support and status monitoring
* Coordinate reporting (RA, Dec, sidereal time)
* Guide rate reporting
* Slewing support (sync and async)
* Site location (latitude/longitude) reporting
* Side of pier detection
* Slewing detection and abort capability
- Capability detection for optional mount features
- Integration with PHD2's guiding algorithms
4. AlpacaConfig (config_alpaca.cpp/h)
- Configuration dialog for Alpaca device setup
- Features:
* Server discovery via UDP broadcast
* Manual server entry (host/port)
* Camera device enumeration and selection
* Telescope device number entry
* Settings persistence per profile
- User-friendly interface with automatic camera discovery
- Error handling and validation
5. AlpacaDiscovery (alpaca_discovery.cpp/h)
- Network discovery implementation for finding Alpaca servers
- Uses UDP broadcast on port 32227 (Alpaca discovery protocol)
- Cross-platform implementation (Windows and Unix)
- Automatic network interface detection
- Broadcasts to all local network segments
- Parses JSON responses to extract server information
- Deduplication of discovered servers
Build System Changes:
- CMakeLists.txt: Added all new source files to build system
- Files properly integrated into camera and scope source groups
- Conditional compilation via ALPACA_CAMERA and GUIDE_ALPACA defines
Key Features:
- Network-based: Devices can be on remote machines
- Standards-compliant: Implements Alpaca protocol specification
- Robust error handling: Comprehensive error messages and recovery
- User-friendly: Automatic server and device discovery
- Profile support: Settings saved per PHD2 profile
- Debug logging: Extensive debug output for troubleshooting
Testing Considerations:
- Testing with finding server works
- Still not finding the cameras on the server
- Still more validation is needed before pushing back to PR
|
I would prefer that we pause and have a side discussion via private e-mail. I think there are still a lot of high-level unanswered questions and spraying code into the repo is probably not the best way to resolve them. Just as one example, PHD2 on Windows can already communicate with Alpaca drivers, that was a core requirement of the Alpaca project. I can do it in a test environment and we have users in the field who are doing it. But you seem to think otherwise. Please send me a private e-mail at bw underscore msg01 at earthlink dot net so we can get on the same page. |
|
Bruce, just my 2 cents. I think it is important to add native Alpaca support to PHD2. About the implementation of the available Alpaca devices list, the Alpaca discovery protocol work very well and this make possible to add the discovered devices directly in the main list along with the ASCOM devices found in the registry (this is what NINA do). |
|
@bwdev01 Bruce I dropped you an email. And as Patrick mentioned the Alpaca protocol is very nice in terms of auto discovery. This last commit I pushed I added the discovery method so you do not need to know the IP of the device just click Discover Server and it finds the Alpaca server on the connected network. I also fixed the concerns with the mount (still need to test). I am still working on allowing it to list the cameras from the server in the dropdown so you don't need to log into the server to find the camera. Also I need to debug a lot more and test this whole thing when the clouds are gone. As Patrick mentioned there are more device now that support Alpaca. But the whole thing with AlpacaPi Server is I am building drivers out for as many devices as possible. I just added iOptron Mount support. So you simply plug your device into the RPi and then rerun the setup on the server and choose the specific drivers you need and it builds only the drivers you need. This then allows your device to work 100% driverless on any client you want to use. But more importantly on any operating system you choose be it Windows, Mac or Linux. Since this is not fully cooked we can close the PR out if you like and when I have everything working and tested I can resubmit the PR. Or I can keep pushing up the work as I get items completed, just let me know how you would like to proceed. |
- Add an Alpaca rotator driver and integrate it into rotator selection, config, and build inputs (Windows builds). - Extend the Alpaca config dialog to query rotator devices and store /alpaca/rotator_device. - Improve Alpaca client reliability: retry on connection-closed errors, force fresh connections with "Connection: close", and parse Alpaca ErrorNumber/ErrorMessage consistently. - Add query-string parameter fallback for PUT/PutAction and a GetString helper with flexible response parsing. - Make camera/mount connections more robust (connect verification, optional capability checks, standard BinX/BinY and ROI parameters, better device name/description handling, tolerant guide-rate errors). - Improve discovery via per-interface broadcast targets, draining all UDP responses, and duplicate server filtering. - Align Alpaca camera with updated PHD2 camera API (CaptureParams and HwBinning/MaxHwBinning) and Bayer recon handling.
|
@bwdev01 @pchev @agalasso Gents, I have updated the code base. I will be testing tonight to make sure it all works as expected. I have cleaned up the Alpaca Discovery method and also added support for the rotator as well. Here is some screen shots. Also I do not know if you all have a checklist to make sure everything works as intended? As long as Alpaca HTTP is sending the name of the cameras connected they show up properly Alpaca can now read the sensor size and automatically sets it It automatically finds the Rotator If we turn off the rotator and check it shows the name for the rotator |
agalasso
left a comment
agalasso
left a comment
There was a problem hiding this comment.
Preliminary review comments. Please address these and I'll review more, thanks.
- Add client ID/transaction IDs, mutex protection, and raw GET support with retries and content-type validation in Alpaca client - Support ImageBytes decoding with metadata checks, improve JSON fallback parsing, and refine subframe/axis handling in Alpaca camera capture - Improve Alpaca connect verification via CameraState and tighten error reporting - Make Alpaca config wizard-aware, validate device selection, and reset devices when servers change - Normalize profile keys to LastMenuChoice with fallbacks in gear/camcal dialogs and handle empty camera selection - Guard image scale adjustments when scope/camera are unavailable and tighten ASCOM camera enumeration failures
|
@agalasso I think we are good to go. I improved the setup wizard for Alpaca and fixed an issue with the lowercase c in the code that was causing the cameras not to hold their settings when completing the wizard 77d42cd#diff-bd3bdc41ba9085df37bc5f348879d7ebe2ed8ce871471e7f76374a884e376ab3R1040. Also |
agalasso
left a comment
agalasso
left a comment
There was a problem hiding this comment.
partially reviewed. will review more when after commented issue is resolved
| if (!profile.Create(L"ASCOM.Utilities.Profile")) | ||
| throw ERROR_INFO( | ||
| "ASCOM Scope: could not instantiate ASCOM profile class ASCOM.Utilities.Profile. Is ASCOM installed?"); | ||
| if (!profile.Create(L"ASCOM.Utilities.Profile")) |
There was a problem hiding this comment.
It looks like you removed the corresponding changes from cam_ascom.cpp. Presumably these changes in scope_ascom.cpp should be removed as well.
If you think this is check is needed, please submit a separate PR with this change and remove the change form this pr.
The following checks should be removed no matter what (#1368 (comment))
Replace silent error returns with explicit ERROR_INFO exceptions in EnumAscomScopes(). This improves error reporting by: - Throwing descriptive exceptions instead of returning empty list - Including exception details from ASCOM COM objects - Providing clearer error messages when ASCOM profile or device enumeration fails Changed error handling for: - ASCOM.Utilities.Profile instantiation failure - RegisteredDevices query failure - Telescope count query failure
agalasso
left a comment
agalasso
left a comment
There was a problem hiding this comment.
A few more partial review comments.
This is a massive PR, and the best way to move it forward is to get all the non-alpaca changes out of this PR and submitted as separate PRs we can review and merge separately.
- intentional whitespace changes - one pr for all of them is ok
- any bug fixes you found on the way ("LastMenuchoice" for example) - one pr for each bug fix
- anything else that is not specific to alpaca - one pr for each independent change
Ideally the alpaca PR should just contain alpaca-related files and only touch the other files where necessary (like lists of scopes etc.) That will make things much easier for the reviewers and help move this forward.
Thanks!
There was a problem hiding this comment.
I should have noticed this in the last review, but same comments in this file too regarding either reverting the changes and/or submitting the changes as a separate PR
There was a problem hiding this comment.
@andkem the reason for all these changes to src/gear_dialog.cpp is it was not holding the Alpaca camera choice into the settings and so the user would need to go back and choose Alpaca again and discover the server again then choose the camera. This bug was causing issues with Alpaca and why I didn't add it as a separate PR. This fix should also resolve issues for users using the Wizard and PHD2 not keeping the camera that the user choose in the Wizard. Let me know if this is acceptable.
There was a problem hiding this comment.
This fix should also resolve issues for users using the Wizard and PHD2 not keeping the camera that the user choose in the Wizard.
Again, thanks for identifying that bug. It's a legitimate issue that needs to be fixed and would appreciate getting a separate PR with your fix. We can review that separately and get it merged, and that will get the changes out of this PR and help make this PR only contain the alpaca changes and nothing else which is what we are requesting. Otherwise, we have a massive PR with various unrelated changes which is difficult to review and may have unintended consequences, and we want to minimize the risk of that. The best way to do that in my experience is to get the unrelated changes out of the big PR and review them separately. Thanks!
| static bool DeviceSelectionMatches(const wxString& val, const wxString& item) | ||
| { | ||
| if (val.Contains("INDI")) | ||
| return item.Contains("INDI"); | ||
| return val == item; | ||
| } |
There was a problem hiding this comment.
looks like a whitespace-only change, unrelated to the rest of the pr?
If so please revert; if this change is needed it can be submitted as a separate pr.
| wxCommandEvent dummyEvent; | ||
| m_lastCamera = pConfig->Profile.GetString("/camera/LastMenuChoice", _("None")); | ||
| m_lastCamera = pConfig->Profile.GetString("/camera/LastMenuChoice", wxEmptyString); | ||
| if (m_lastCamera.IsEmpty()) | ||
| m_lastCamera = pConfig->Profile.GetString("/camera/LastMenuchoice", _("None")); | ||
| if (m_lastCamera.IsEmpty()) | ||
| m_lastCamera = _("None"); |
There was a problem hiding this comment.
Thanks for identifying the Lastmenuchoice problem in the profile wiz. Please submit a separate PR as the changes here are unrelated to alpaca.
There was a problem hiding this comment.
So I had to ask myself this: by now the ProfileWiz has been used 10's of thousands of times and no one has ever reported the problem of losing a camera selection. And if you get really thorough with the debugger, it doesn't happen. That's because Windows Registry keys are case-insensitive, that's the rule. So, yes, this lower-case 'C' problem deserves to be fixed, but you can't making the argument that it's affecting end-users, at least not on Windows. And it doesn't necessarily justify all this other stuff having to do with "empty"/"none" handling..
| wxString choice = m_pCameras->GetStringSelection(); | ||
| if (choice.IsEmpty() && m_pCameras->GetCount() > 0) | ||
| { | ||
| m_pCameras->SetSelection(0); | ||
| choice = m_pCameras->GetStringSelection(); | ||
| } |
There was a problem hiding this comment.
again, this seems unrelated to alpaca. Would prefer to see a separate PR for this.
4 participants
This commit adds initial support for the ASCOM Alpaca protocol, allowing PHD2 to connect to Alpaca servers for camera and mount control over HTTP.
Features:
Implementation details:
The implementation follows the ASCOM Alpaca API specification and includes robust error handling and diagnostics to help users troubleshoot connection issues with various Alpaca server configurations.
Here is the new options when setting up the camera which allows you to point to your Alpaca Server. This has been tested with AlpacaPi Server https://github.com/open-astro/AlpacaPi-Server which also needed some updates as well to properly work with PHD2 https://github.com/open-astro/AlpacaPi-Server/commit/cf9bb019cbd3881de02a2ce3c42cfaeec7399d37