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.



Of course, there are quite a few settings planned in the settings menu, however.


What would be the main difficulties I would face in either choice?

Read More...

John replied to the topic 'Simple Custom Mount Driver' in the forum. 4 years ago

Thanks Chris. I'll probably do just as you suggest.

Read More...

John replied to the topic 'Simple Custom Mount Driver' in the forum. 4 years ago

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...

John replied to the topic 'Simple Custom Mount Driver' in the forum. 4 years ago

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:



If you look closely, you can see an encoder on the same shaft as the motor. It was just easier to mount the encoders on the outside. I toyed with the idea of getting Renishaw encoders on the driven shafts attached to the scope, but ultimately decided backlash from the drive train would be manageable, since I'm using pulleys. So, I put these encoders on the shaft up the drive train. This essentially multiplies my quadrature count per revolution (40,000) by the gear ratio 28.8:1. This is indeed ~1 arcsecond resolution. Now, if I can match that resolution with calibrated accuracy, taking into account PEC, only time will tell.

In any case, it's a little late to be switching to steppers, and believe it or not, I'm doing it this way for a reason.

Eventually, I'll add field rotation to the focuser for astrophotography. Yes, you can take long exposure photographs with an Alt-Az mount -- you just need to account for field rotation. This is a prototype that I would like to turn into a commercial product at some point if everything works out. Right now, I'm making it for my father though.

I'll check out this "IND alignment subsystem." Indeed, it sounds like exactly what I need to get up and running. Thank you for all the suggestions so far.

Read More...

John created a new topic ' Simple Custom Mount Driver' in the forum. 4 years ago

Hi, I'm building a custom Alt-Az fork mount


for which I have written a driver in C. It is controlled via PWM and PID in a closed loop system and is driven by the Raspberry Pi 3B+ GPIO pins. I would like to access the GOTO and tracking capabilities of KSTAR and PHD2, respectively, by utilizing the INDI protocol.

Unfortunately, I'm a little confused about how Indi works. The overview is quite clear from the guide on this site, but the details are not clear to me at all. How do I interface my custom driver with the Indi protocol? All my driver does now is moves the two axes with the arrow keys at varying speeds with PWM and PID. How can I interface my control driver (firmware, if you will) with tutorial_two: simplescope.cpp, for example? Honestly, I don't really understand most of what simplescope.cpp is doing. There are a lot of methods being called which don't seem to have much content in the associated header. It's a little tough to follow.

Surely, people do this all the time, but I cannot find a guide about how to do this anywhere. The documentation is a little daunting, and some help navigating it would be appreciated.

I really appreciate what you guys are doing with Indi.

Read More...