Thanks, I'll check that out. I don't know how I missed the dev tab.
Read More...
I built a custom mount and wrote custom driver software with a GUI to run it on a Raspberry Pi 4. So far, so good, but I am now in a predicament where I must choose one thing or the other.
The unforeseen event which put me in this predicament is finding out that my ZWO 294 camera won't work on Ubuntu 18.04 (arm64) without Ekos. I suppose I underestimated the level of sophistication involved with these cameras.
My two choices are now:
1) Rewrite the custom driver in INDI format and abandon the camera functionality and the GUI, using kstars/ekos instead
2) Determine how Ekos makes the ZWO library work and integrate that functionality into my existing software
The easy route would be to take option number 1 -- however, I was planning on using plate solving as a fundamental component of the driver itself. For example, I was going to automate backlash measurements and correct for geometric error via a procedure involving obtaining true position by plate solving. I realize kstars/ekos has some sort of plate solving functionality, but it probably would not be easy to integrate with my reformatted driver. Or, would it?
Alternatively, I could dig through ekos source code and try to figure out how to make the zwo camera work in my homebrew software which is already pretty far along. I was using a makeshift camera for while to develop streaming and snapping pictures within the GUI beside the controls.
I'm curious which option you guys think I should choose and why. I realize how amazing kstars/ekos is, but my goal is to make a much simpler bit of software. That is the main reason option 2 is even on the table. Here is a screen shot indicating the level of simplicity I'm shooting for.
I have been out of town, or I would have posted again sooner, but I checked out INDI alignment subsystem, and this really seems like overkill for what I'm trying to do. Perhaps I misunderstand what INDI does.
I was under the impression that I could write a driver which takes altitude and azimuth coordinates as input. Along with GPS position and elevation, I can input RA and DEC into KSTARS, and INDI converts this into altitude and azimuth coordinates and gives it to my driver which turns the motors. Am I mistaken? If INDI telescope protocol does not do this, what in fact does it do? I'm a little confused.
Read More...
I suppose I should have been a little clearer. The closed loop includes encoders indeed -- one for each axis. This is the model:
www.usdigital.com/products/encoders/incremental/kit/EC35
Here is a picture of how it is set up:
Hi, I'm building a custom Alt-Az fork mount