Mountings and Controls For Widefield Imaging Rig

[Gina]

The filing has begun to get a bit uneven   A conical ring would mean that adjustment could be applied not just for starting out but could be altered as the tyres on the wheel wore down though this should take a long time.  Here is a model of a ring to add to the present ring with a ledge for alignment.  Printing time 1.5h.

[Gina]

I think this will be a "goer"   Had to reprint the pinion as I forgot to allow for the 0.2mm size increase due to the deposited filament thickness so it didn't mesh properly with the big gear.  Getting close to testing it with a 28BYJ-48 stepper motor from Arduino Nano

[Gina]

Done some testing but the results have not been good.  Yes, I can adjust the clearance or loading on the wheels but this is not constant when the rig is rotated.  I think this is because I wasn't able to get the new running ring quite straight on the rest of the rig.  Consequently, if I get it running free enough it is loose at another angle. 

What I don't really know is if this will be a problem or not.  There will be little change in orientation of the mount and rig during the maximum sub-frame exposure of two minutes.  I guess I could just try it set up loosely with the little geared stepper motor to drive it. 

The other option would be to keep a loading on the wheels and use a more powerful stepper motor.  As I posted earlier, I have a NEMA17 with 100:1 gearbox which I could use with direct drive to the cage.  I think a NEMA17 without gearbox (of which I have several) would need more than the 10:1 gear ratio that would be the highest practical with the present large spur gear on the cage.  Or would it...

[Gina]

I guess I could estimate the torque required to turn the cage with fairly heavy loading on the wheels and see if the torque from a NEMA17 stepper motor would be sufficient from its spec.  Detent torque is given as 220 g.cm which I think is the value to go by.

Thinking about it I reckon a spur gear drive from a NEMA17 (like I use for my 3D printers) using around a 10:1 gear ratio might be the best option.  I could use a pinion of 14mm diameter and 7 teeth on the 5mm shaft of the motor, no problem, giving a force of 300g on the teeth.  But I don't really know what a force of 300g is like - I can turn the large gear quite easily by pushing the teeth with my finger - surely less than 300g!  Guess the thing to do is try it.

[Gina]

Model of NEMA17 pinion with 7 teeth.

[Gina]

Camera end bracket for NEMA17 stepper motor.

[Gina]

The NEMA17 drives it but I need to reduce the drive rate.  It rotates the drum/cage rapidly once going but the starting torque is insufficient - the motor just whines loudly!  I've had this problem with my NEMA driven electronic clocks which run the hands round fast to set the time automatically then drop to 4 steps per second for normal time keeping.  This imaging rig needs a fair bit more power than a clock so I'm not surprised (running from my epicyclic clock circuit for testing).  I'll change the Arduino sketch.

[Gina]

I guess it would be better to make up a new driver board than mess about with the clock sketch.  Meanwhile, I'm collecting up the bits to re-assemble my non-rotating rig in case of unexpected clear night skies   I've confirmed the camera and lens mounting parts for the rotation rig so I can release the camera, FW and 105mm lens from testing to set up on the mount.  I don't need to worry about focussing on the far tree in daylight for setup as there's a full moon

[Gina]

Been looking at more lenses to include in this rig.  In particular the 28mm and 55mm lenses.  The 28mm f3.5 and the 55mm f1.5 are almost exactly the same size and are a bit shorter but a bit larger diameter.  The lens supports can be in the same place as those for the 105mm lens but need a slightly larger hole for the lens.  The focus gear can also be similar to that for the 105mm lens - just a bit longer and bigger.  It will still fit into the cage

[Gina]

Since the cage is running on the original ring I have removed the new extension ring to provide easier access.

[Gina]

Looking at the motor drive for rotation, the gear ratio is 10:1 and NEMA17 stepper motors need 200 steps per revolution so 2000 steps would turn the cage by 360°.  Since the cage wants to turn 180° to cover required angles, this corresponds to 1000 steps.  5.55r steps per degree.  250 steps for 45° or 125 steps for 22.5°.  Dividing the range into 8 seems quite logical   And I think this will be a suitable resolution - I see no reason to go finer.  I might have gone for a resolution of 10° if this had worked out as a whole number of steps.

If I go for RPi control of the Arduino Nano this range is represented by a 3 bit number which could be provided by 3 of the GPIO data lines connected to 3 Arduino digital inputs.

[Gina]

I'm thinking I shall have to push myself and look into writing or adapting INDI drivers so that I can use KStars/Ekos/INDI to run these things with RPi in addition to astro imaging.

[Gina]

Since the NEMA17 stepper motor is outside the cage and the focussing stepper motor is inside the cage, one idea would be to use the present Arduino Nano focus circuit as it is for focussing and a Raspberry Pi to control the NEMA17 using the Pololu stepper driver on an RPi HAT.  And "Here's one I made earlier"...  Yes, I already have one  

The camera would be plugged into one of the USB ports and run off INDIserver and driver with the USB_serial adapter mount cable plugged into another USB port (or mount connected directly to the RPi GPIO serial).  The Nano and the EFW mini would be run from the camera built-in USB2 hub as now.

There is a nice space between the cage and the dovetail that will take the RPi, in a dedicated box, rather nicely

[Gina]

In view of problems with my imaging laptop, I'm going to concentrate on replacing it with a Raspberry Pi 3 and Raspbian OS (Linux).  This being the case, I'm thinking of dumping the Arduino Nano from the rig and doing everything in the RPi.  Having already decided to do the rotation with the RPi and Pololu stepper driver, I can do the same for the focus.  OK an extra cable (flat strip type) from outside cage to inside but less to accommodate inside the cage - no need for a bracket to hold the Nano.

I shall probably be modifying an INDI driver for the rotation control but should be able to use the Astroberry Focuser driver as-is for focussing.  For the hardware, I have modified a 28BYJ-48 5v stepper motor from unipolar to bipolar for use with the Pololu driver and 12v (13.8v) supply and will use that instead of the 12v unipolar version and ULN2003A driver.

[Gina]

I'm making progress with setting up a Raspberry Pi for the imaging rig and have had it capturing images from the ASI1600MM-Cool camera, controlling the cooling and operating the EFW mini.  I have also had it moving the NEQ6 mount.  Next job is to install drivers for the BCM microprocessor chip to use the GPIO pins and the Astroberry drivers for focussing and rotation.

I'm thinking of installing the RPi plus HAT and other components between the rotating cage and the dovetail bar but ATM there is not quite enough room so I'm proposing to raise the rotation rig slightly to make room.  Only a few mm.

[Gina]

Done some measuring and it seems that the total height of the RPi and HAT plus Pololu stepper driver module is about 5mm more than the gap between dovetail bar and cage.  Then there is the case for the electronics to allow for so I think the cage will want raising by about 10mm to allow for the electronics box and a small gap.  Easiest way to do this would be to 3D print a couple of spacers and glue them onto the present brackets.

[Gina]

OTOH there is something to be said for using a different arrangement than RPi then HAT then stepper driver one above the other producing considerable height.  Below is a photo of the RPi, HAT, driver module and buck converter.  I shall want another Pololu driver and a couple of fuses plus power input socket and smoothing/interference suppression capacitors so plenty of stuff to put on another circuit board.  I'll take a closer look at this and see how things measure up.

[Gina]

Electronics unit above is 90mm x 60mm x 30mm ex-case and excluding connectors (plugs).  Area between dovetail bar and cage is actually 170mm x 100mm x 20mm (at closest point).

If I were to include the RPi unit as is, it would need 30mm plus say 4mm for case plus 1mm clearance = 35mm minimum.  Current space between dovetail bar and cage measures 20mm (less than I had estimated) at its minimum.  That would mean raising the cage by 15mm rather that 10mm.  I would prefer to keep the C-of-G as close to the dovetail bar as possible to minimise flexure.

I think I shall see if I can design an alternative layout with the two stepper driver modules and other components on a piece of stripboard (a.k.a. Veroboard).

[Gina]

As covered in my other thread, the plan is to use a Raspberry Pi and the Linux based KStars/Ekos/INDI system with the RPi as a headless server running the INDI server.  The latter connects to the various devices through drivers and the client machine, also running Linux, uses KStars/Ekos to communicate with the RPi running INDI server.  KStars is the front-end and Ekos supplies the link to the various drivers and their associated hardware eg. camera with capture facilities and temperature control. filter wheel and remote focussing plus mount control.

This imaging rig includes rotation in addition to the usual imaging devices.  Eventually I plan to write an INDI driver for this or adapt an already written one.  This will control the orientation of the image sensor by turning the whole imaging rig (as already mentioned above.)  However, in the meantime while I sort out how INDI drivers work and get my head round all of it, I can use a driver that I have already tested for switching heaters and cooler on one of my all sky cameras.

This is the Astroberry Board driver.  The Astroberry Board itself controls four relays to switch various power supplies on and off.  I will not be using an actual Astroberry Board but use the RPi GPIO lines that this driver uses to control other things.  Basically these are called Lines A B C and D and the ON state is represented by 0v on the corresponding GPIO pin and the OFF state by +3.3v.

For the rotation, rather than specify the angle in degrees a rather coarser control can be used until I get a special driver written.  A range of 180° will cover all orientations by making use of turning the image by 180° in the processing to cover the rest of the 360°.  Now 4 control lines will give 16 permutations when converted to binary code (or hexadecimal to be precise).  This code can control another processor such as an Arduino Nano to turn a stepper motor to turn the rig an appropriate amount.

I think a Home position will need to be established as the stepper and cage could be in any position when power is applied (unless turned by hand to a specific angle).  This could be provided either by a microswitch on the frame and lever on the cage or a magnet and Hall switch.  The Home position would be allocated to "0" in code and the Arduino could Home the cage until the limit switch operated by rotating the cage (say) anti-clockwise.  Once homed the other codes would rotate the cage clockwise an appropriate number of steps.

The order of operation could Home the cage before each rotation operation OR the current position could be saved and the cage rotated one direction or the other as appropriate.  I would prefer the latter method.

[Gina]

Another photo of the imaging rig.  This shows a compromise on the cable feeding the EFW.  Straight connectors and an angle adapter.  I've ordered another cable with angle plugs on each end.

[Gina]

Code "0" =  Home = rotate cage anticlockwise until at endstop.  Other codes :- 125 steps per 22.5° = one eighth of 180° - not a sixteenth.  A sixteenth would be 62.5 steps and we can't have half a step unless using half-stepping.  Had a thought though - if I wanted to control the zoom of a zoom lens as well, I could use one bit of the binary code to determine whether to control the rotation or the zoom - allocating 8 codes to the zoom.  Now that's not such a bad idea

No. of steps = code x 125.  All the rest follows arithmetically...

[Gina]

I've designed and printed a new motor pinion for rotation and now printing a new bracket for the motor and main bearing - the previous one was encroaching too much into the space I want for the electronics box.

[Gina]

Here is the circuit block diagram.

[Gina]

Here's a photo of most of the components laid out on a piece of stripboard.  The empty space at the left will take the electrolytic and ceramic capacitors for smoothing and interference suppression.  There are also several multi-pin connectors to add.  The power in connector will go in the side of the box.  The yellow things are fuse holders placed upside down on the board as the pins will want the board holes drilled out to take them.  The middle connector takes an Arduino Nano and three connectors on the right take the three Pololu stepper motor driver modules - on shown in position.

[Magnus_e]

On 26.1.2017 at 21:49, Gina said:

As covered in my other thread, the plan is to use a Raspberry Pi and the Linux based KStars/Ekos/INDI system with the RPi as a headless server running the INDI server.  The latter connects to the various devices through drivers and the client machine, also running Linux, uses KStars/Ekos to communicate with the RPi running INDI server.  KStars is the front-end and Ekos supplies the link to the various drivers and their associated hardware eg. camera with capture facilities and temperature control. filter wheel and remote focussing plus mount control.

This imaging rig includes rotation in addition to the usual imaging devices.  Eventually I plan to write an INDI driver for this or adapt an already written one.  This will control the orientation of the image sensor by turning the whole imaging rig (as already mentioned above.)  However, in the meantime while I sort out how INDI drivers work and get my head round all of it, I can use a driver that I have already tested for switching heaters and cooler on one of my all sky cameras.

One thing to note about the INDI drivers is that they are sorted in to groups like focusers, ccd's, telescopes (mounts) and several more. All of these groups is implemented as super classes with all the generic features of the devices as virtual functions. So the super class for focusers will have all the functions for initialization, connect and everything to generate the gui an listen for button clicks etc. For a focuser there will also be functions for setting focus in / out and focus for x milliseconds.

 

As there are no super class for framing hw, your best bet is to make it as a aux device. Aux devices in indi is the most basic devices, but you have all you need to add the gui buttons and text / number inputs, and you have the timerhit function that is the event loop for the device.

One of my INDI drivers is an aux device, so it might give some insight, or make everything a lot more confusing....

 https://github.com/magnue/indi_wiringpi_gpio/blob/master/README.md