Fired? As in a kiln or a bonfire?
I would say Martin Wimpress is a pretty important cog in the wheel. He is one of the co founders of Ubuntu MATE and now leads the project. More significantly for us, Wimpress is pretty much the only one working on Ubuntu MATE's Pi support and he can only work on that when Canonical doesnt have him doing all sorts of other things. It was a lack of his time as well as some technical issues that made the Pi3b+ ubuntu mate image take so long to get out. I am sure he would love some help. . .
I am not 100 percent sure, since I haven’t tried it before, but I know how it *should* work
The first issue you will probably have is that both focusers will look the same to the OS and it won’t be able to tell the difference between them. They will probably get assigned names based on the order they get plugged in. The rules files are how a Linux system responds when the device gets plugged in and is how we keep our devices separate in INDI so we don’t tell our focuser to slew and our telescope to focus. What you want is a rules file that will recognize each focuser and assign each one the same unique port name each time. Unfortunately the focusers have the same manufacturer id so the usual method of writing a rules file identifying the device based on that number won’t work. The serial number might be different in which case you could try to use that in a custom rules file. But that might not work. If that doesn’t work, you can set aside a usb port for each one and only ever plug that focuser into that port. So your rules file could see that a device got plugged into that port and assume it is that particular focuser. I would definitely try to solve this problem first so that each time you plug in focuser 1 or focuser 2 they get the correct name.
The second problem is with the driver. The Moonlite driver would have all the settings of and be associated with one Moonlite focuser, not both. To fix that you need to use the “custom drivers” feature and call each focuser by a unique driver name and associate each one with the unique port name I discussed in the previous paragraph. This problem is easy to fix because Ekos has a great custom drivers tool.
Then it should work
So I would definitely recommend making sure everything works with simulators before going out in the field.
I can’t do much at the moment because I am on vacation right now and don’t have very good internet, which is why it has taken me awhile to respond. But I will be able to do more after the 14th of July.
I would like to know why the automated installer failed to install astropy, because it should have worked unless you have something odd about your python installation.
I would recommend checking to see that it works now using the ccd and telescope simulators in offline mode. If it doesn’t, check to see that the index files are installed gsc is installed, and where python3 is installed. If there is a problem, Ekos should print the error messages to the log now because I changed it. You should not have to paste the commands to terminal anymore.
At the command line, it should be either
pip install astropy
pip3 install astropy
What happens when you either type
Correct, this is not an error. It is a change I had to make due to some issues I had with python. I used to bundle a stripped down version of python inside the app bundle, but that no longer seems to be a good option since it isn’t reliable if you build it on a new system. So basically now you have to install python on your system. I wrote an installer as Peter described that will do all this for you. It is all explained in the quick start pdf.
I do not understand what you mean. There is no virtual environment. Astrometry.net natively compiles on Mac computers, my computer is an actual Mac OS X computer running Mac OS Mojave, the latest version. I compile it on my system and it works perfectly on my computer. No virtual environment needed
So in the latest version of KStars, yes the astrometry binaries and Netpbm are still in the package. They are NOT broken. They should work just fine on most systems (with a few notable exceptions that I don’t yet understand). The main issue for astrometry on macs is python. Currently the solution is to install python 3 and astropy with homebrew or some other way (you can use the installer I wrote and put into kstars) and then the embedded astrometry should work great. If it does not , then install astrometry.net with homebrew.
The issue was that while python is installed by default on macs, it is an older version of python 2 that requires administrator permissions to install packages. Python 3 is desirable for astrometry today. The best way to install that seems to be homebrew. Awhile back I had managed to get a stripped down version of python built on an older computer embedded in the app bundle, which was working for awhile. But building python 3 on a new computer did not work on all other systems properly and there seems to really be no correct way to package it up as far as I can tell. If somebody else can get that working be my guest. I worked for several long days trying to do it and failed. It would not be a good solution to build it on an ancient computer because that is not sustainable.
Homebrew has a very good cross platform way to get python 3 up and running on all systems and they also do a good job with astrometry too.
But Jasem, uploaded and built it successfully two hours ago:
Ok I released a new version, version 1.0. This might be the only version for the next two weeks or so since I will be kind of busy. But this version includes the option to set INDI Web Manager App to start when the system starts, which should be a very useful function for people setting up a remote system that should automatically turn on.
Please test things thoroughly and enjoy the new app.
For OS X, you can get version 1.0 here: github.com/rlancaste/INDIWebManagerApp/releases/tag/1.0
For Linux, it is available from the nightly PPA: launchpad.net/~mutlaqja/+archive/ubuntu/indinightly
For Source Code, it is available on GitHub: github.com/rlancaste/INDIWebManagerApp
Birthdate19. 07. 1980
About meEven though I am relatively young, I have been an astrophotographer for about 20 years. Within the last 5 years or so, I have taken my hobby to new heights. I built my own 10 inch telescope including grinding the mirror, bought a wide field newtonian for wider fields, acquired a much better mount to put them on (separately), got an SBIG camera for cooled CCD photos, modified a Canon XSi for better DSLR photos, and got lots of accessories. I have been doing all of my astrophotography with a Mac computer. I have basically made my own portable observatory, everything is carefully organized into boxes that I can load into my car in about 20 minutes. I take these things to dark skies and do lots of imaging at star parties.
I found out about INDI in May 2016 when Pleiades Astrophoto sent me an email about including an INDI client in their software. When I investigated further, I found out about KStars and Ekos. I quickly realized that I could install everything on a Raspberry Pi, velcro that to my scope, and use VLC to configure it from my computer using wifi. I have implemented 2 modes. The first is using the Raspberry Pi as an INDI server and using my Laptop as a wireless client using either the EKOS VM (running KStars and Ekos) or PixInsight as the client software. The second is using KStars and Ekos on the Raspberry Pi and controlling everything through VNC. Both methods have allowed me to cut the cords, move to WIFI control, and make all USB connections shorter. The second method also allows me to put my computer to sleep after I have configured the PI to do all the work. All I have to do is check in once in awhile to make sure it is working properly. So far this experiment is going very well, but I did have to work out quite a few issues along the way. I have been keeping a couple of logs of everything I have done to make it work, however, which is very useful. There are still a few problems, but the system is fully functional. It is a good thing it is summer so I have time to work on this!
The remarkable part is that you can automate your astrophotography setup, make the connection wireless, simplify the software by just running one program (KStars/Ekos) that runs it all, and you can make the connection to the devices separate from that program using INDIServer. (The last item is important because if KStars/Ekos were to crash, the devices would still be running on INDIServer.) And all of this will cost you around $100 including the Pi, a case, a 32 MB microSD card, the software, and a powered USB hub. There was a bit more work involved in setting it up and figuring it all out, but it was worth it.
I am an:
Physics and Computer Science Teacher
Delaware Astronomical Society Member
Mt. Cuba Observatory Education Associate