I'm very new to kstars and I'm starting to think I've bitten off more than I can chew.
I have a small SCT (A Celestron C5). Last year I built a poncet-style equatorial platform that I drove with a couple stepper motors and an Atmega168. It was much better than an unguided setup, but it got me thirsty for more control. I wanted autoguiding, autoalignment, autofocus, and I didn't want to spend a whole lot of money on it. So I started to put together hardware for it, with the goal of creating a "pull-to" mount (as opposed to go-to).
Here's what I ended up with:
* A Raspberry Pi 3 running Ubuntu Mate and kstars-bleeding
* The No-IR 8mp PiCamera module mated with a 50mm f/1.4 lens for the guider CCD
* Celestron C5 (bare telescope) paired with a Canon 70D. The Canon is recognized by gphoto2.
* I have a continuously-rotating servo attached to the Celestron's focus knob
* I added a second axis to my poncet platform (which only allows a couple degrees of declination axis freedom)
* I replaced the tripod that used to sit between the Celestron and the EQ platform with a truss support for a Dobsonian-style trunnion alt-az head.
* I'm making encoder wheels for the alt and az axis. These are IR sensors that are watched by another ATMega168 which will maintain the relative alt and az position counts.
Now I'm pawing through driver source code hoping to find existing drivers that I can make talk to all of this stuff. As a proof of concept, I was able to write some Python to create a PTY and have it accept commands as if an INDI driver were talking to a serial port, and I feel pretty comfortable doing that sort of thing for most of my frankenhardware - a lot more comfortable than trying to write custom drivers at this point. What I really need help with is identifying existing drivers that are a good match for my hardware's actual capabilities, so that I can write some python to impersonate the hardware the driver is used to talking to.
* Telescope: The dsc "Digital Setting Circles" driver seems ideal for my alt-az encoder sensors - but I want to be able to control both axes of my EQ platform as well. I can't implement go-to commands, but I want to be able to accept directional guiding pulses (like an ST4 would send). Is this doable?
* Focuser: I can make the Meade LX200 focusing protocol work, but I don't otherwise have an LX200-compatible mount. I don't see any other "simple"-type focusers in the INDI codebase except maybe the Arduino Focuser - but the INDI<->Arduino protocol is pretty opaque at first glance. What else is there?
* PiCamera CCD: INDI detects it using the V4L2 driver, and live video works if I set the capture type to Motion JPEG, but I can't capture still photos. Is this going to be a problem? The issue appears to be that the INDI driver complains that "Absolute exposure duration control is not possible on the device!" but the INDI control panel doesn't seem to have an "Auto" option for exposure time. The "raspistill" command line program will happily take pictures of specific exposure lengths, although there's a range that's accepted by the camera and going outside that range has unpredictable effects.
I have a small SCT (A Celestron C5). Last year I built a poncet-style equatorial platform that I drove with a couple stepper motors and an Atmega168. It was much better than an unguided setup, but it got me thirsty for more control. I wanted autoguiding, autoalignment, autofocus, and I didn't want to spend a whole lot of money on it. So I started to put together hardware for it, with the goal of creating a "pull-to" mount (as opposed to go-to).
Here's what I ended up with:
* A Raspberry Pi 3 running Ubuntu Mate and kstars-bleeding
* The No-IR 8mp PiCamera module mated with a 50mm f/1.4 lens for the guider CCD
* Celestron C5 (bare telescope) paired with a Canon 70D. The Canon is recognized by gphoto2.
* I have a continuously-rotating servo attached to the Celestron's focus knob
* I added a second axis to my poncet platform (which only allows a couple degrees of declination axis freedom)
* I replaced the tripod that used to sit between the Celestron and the EQ platform with a truss support for a Dobsonian-style trunnion alt-az head.
* I'm making encoder wheels for the alt and az axis. These are IR sensors that are watched by another ATMega168 which will maintain the relative alt and az position counts.
Now I'm pawing through driver source code hoping to find existing drivers that I can make talk to all of this stuff. As a proof of concept, I was able to write some Python to create a PTY and have it accept commands as if an INDI driver were talking to a serial port, and I feel pretty comfortable doing that sort of thing for most of my frankenhardware - a lot more comfortable than trying to write custom drivers at this point. What I really need help with is identifying existing drivers that are a good match for my hardware's actual capabilities, so that I can write some python to impersonate the hardware the driver is used to talking to.
* Telescope: The dsc "Digital Setting Circles" driver seems ideal for my alt-az encoder sensors - but I want to be able to control both axes of my EQ platform as well. I can't implement go-to commands, but I want to be able to accept directional guiding pulses (like an ST4 would send). Is this doable?
* Focuser: I can make the Meade LX200 focusing protocol work, but I don't otherwise have an LX200-compatible mount. I don't see any other "simple"-type focusers in the INDI codebase except maybe the Arduino Focuser - but the INDI<->Arduino protocol is pretty opaque at first glance. What else is there?
* PiCamera CCD: INDI detects it using the V4L2 driver, and live video works if I set the capture type to Motion JPEG, but I can't capture still photos. Is this going to be a problem? The issue appears to be that the INDI driver complains that "Absolute exposure duration control is not possible on the device!" but the INDI control panel doesn't seem to have an "Auto" option for exposure time. The "raspistill" command line program will happily take pictures of specific exposure lengths, although there's a range that's accepted by the camera and going outside that range has unpredictable effects.