Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_celestial_motion.thumb.jpg.a9e9349c45f96ed7928eb32f1baf76ed.jpg

Gina

Writing or Modifying INDI Drivers for Astro Imaging and Control with RPi

Recommended Posts

In the development of my rotating astro imaging rig using camera lenses, I have the requirement to control the camera rotation plus focussing and possibly zoom if I go for zoom lenses, in addition to image capture and mount control which is already covered in the INDI server and drivers for the Raspberry Pi.  ATM I'm doing this in the Arduino Nano and controlling it with Windows and control software written in Visual Basic.  This uses a Win 7 laptop in the observatory controlled remotely via TeamViewer.  I want to replace this with a Raspberry Pi and Linux.

I already have an all sky camera running INDI Server and controlled by KStars/Ekos on Linux Mint box indoors.  I'm using a standard INDI driver to control an RPi HAT and thence dew heaters.  The driver works but doesn't have a dedicated user interface so I would like to change this too.

I'm hoping I can get my head round modifying INDI drivers to suit my purposes and maybe write new drivers to extend control further.  I have experience of various programming languages including C++ and Python etc. though I may need to revise my Python as it's been a few years since I last used it.  I also have some knowledge of Linux.

I would appreciate help in pointing me in the right direction.  Thanks in advance :)

Edited by Gina

Share this post


Link to post
Share on other sites

For the raspberry Pi GPIO side there's a few ways to do it. I went with the wiringPi library. See develop branch of https://bitbucket.org/BWGaryP/mup-astro-cat/src for more info on that + code. There's also some setup notes in the docs folder for getting wiringPi working without needing suid on the binary for gpio access; requires a env variable to be set.

Once you've done the tutorials in the INDI Driver Development docs, It's worth taking a look over a couple of the existing driver implementations. The documentation around properties felt a bit lacking to me but the source eventually makes things clearer.

I don't know that much about indi, only touched on the parts I needed to get a focuser going, but if you hit any issues with that ask away.

Edited by Hicks
  • Like 2

Share this post


Link to post
Share on other sites

As a MAC user I will be watching with interest as I was considering looking creating indi drivers for come of the gear I have as a Summer project - it's been 10yrs since I last set eyes on any code tho' :(

  • Like 1

Share this post


Link to post
Share on other sites

I was going to post in the software forum but remembered I'd posted about modifying INDI drivers before so searched for it and found this thread.  As what I'm thinking of involves my current hardware, I'll post here for now but will probably post a tutorial in the software forum when I've sorted things out a bit.

Currently I'm using the Astroberry Board driver to control camera cooling (a DIY Peltier TEC job) and two dew heaters for my all sky camera.  With the latest upgrade (new lens) I don't need cooling but it does need dew heaters and the Astroberry Board INDI driver is not ideal as far as the GUI in Ekos is concerned.

This is a screenshot of the Astroberry Board interface in the INDI Control Panel.  The relevant part is at the bottom - Line A, Line B, Line C and Line D.  The titles of these controls don't match what I'm doing with them!  The functions in the ASC are "Cooling"  ON/OFF,  "Dew Heater" ON/OFF and "Dry Raindrops" ON/OFF.  I don't know what System - Shutdown - Restart does and I don't really want controls that either do nothing (or worse do something unwanted).

Screenshot from 2017-02-06 13-18-01.png

I've already edited one source file in the Astroberry library to disable a couple of unwanted drivers in the set and I've looked at the rpi_brd.cpp file which includes the details of the user controls.  I reckon I could edit these before compiling and produce different labels.

Edited by Gina

Share this post


Link to post
Share on other sites

This is the relevant section of the code :-

    
    IUFillSwitch(&Switch0S[0], "SW0HALT", "Shutdown", ISS_OFF);
    IUFillSwitch(&Switch0S[1], "SW0REBOOT", "Restart", ISS_OFF);
    IUFillSwitchVector(&Switch0SP, Switch0S, 2, getDeviceName(), "SWITCH_0", "System", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

    IUFillSwitch(&Switch1S[0], "SW1ON", "Power ON", ISS_OFF);
    IUFillSwitch(&Switch1S[1], "SW1OFF", "Power OFF", ISS_ON);
    IUFillSwitchVector(&Switch1SP, Switch1S, 2, getDeviceName(), "SWITCH_1", "Line A: 5V", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

    IUFillSwitch(&Switch2S[0], "SW2ON", "Power ON", ISS_OFF);
    IUFillSwitch(&Switch2S[1], "SW2OFF", "Power OFF", ISS_ON);
    IUFillSwitchVector(&Switch2SP, Switch2S, 2, getDeviceName(), "SWITCH_2", "Line B: 5V", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

    IUFillSwitch(&Switch3S[0], "SW3ON", "Power ON", ISS_OFF);
    IUFillSwitch(&Switch3S[1], "SW3OFF", "Power OFF", ISS_ON);
    IUFillSwitchVector(&Switch3SP, Switch3S, 2, getDeviceName(), "SWITCH_3", "Line C: 0-12V", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

    IUFillSwitch(&Switch4S[0], "SW4ON", "Power ON", ISS_OFF);
    IUFillSwitch(&Switch4S[1], "SW4OFF", "Power OFF", ISS_ON);
    IUFillSwitchVector(&Switch4SP, Switch4S, 2, getDeviceName(), "SWITCH_4", "Line D: 12V", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

I think it would show what I want if I changed it to this :-

    
    IUFillSwitch(&Switch0S[0], "SW0HALT", "Shutdown", ISS_OFF);
    IUFillSwitch(&Switch0S[1], "SW0REBOOT", "Restart", ISS_OFF);
    IUFillSwitchVector(&Switch0SP, Switch0S, 2, getDeviceName(), "SWITCH_0", "System", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

    IUFillSwitch(&Switch1S[0], "SW1ON", "ON", ISS_OFF);
    IUFillSwitch(&Switch1S[1], "SW1OFF", "OFF", ISS_ON);
    IUFillSwitchVector(&Switch1SP, Switch1S, 2, getDeviceName(), "SWITCH_1", "Cooling", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

    IUFillSwitch(&Switch2S[0], "SW2ON", "ON", ISS_OFF);
    IUFillSwitch(&Switch2S[1], "SW2OFF", "OFF", ISS_ON);
    IUFillSwitchVector(&Switch2SP, Switch2S, 2, getDeviceName(), "SWITCH_2", "Dew Heater", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

    IUFillSwitch(&Switch3S[0], "SW3ON", "ON", ISS_OFF);
    IUFillSwitch(&Switch3S[1], "SW3OFF", "OFF", ISS_ON);
    IUFillSwitchVector(&Switch3SP, Switch3S, 2, getDeviceName(), "SWITCH_3", "Dry Raindrops", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

    IUFillSwitch(&Switch4S[0], "SW4ON", "Power ON", ISS_OFF);
    IUFillSwitch(&Switch4S[1], "SW4OFF", "Power OFF", ISS_ON);
    IUFillSwitchVector(&Switch4SP, Switch4S, 2, getDeviceName(), "SWITCH_4", "Spare", MAIN_CONTROL_TAB, IP_RW, ISR_1OFMANY, 0, IPS_IDLE);

 

Edited by Gina
  • Like 1

Share this post


Link to post
Share on other sites

It's worked :)  OK "One small step..." or "From tiny acorns mighty oaks do grow" :D

Screenshot from 2017-02-06 15-48-45.png

Edited by Gina
  • Like 1

Share this post


Link to post
Share on other sites

If you want to hide the shutdown property, one option is to use the updateProperties() method. This is from what I could gather, how you're supposed to display properties only when they can be used. So for example, when connected, everything can show, when disconnected, some properties don't make sense so you can remove them until connected.

For the shutdown property you should be able to skip the isConnected test and just always deleteProperty(Switch0SP.name);

Although you could also just not create the property in initProperties, if it's created in your driver as opposed to higher up that you've inherited from. In the latter case delete should work, but you'd have to check the higher up classes just to be sure they're only reacting to the property and not directly using it, since it will be deleted.

Edited by Hicks
  • Like 1

Share this post


Link to post
Share on other sites

Back now to the original purpose of this thread viz. controlling the camera rotation in my widefield imaging rig.

Whilst the Astroberry Focuser INDI driver has many of the controls I would like to use in the GUI it's probably inherited from the Focuser class.  Checking the rpi_focus.h file this is indeed the case so as this isn't a focuser we don't want inherited focuser functionality.   Can probably copy some of the code for the controls from it though.  OTOH checking the Astroberry Board code shows it only inherits the DefaultDevice class.

 

Share this post


Link to post
Share on other sites

Before starting to write a driver by combining parts from other driver code I need to decide which controls I want.  Since I'm not modifying a single INDI driver I can start from scratch.  The rotation drive moves the camera 180 degrees and with virtually anything possible I guess it makes sense to simply enter the angle in degrees in a text box.  This would be associated with a Set control button, maybe a progress count and a light to show when completed.  Plus a Label saying "Camera Angle".  And of course, "Connect" etc.

In the code the degrees number would be converted to steps and the difference from the current step count calculated.  The code would then issue direction and step count to a routine that would send logic state to the DIR and pulses to the STEP control.  Code from the focuser driver might be used for the driver control or I could write my own code.

 

Share this post


Link to post
Share on other sites

Looking at the ratio of degrees to steps, the gear ratio is 10:1 and NEMA17 stepper motors have a full step resolution of 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.  That's awkward!  Needs careful coding to prevent errors when reversing.  An error of 1 step wouldn't matter but if there were cumulative errors is would matter after a while.

I think I should have looked further ahead when I designed the gear drive but hindsight is a wonderful thing :D Guess I could add another large gear onto the present setup - the pinion is no problem.  A gear ratio of 90:10 = 9:1 and 200 steps per revolution would correspond to 360°/9 = 40° so 1° - 200/40 = 5 steps - ideal :)

Edited by Gina

Share this post


Link to post
Share on other sites

Decided on 6t motor pinion and 108t large gear to attach to the cage giving a ratio of 18:1 and 10 steps per degree.

Share this post


Link to post
Share on other sites

That wasn't practical so I've gone for 9:1 and 5 steps per degree.  I have a modified version of the Astroberry Focuser working to control the rotation but there are a number of unwanted controls in the GUI and I want to get rid of those.  The GUI is inherited from further up the class structure so not able to be changed much in the rotator.cpp source file.  Hence I'm going to study writing my own drivers from scratch.

I plan to go through the tutorials on driver writing and see what I can learn.  However, I have another tack to try and that's Python which I've used in the past for my weather station amongst other things.  Whether this works better than directly programming in C++ remains to be seen but I'm thinking this may increase the scope of uses, particularly interfacing to the "real world".

I have bought two books about the Raspberry Pi one of which is exclusively interfacing matters. These are

Raspberry Pi User Guide

Exploring Raspberry Pi: Interfacing to the Real World with Embedded Linux

These both cover Python programming and there's a tutorial on using Python with INDI so I figure this must be worth investigating.  INDI Python Programming on Raspberry PI

Edited by Gina

Share this post


Link to post
Share on other sites

Just tried again to register with the INDI forum without success :(  Fill in page 1, fill in page 2, but from there it goes to a format-less page where it seems to want the same info again.  Anyone here have any ideas of what I can do, please?

Share this post


Link to post
Share on other sites

No?  Oh well, I'll just carry on without posting access to the INDI forum...

The tutorials seem to want testing in the RPi with monitor etc. connected.  That would require a considerable reorganisation of my hardware setup :( The advanced RPi programming book I've got shows how to cross-compile RPi software on a Linux desktop, so I'll look into that later.  Meanwhile, thinking about it, it might be worthwhile taking my HDMI monitor, keyboard and trackball off the Win 7 desktop and using them with an RPi.  Would save taking the SD card out of the RPi to edit in the reader on the Linux desktop.

Share this post


Link to post
Share on other sites

Been looking into the tutorials and only the first has any explanation that I can find.  The others just describe how to take the source code and compile it without the explanation I would like.  I'm going to have to do more searching plus studying the code and maybe trying some experiments.  This isn't as straightforward as it ought to be!  That might mean though that if I can fathom it out I might be able to produce a tutorial that we lesser mortals can understand.

I need to find out where the various GUI code is located so that I can assemble the appropriate controls to make the GUI as I want to see it.  I think (and hope) this is proper Object Orientated Programming like I used to be familiar with though that was a while ago and recent programming has been somewhat "loose" in comparison.  I would rather like to get back into "proper programming" again.

Share this post


Link to post
Share on other sites

I'm going to check this out on my Linux Mint desktop to the point of having the source code available to examine then see what I can make of it.

Firstly we need to install subversion so that we can ckeckout the INDI source code.

sudo apt-get install subversion cmake libgps-dev

Then download the INDI library source code.

svn checkout svn://svn.code.sf.net/p/indi/code/trunk/libindi

We should now have the source code in ~/libindi

gina@Mint-Desktop ~ $ cd libindi
gina@Mint-Desktop ~/libindi $ ls
AUTHORS   base64.h   CMakeLists.txt  config.h.cmake  COPYING.GPL   COPYRIGHT  drivers      eventloop.c  examples  fq.h       indidevapi.h  indidriver.h      indiserver.c  libindi.pc.cmake  LICENSE  README  tools
base64.c  ChangeLog  cmake_modules   COPYING.BSD     COPYING.LGPL  Doxyfile   drivers.xml  eventloop.h  fq.c      indiapi.h  indidriver.c  indidrivermain.c  INSTALL       libs              NEWS     TODO

drivers, examples, tools, cmake modules and lib are directories.

Now to see what is there ...

Edited by Gina

Share this post


Link to post
Share on other sites

This is going to take a while :D   One thing of interest I've found (not listed in the INDI Devices) is "Roll-Off" in the "Domes" group.  This looks like just what I want to control my roll off roof :)  I was surprised not to see a roll off roof INDI driver listed in the main documentation - evidently added since :)

Share this post


Link to post
Share on other sites

Looked at lots of files but not yet found where the GUI controls are defined.  It has be be somewhere in there!

Edited by Gina

Share this post


Link to post
Share on other sites

indidevapi looks interesting.  Seems to define individual parts of a control eg. light, text etc.  Presumably something calls these to build the GUI.

Share this post


Link to post
Share on other sites

Been looking through more files and accumulating information.  I think I may be able to run many tests on my Linux Mint desktop without a Raspberry Pi.  Obviously I can't test the hardware such as GPIO without the right hardware but for developing the driver controls and testing the GUI, I think it might work.  This would save a lot of messing about.  Anyway, I'm going to try it.

Share this post


Link to post
Share on other sites

Fell at the first fence :)

gina@Mint-Desktop ~ $ cd libindi
gina@Mint-Desktop ~/libindi $ cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug .
-- The C compiler identification is GNU 5.4.0
-- The CXX compiler identification is unknown
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- broken
CMake Error at /usr/share/cmake-3.5/Modules/CMakeTestCCompiler.cmake:61 (message):
  The C compiler "/usr/bin/cc" is not able to compile a simple test program.

  It fails with the following output:

   Change Dir: /home/gina/libindi/CMakeFiles/CMakeTmp

Following these commands from the INDI tutorial

svn checkout svn://svn.code.sf.net/p/indi/code/trunk/libindi
cd libindi
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug .
sudo make install

Had already done the first two and been reading the files created.  Seems to be something wrong with the C++ compiler.

I'll try sudo apt-get update && sudo apt-get upgrade && sudo reboot

Edited by Gina

Share this post


Link to post
Share on other sites

That didn't help :(  Still getting broken C compiler error.

Share this post


Link to post
Share on other sites

Done a "Google" but found nothing that helps or at least that I can understand :(

Does anyone have any ideas - please?

Share this post


Link to post
Share on other sites

I wondered if the INDI library was having trouble with Linux Mint but can't be as it says it will run on any Linux distro.  Which is what I thought.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Waynescave
      Hi guys
      Can anyone identify which control box this is? Is it focusmaster? And does it run off robofocus driver in Indi lib as I cannot get a successful connection (in indi within ekos) 
      I bought a robofocus motor with this control box second hand. 
      I have faith with seller that hardware works as should. 
      I've tried other cables and USB ports too. The software (k stars) I use does do port search when connecting equipment.. 
       
      Any help appreciated 
      Wayne

    • By artoleus
      Hi,
      So, I have a minor setup issue for my automation setup.   Here is a brief overview of my setup:
      Raspberrypi on the scope connected to a powered usb hub.  Connected to the hub are a external wifi card (raspberry pi3 wifi is weak), an astromodified Canon 550D, a QHY5L-II for guiding and an EQ6 pro mount. The camera and QHY are connected to an OAG.  The QHY5 is also connected to the mounts ST4 port. 
      On the Rasperry Pi 3 I am running xubuntu with INDI server and PHD2 installed.  Using realvnc to view phd2.  indi server + webserver starts on boot,  static ip on external wifi card starts on boot. 
      On my laptop I have EKOS to connect to indi server and phd2 for guiding.  I am running phd2 on the raspberrypi to hopefully this will let PHD2 have a more direct (faster) connection to the guide camera.  
      My issue:
      Their appears to be a disabled install of ufw which has some groups under iptables.  I enabled the ufw and enbled the ports 4400, 7642 (PHD2), 8624 (indiweb), 7624(indi) however the guiding suite of Ekos would not connect to PHD2.  I disabled ufw and flushed the iptables and tried again with the above ports however the same result.  In the end I have opened all the ports to allow the connection to proceed, which is ok for short term but ideally I would want some security.  
      Does anyone know which ports I should open to get indi, indiweb and phd2 to talk nicely to my laptop EKOS version?  
      Anyone else running a similar setup successfully?  Can you give me any indications of what pitfalls to avoid?
      Thanks
       
    • By wimvb
      Imaging season is still a few weeks away up here, but I've started dusting of my gear and upgrading some parts.
      One step closer to automation is a motor focuser, and I opted for a budget solution. I bought a SkyWatcher DC focuser and built a computer control for it. Since I use INDI for my automation, I had to find a way to connect the focuser to indiserver. A first thought was to use the INDIduino code, but after some coding and testing I found out that this code is very limited and not really supported by indi clients. The Ekos/Kstars focus module can't be used for focus control if you use INDIduino, apparently.
      But then I stumbled upon an Arduino solution that emulates the MoonLite focuser (http://www.indilib.org/forum/general/283-moonlite-focuser-protocol.html). Unfortunately, this protocol is for a focuser with a stepper motor, whereas the SkyWatcher has a geared DC motor.
      I had already rewritten some code from stepper to (geared) DC motor, so it was easy to adapt this to the MoonLite based code.
      My solution consists of the following:
      hardware:
      - SkyWatcher DC focuser (only the motor is used, the handbox is replaced by the Arduino)
      - Arduino UNO
      - Velleman motor controller shield for Arduino
      - 9 V power adapter to power the shield
      - Raspberry Pi
       
      software:
      - Arduino sketch with Geared Motor library (see below for link)
      - INDI server on RPi, and client (Ekos/Kstars) on Windows
       
      I've tested this setup on my SkyWatcher Explorer 150PDS and it runs fine. Unfortunately I haven't been able to test the autofocus, due to absence of astrodarkness and clear skies.
      Since a DC focuser has no knowledge about the position of the actual focuser, the software assumes that position '0' is all the way in. Maximum position is 25000 for my setup. By default, focus is increased by 100 steps, which is supposed to be 100 ms of motor drive.

      BTW, the code is in my GitHub repository:
      https://github.com/wberlo/Arduino_Moonlite_Focuser
    • By lambermo
      Hi all,
       
      The 10Micron mounts extend the LX200 protocol which means that their basics can be controlled by anything that speaks LX200.
      The Mount Command Protocol as 10Micron calls it is fully documented (I would not have bought this mount otherwise).
       
      I've started a 10Micron INDI device driver to support the extensions, based off of LX200Generic so that it inherits basic LX200 functionality.
      First thing that was added was TCP/IP support so that the mounts' ethernet port can be used for control and free up the mounts' serial port for a GPS unit at the same time.
      This support was later moved up into the main INDI::Telescope class so that all INDI mounts that support it now can use ethernet 
      On connect the driver sets Ultra Precision Mode (needed for model building later on and helpful with pointing).
      It also retrieves basic properties like product name/control box type/firmware version.
      Next Park and Unpark are supported.

      Last pull request : https://github.com/indilib/indi/pull/167
       
      Known TODO's
      - find out where J2000 needs translation to Jnow
      - support pointing model building. Maybe by porting MountWizzard (python with ties to ASCOM and SGpro) ?
       
      Who is interested in helping and/or has ideas on what needs to be implemented next ?
       
      -- Hans
    • By PESKYWAABBIT
      Hey there,
      Curious about which CCD's you have been or are using successfully with auto guiding on a rpi2 or even a rpi3?
      lin_guider seems to support a bunch of manufacturers but a list of what models are proven to work with the Raspberry pi's will surely help my quest!
      Cheers for the help!
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.