Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Feedback on my open source Alt-Az mount software

DIY equipment mount
  • Please log in to reply
13 replies to this topic

#1 n-dtech.com

n-dtech.com

    Lift Off

  • -----
  • Vendors
  • topic starter
  • Posts: 19
  • Joined: 13 Jan 2021
  • Loc: Austin, Texas

Posted 13 January 2021 - 06:04 PM

Hello, I would like to try to start over. I have some software which I would like to share with the community. I made it open source GNU public license, so feel free to use it in any project you wish. It is the basis for the software which I use in my current Alt-Az fork mount prototype, which as of right now, I keep in a private repository.

 

In any case, I would love for any of you DIYers out there to try it out. I would appreciate the feedback, just try to keep the criticism constructive for me please. As of now, everything runs on a 4 core Raspberry Pi (3B, 3B+, or 4), on Ubuntu 18.04. It is a bit tricky to set up, so I might make the OS image with all of the relevant libraries, along with my software preinstalled, available for download, if people have trouble.

 

I may or may not make geometric correction algorithms available in the public repository at some point, depending on how things go in the future, along with a method calling the ESA's plate solving algorithm. As of now, it is very bare-bones, but aside from mechanical imperfections, I can assure you the software itself will enable your DIY Alt-Az mount to track as accurately as the precision of your encoders will allow.

 

There is one limitation, however. Since it runs on a Raspberry Pi currently, and for some reason the Raspberry Pi foundation has neglected to create an official library for control of the GPIO pins, I have relied on a 3rd party library for such control. Don't get me wrong, the 3rd party library I chose to link is quite excellent (http://abyz.me.uk/rpi/pigpio/). The problem is that it is written in C, and the GUI library I use is QT, which is written in C++. Incidentally, it made sense to write the bulk of the code in C++, using a class system for ease of integrating multithreading. Each motor and each encoder runs on its own core of the cpu. Ordinarily, mixing C and C++ would not cause much trouble. However, one area where C and C++ do not play well together is callbacks. Callbacks are handled quite differently in the two languages, so at the moment, there is a bit of a memory problem which can lead to occasional crashing.

 

I would like to add one more thing. I have been using the sofa library for the bulk of the calculations (https://www.iausofa.org/current_C.html), and it works incredibly well. However, environmental conditions, such as temperature, pressure, and other variables which can affect viewing conditions (sometimes atmospheric factors such as these can affect Alt-Az coordinates dramatically) are set in the globalvars.cpp file. While strictly speaking, this is not ideal programming practice, ease-of-use for the end-user was the motivation for this design. Ideally, instrumentation should be used to set these variables at runtime. As it stands now, global variables need to be set by the user before compiling. A compiled language was chosen for this application, because an interpreted language, such as python, would be much too slow to handle the accounting of the incremental encoders.

 

Anyway, please let me know what you think. I am anxious to get some more eyes on the code, so I can improve it. Here is the link: https://github.com/T.../TelescopeMount

 

[edit] One more thing -- in addition to a Raspberry Pi, a touchscreen or mouse/screen combination is required to operate the GUI. You might want to turn the brightness all the way down. [end edit]


Edited by n-dtech.com, 13 January 2021 - 06:14 PM.

  • rkinnett likes this

#2 rkinnett

rkinnett

    Viking 1

  • *****
  • Posts: 732
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 13 January 2021 - 09:41 PM

Welcome to CN!

 

Thanks for sharing this.  This project has a lot of potential.  If I run across a dirt-cheap "for parts" mount, I'll grab it and give this a shot.  I would add interfaces for Indi and ASCOM-Remote.. then this will be very intriguing for anyone looking to motorize a Dob or renovate an old fork mount.  This could also be a good starting point for a satellite tracker.

 

I hope someone can help solve that memory leak and crash issue..



#3 n-dtech.com

n-dtech.com

    Lift Off

  • -----
  • Vendors
  • topic starter
  • Posts: 19
  • Joined: 13 Jan 2021
  • Loc: Austin, Texas

Posted 13 January 2021 - 10:40 PM

Thank you for the feedback. If I added INDI integration, I would get rid of the qt GUI altogether, and that would take care of the memory leak. I don't plan on updating that repository at all, really. It is just something to share with the community, that is relatively easy to set up, and easy to build on, while I further develop my proprietary version with image acquisition capability.

 

[edit] It is simply a gift to the community, nothing more. Check out the PID algorithm (closed control loop), for example. Take it or leave it, but I use a lot of the code in my newer version. Honestly, I'm surprised no one has forked it yet. It would not take too terribly much effort to make it the default generic Alt-Az mount driver for INDI, for example.

 

A little over a year ago, I was looking for something similar and could not find such a thing, so I wrote that code. It was actually easier to make my own GUI than to integrate with INDI, so that's what I did. Additionally, I figured in the long term it would be more professional to have my own GUI than rely on an open source community undertaking. [end edit]

 

I do not plan to use the Raspberry Pi in the final proprietary version, at least not for directly controlling the motors/encoders. I will use a different microcontroller with first party library support better suited to controlling GPIOs. Then, I'll not have this problem with mismatching of callbacks between C and C++. [edit] I just pointed out the main weakness, so that if anyone wanted to pick up the reigns on the project, they would be aware of it. [end edit]


Edited by n-dtech.com, 14 January 2021 - 11:52 AM.


#4 lambermo

lambermo

    Apollo

  • -----
  • Posts: 1,103
  • Joined: 16 Jul 2007
  • Loc: .nl

Posted 14 January 2021 - 01:40 PM

Instead of SOFA you should use ERFA https://github.com/liberfa/erfa so that you do not run into licensing problems.



#5 n-dtech.com

n-dtech.com

    Lift Off

  • -----
  • Vendors
  • topic starter
  • Posts: 19
  • Joined: 13 Jan 2021
  • Loc: Austin, Texas

Posted 14 January 2021 - 01:59 PM

Have there been licensing issues in the past with sofa? As far as I know, they are the foremost experts in the field, with decades of building upon legacy code. I see no reason to change anything. I took notice of the licensing agreement here

https://www.iausofa.org/tandc.html

before I even downloaded the tarball, obviously.

 

[edit] Any mention of my open source software in any of my patent applications is toward the end of the claims, and is merely used as an example of how to control the mechanical claims. I use generic references to my software listed above (which is GNU license, incidentally...), using terminology like "such as." In any case, the algorithms used to control the hardware have little to do with those involved with the sofa library. I appreciate your concern and suggestion, however. [end edit]


Edited by n-dtech.com, 14 January 2021 - 02:11 PM.


#6 rkinnett

rkinnett

    Viking 1

  • *****
  • Posts: 732
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 14 January 2021 - 06:27 PM

It is simply a gift to the community, nothing more. Check out the PID algorithm (closed control loop), for example. Take it or leave it, but I use a lot of the code in my newer version. Honestly, I'm surprised no one has forked it yet. It would not take too terribly much effort to make it the default generic Alt-Az mount driver for INDI, for example.

 

So be it, I'll choose to leave it.  Good luck.



#7 n-dtech.com

n-dtech.com

    Lift Off

  • -----
  • Vendors
  • topic starter
  • Posts: 19
  • Joined: 13 Jan 2021
  • Loc: Austin, Texas

Posted 15 January 2021 - 01:25 AM

So be it, I'll choose to leave it.  Good luck.

Fair enough -- do you know of another open source alternative which includes a full closed control loop for each axis? I would love to see your github.



#8 alphatripleplus

alphatripleplus

    World Controller

  • *****
  • Moderators
  • Posts: 122,553
  • Joined: 09 Mar 2012
  • Loc: Georgia

Posted 15 January 2021 - 09:00 AM

Moving this to Astronomy Software & Computers for a potentially better fit.


  • n-dtech.com likes this

#9 n-dtech.com

n-dtech.com

    Lift Off

  • -----
  • Vendors
  • topic starter
  • Posts: 19
  • Joined: 13 Jan 2021
  • Loc: Austin, Texas

Posted 16 January 2021 - 08:45 AM

Moving this to Astronomy Software & Computers for a potentially better fit.

Thank you, I was not aware such a subforum existed.



#10 synfinatic

synfinatic

    Viking 1

  • *****
  • Posts: 740
  • Joined: 22 Dec 2013
  • Loc: San Jose, CA

Posted 17 January 2021 - 04:58 PM

I'm probably not the target audience since I have no idea how to tune the PID parameters as your README states.

 

That said, your code says it it licensed under the GNU GPL... but not what version of the GPL.  v2 and v3 are quite different and if someone was interested in using this code they'd probably have to do a hard pass without clarification.



#11 n-dtech.com

n-dtech.com

    Lift Off

  • -----
  • Vendors
  • topic starter
  • Posts: 19
  • Joined: 13 Jan 2021
  • Loc: Austin, Texas

Posted 17 January 2021 - 06:43 PM

I'm probably not the target audience since I have no idea how to tune the PID parameters as your README states.

 

That said, your code says it it licensed under the GNU GPL... but not what version of the GPL.  v2 and v3 are quite different and if someone was interested in using this code they'd probably have to do a hard pass without clarification.

That is a good point, and thanks for noticing. I'll probably leave it alone until I get legal assistance securing my IP, but I'll keep that in mind for the future.



#12 synfinatic

synfinatic

    Viking 1

  • *****
  • Posts: 740
  • Joined: 22 Dec 2013
  • Loc: San Jose, CA

Posted 17 January 2021 - 08:09 PM

That is a good point, and thanks for noticing. I'll probably leave it alone until I get legal assistance securing my IP, but I'll keep that in mind for the future.

Uhm, okay... I have to admit that's really not the answer I was expecting. 

 

Don't get me wrong... if you want to make $$$ off your work, I got no problem with that.  I write code for a living.  I've also been releasing code under various flavors of the GPL and BSD licenses for about 20 years and helped companies navigate the issues with them.  (Don't get me started on Fydor who argued the GPLv2 covered the XML output of his program, not just the program and code itself.)  I'm just confused why you'd post code publicly related to work you intend to apparently patent while doing so under an undefined license.

 

Anyways, I should point out there there is a Version 1 GPL, which someone who just comes across your repo on github without the knowledge in this thread might confuse as your intent since that's the original.  Almost nobody uses that anymore (it's been deprecated) which is why I assumed you were talking about v2 or v3.  Stranger things have happened.

 

Anyways, the GNU Project has a pretty good explainer on the differences between the two major versions, it's probably worth taking a read: https://www.gnu.org/...e-gplv3.en.html

 

Of course, if you don't have a strong opinion, it is totally acceptable to dual-license the code under the GPLv2 and v3.  Then users can pick which works best for them.  Also, I should point out that latest version of GPLv2 now has an optional "or later" clause which allows GPLv2 to be "upgraded" to v3.  This is important because the two licenses are incompatible.



#13 n-dtech.com

n-dtech.com

    Lift Off

  • -----
  • Vendors
  • topic starter
  • Posts: 19
  • Joined: 13 Jan 2021
  • Loc: Austin, Texas

Posted 17 January 2021 - 08:23 PM

The IP I'm referring to has little if anything to do with the code. I apologize for being vague, but I don't want to talk myself into a corner. Suffice it to say, your advice has been noted, and I appreciate the feedback.



#14 n-dtech.com

n-dtech.com

    Lift Off

  • -----
  • Vendors
  • topic starter
  • Posts: 19
  • Joined: 13 Jan 2021
  • Loc: Austin, Texas

Posted 18 January 2021 - 07:52 AM

I just realized the PID algorithm was never updated in this version, so I have included as optional files the algorithm I have been using for the past 7 months or so. It may take a bit of finagling to get the new PID algorithm to work with the old code, but it is much improved and particularly suited to high torque setups, due to the addition of damping parameters.

 

https://github.com/T.../pidUpdated.cpp




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics





Also tagged with one or more of these keywords: DIY, equipment, mount



Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics