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.

The INDI mount drivers need position information from the mount, in your case altitude and azimuth. This gets translated to sky positions and the driver also converts sky positions to altitude and azimuth positions to which the hardware can be driven. The mount hardware also needs to move both axes at the rates required to track objects in the sky. This all requires accurate positions - within an arc minute or better and accurate speed control - to within an arc second a second or better.

Your hardware seems to use DC motors and it isn't clear how you get position data from it. Some mounts have digital encoders on the mount shafts but high resolution encoders are expensive. A lot of commercial mounts have encoders on the DC motors and these are used, with clever motor control software to get positions and control the tracking rate. Does your hardware have this? You mentioned Closed loop PWM and PID but I'm not sure I can see position sensors.

An alternative is to use stepper motors and this is what most home grown systems use. The motors operate by counting steps so position and step rate fall out naturally.

The basic INDI telescope driver does not concern itself with any of this, it assumes that there is lower level software that will provide position, usually as Ra and Dec, move to a Ra and Dec position and do tracking.

There is however an IND alignment subsystem that is intended to manage this conversion and the calibration needed to handle conversions between astronomical positions and rates and mount axis positions and rates. This may be what you need. I don't think this is trivial though, there's quite a lot needed to get from motors to something tht can be used.

Hope this helps, it's difficut to know what level you are at with all this.

Chris

You seem to be quite advanced in your mount design but if I may suggest, have a look at the OnStep project, which make use of stepper motors to drive the mount. Many people have converted their Dobsonian mounts to OnStep and you may find more ideas under the "Showcase: Built with OnStep" link of the Wiki page which you can get to at: onstep.groups.io/g/main/wiki/home . Unfortunately for you, you would have to modify your design to adapt it for stepper motors but it may be worthwhile as there already is an indi driver for OnStep.

Nice design BTW. Good luck.

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.

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.

Yes it's quite simple to transform between the altitude and azimuth coordinate system of your mount to the hour angle declination system, all that's needed is to rotate by the latitude. That can be done using the sine and cosine rules or using matrices to manage the coordinate rotation. Once you have the hour angle, time and longitude it's easy to convert hour angle to right ascension.

This won't compensate for mount alignment errors but all that's needed is to eliminate those. No need to involve software at all if you don't want to.

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