Automation project

[NickK]

I'm looking to create a system that I can get from stowed to imaging in 10 minutes.

I have a 3/4 ton concrete garden pier, see here, and I have started work on Yet Another Robofocuser for the scope. The next stage is pulling it all together - enter the little embedded computer, the ODROID C2.

Top to bottom: top Arduino Uno (PIC micro controller) with R3 motor shield and stepper motor for the focuser, middle the ODroid Show2 screen (small TFT that takes 60mA) and bottom is the ODroid C2 (ARM quad core 2GHz with 2GB ram). More info here: http://forum.odroid.com/viewtopic.php?f=135&t=19147

You'll note it's passively cooled - no moving parts for a good reason. The entire lot will be mounted on the scope along with two powered USB hubs, SSD for 128GB of secondary storage and a WIFI router. All powered by the PSU or battery.

It will be running VNC connected ubuntu desktop with kstars, Ekos and INDI with the cloud maker's drivers.

Attached via the hubs will be: NEQ6, ATIK cameras (titan, 383L, 414ex, 16ic), then via i2c it will connect to the ardunio Uno acting to control the stepper motors on the scopes for focusing. The small TFT screen is too slow/small for displaying a desktop but will be used for displaying diagnostics/menus etc as it has three LEDs and 3 push buttons.

Here's the VNC desktop. Although it will run faster updates via the HDMI connecting to a TV. 

My idea is to put the astrometry.net indices and run it locally on the C2 for plate solving giving a system that can polar align, setup slew alignments and target identify by using plate solving.

 

[NickK]

383L now working!

If you use the C2 with 64bit kernel with cloud maker's atik drivers, you'll need to download a 32bit libcfitsio.so deb package and manually extract, create a symbolic link, export LD_LIBRARY_PATH=. then run the indi_atik_ccd from the current directory so that the indi driver picks up the 32bit version of the library.

[NickK]

Hmm seems they think my C2 has the 'cold solder issue' and to RMA it.. So although it's working the HDMI port doesn't connect well (think put pressure on it).

The good thing is that I just disconnect the eMMC and send back the board.. the next board will be back to working by simply adding eMMC again

I've also got a SHOW2.. having some 'interesting' issues with the OSX serial ports (even with the driver installed) so will set that up using the linux VM I have. It's a small slow 2.5" TFT that has the same chip as the Arduino UNO inside it to drive the screen-  infact you can use the Arduino IDE to edit the firmware. My thinking with this is to display a few things like the last guider image (only needs a 1/2 frame/sec) and some stats like the RA/DEC/tracking/guiding status (possibly graph if I can fit that in the 2K memory!) and possibly the focusing. All you need to have a quick look at without opening the the VNC session.

I'm thinking that if I can.. make the apple IR remote work with the C2 board (it has a IR sensor) I can do manual mount slewing and focusing for visual use

 

[NickK]

Here's the TFT image quality

 

My thinking is that I can do an autostretch and output a guider image to it - I had a guider image lying around just to give you and idea of what I'm thinking:

[NickK]

On the VNC side of things between the quad core ARM ODroid C2 running Ubuntu Mate and various clients (MacBook Pro etc) there's a few VNC servers.

My experiences so far on the aarch64 64bit side of the world:

* X11vnc - not managed to try this yet, it seems that the odroid repo has a conflict in the qt5 package against the upcoming graphic drivers. General comments are that it's focused on security.

* tightvncserver - not managed to try this yet, it seems that the odroid repo has a conflict in the qt5 package against the upcoming graphic drivers. General comments are that it's faster than x11vnc, focusing on speed and lightweight.

* vino - I did mange to get this to work, very pain free and using kStars/Ekos sucks about 70% of one of the cores. Higher than I'd really like.

* x2go - This is slightly different in that it like the old x11 DISPLAY export, maintaining the desktop from the X11 commands rather than rendering to a frame buffer and then exporting the frame buffer. Supposedly faster but will check soon..

I do know that HardKernel are working on the 64bit aarch64 GPU drivers - currently the software CPU rendering means it's not as performant as it should be (given the shared CPU/GPU memory model).

 

[NickK]

UBECs have arrived

Top one is a 5V 3A (got three of these) and the other is a dual 12V4A (switchable to 5/6/7.2/12V) and 5V4A. They all take in 7-26V so the idea is that these are sat on the 13.5V main power line and supply all the systems with power. 

[NickK]

The ODroid C2 has a IR receiver on the board - convenient for wireless control - which begs the question: Can I use my Apple Infrared Remote to control Focusing, Slewing etc.

The short answer is Yes.

INDI has a joystick driver that allows joysticks/gamepads to be used to control focusing and other activities.

Linux Infrared Remote Control (LIRC) is a package that supports a wide range of remote controls by itself and allows both scripting and application API integration.

Update the joystick driver to use LIRC and you have IR Remote capability.

[NickK]

indi_getprop

 

	Telescope Simulator.CONNECTION.CONNECT=Off
	Telescope Simulator.CONNECTION.DISCONNECT=On
	Telescope Simulator.DRIVER_INFO.DRIVER_NAME=Telescope Simulator
	Telescope Simulator.DRIVER_INFO.DRIVER_EXEC=indi_simulator_telescope
	Telescope Simulator.DRIVER_INFO.DRIVER_VERSION=1.0
	Telescope Simulator.DRIVER_INFO.DRIVER_INTERFACE=5
	Telescope Simulator.DEBUG.ENABLE=Off
	Telescope Simulator.DEBUG.DISABLE=On
	Telescope Simulator.CONFIG_PROCESS.CONFIG_LOAD=Off
	Telescope Simulator.CONFIG_PROCESS.CONFIG_SAVE=Off
	Telescope Simulator.CONFIG_PROCESS.CONFIG_DEFAULT=Off
	Telescope Simulator.DEVICE_PORT.PORT=/dev/ttyUSB0
	Telescope Simulator.TELESCOPE_BAUD_RATE.9600=On
	Telescope Simulator.TELESCOPE_BAUD_RATE.19200=Off
	Telescope Simulator.TELESCOPE_BAUD_RATE.38400=Off
	Telescope Simulator.TELESCOPE_BAUD_RATE.57600=Off
	Telescope Simulator.TELESCOPE_BAUD_RATE.115200=Off
	Telescope Simulator.TELESCOPE_BAUD_RATE.230400=Off
	Telescope Simulator.DEVICE_PORT.PORT=/dev/ttyUSB0
	Telescope Simulator.TELESCOPE_BAUD_RATE.9600=On
	Telescope Simulator.TELESCOPE_BAUD_RATE.19200=Off
	Telescope Simulator.TELESCOPE_BAUD_RATE.38400=Off
	Telescope Simulator.TELESCOPE_BAUD_RATE.57600=Off
	Telescope Simulator.TELESCOPE_BAUD_RATE.115200=Off
	Telescope Simulator.TELESCOPE_BAUD_RATE.230400=Off
	ATIK Wheel.CONNECTION.CONNECT=Off
	ATIK Wheel.CONNECTION.DISCONNECT=On
	ATIK Wheel.DRIVER_INFO.DRIVER_NAME=ATIK Wheel
	ATIK Wheel.DRIVER_INFO.DRIVER_EXEC=indi_atik_wheel
	ATIK Wheel.DRIVER_INFO.DRIVER_VERSION=1.1
	ATIK Wheel.DRIVER_INFO.DRIVER_INTERFACE=16
	ATIK Wheel.CONFIG_PROCESS.CONFIG_LOAD=Off
	ATIK Wheel.CONFIG_PROCESS.CONFIG_SAVE=Off
	ATIK Wheel.CONFIG_PROCESS.CONFIG_DEFAULT=Off
	 
	

 

So it looks like only when the device is connected do properties get exposed. This means that a script or an application client can pull information back..

 

[NickK]

The main control box is taking shape

This houses the SSD (back), the ODroid C2 middle (in antistatic atm) and the ODroid SHOW2 attached to the front transparent cover. 

I will use the same 4 connection locking connector that I used to mod my NEQ6 with for power to supply the 12-13.5V into the box. A UBEC in the box will then provide the down voltage to 5V for the electronics.

As small alloy box will contain the Arduino, DRV8825 stepper driver and the 13.5-12V4A/5V4A UBEC. I will run a 5V line off that UBEC to a hub to provide power this will use a similar screw connector but with only 2 lines to prevent the wrong connection of 13.5V into 5V..

 

[NickK]

Minor change of plan - I've tested the large UBEC and it's not pumping any heat out, so I've decided to move it to the main box from the focuser box. This makes it easier to have a single power switch on the main box - I'd like the power switch to control the entire power in the system - including the camera power. Although I may break that out into a separate small box.   

The fun with a project like this is fitting all the components - when their cables are USB etc they all have a minimum distance. In fact I think the 13.5V power in will actually plug in from behind. The box will be mounted along side the scope so this would be near the axis of the mount.

The external powered hubs give the option to unplug both and connect to the laptop if required.

Only one minor issue with the 5V4A UBECs.. and it would go down well at a star party..

 

Top one layer of green electrical tap.. bottom nude.. in the end I've got two layers of electrical tape on the end to reduce the brightness!

 

[NickK]

All power wiring done, just need some smaller USB data cables and we're away...

Press the silver button... both 5V UBECs light green, main UBEC 12V/5V powers up and beeps it's alarm to test.. the ODroid SHOW2 TFT boots and says Hello.. the ODroid C2 boots... and the focuser boots..

[NickK]

In the dark... The bright blue USB cable will be replaced with something non glowing however it's useful to check things are powered.

The laptop screen shows the remote desktop into the little Odroid C2 running Kstars.

[NickK]

Well at the moment my automation efforts have been thwarted by the C2's 64bit ubuntu-mate... in short Odroid have the same mali-fbdev package that causes a conflict clash in the dependences. So I can't install or uninstall kstars standard version to get to bleeding edge development. On the good side of this in a couple of weeks time they will have the 64bit mali GPU drivers done.. which means it will be more efficient and faster still.

I've been looking at the long list of things I want todo

DONE 1. Kstars + INDI on the C2 is the top priority - 64bit version compiled, includes running 64bit EQMOD mount, ATIK 32bit drivers, and 64 bit Moonlite focuser
DONE 2. short USB leads for inside wiring - I'll take an existing long USB lead and chop it up into smaller leads and add the USB plugs.
ORDERED 3. Ethernet external port - the same as the USB port but for Ethernet.
IN PROGRESS 4. Mounting hardware bracket for the main box and focuser - this will be ahead of the mount axis to provide some balancing.
IN PROGRESS 5. Status pages and guider image display on the small 3.2" TFT - this is over a serial link so it's not too difficult. Annoyingly they didn't build the CP210x drivers into the kernel modules..
6. shorten the power leads inside to make more room.

7. 64bit ATIK INDI on the C2 drivers - I have had these working as a remote INDI service but getting the local kstars server working would mean the system is faster still, but test with Ekos bleeding edge first
8. INDI Yet Another Robo-Focuser (YARF) INDI driver currently YARF works with the existing Moonlite focuser driver which doesn't understand limit switches - not a problem at the moment but a nice to have.
IN PROGRESS 9. X2GO installation for 64bit C2 - this is a very fast remote desktop system. - it connects but then exists due to a bug in their code.. so hopefully they fix it soon..
10. Infrared Remote driver for INDI allowing your old TV remote to be used (and old apple IR remotes) to control functions such as focus and slew or even menus on the status. I'll probably extend the IR sensor off the main C2 board and into a clear window on the case pointing back towards the cameras.

EDITS - update the list progress..

Interesting that GPSd is supported on the EQMOD mount.... so I can connect my garmin Geko 301

[DHEB]

This thread is amazing! Watching your progress with attention!

[NickK]

The last couple of days has seen both banging heads and finally getting somewhere.

1. I managed to solve the problem with the ubuntu apt installation system that was broken by the developers.. using dpkg as a sledgehammer solved the problem.

2. Managed to get x2go server installed but current state is that it connects and a bug on the ubuntu mate/server side causes the connection to be terminated.

3. Short usb wiring - well that's going to be a £1 usb cable cut down to size and re-plugged..

4. ethernet external port - it seems that Farnell/RS do that ..so I see an order in the future..

5. Installing Kstars-bleeding on aarch64 native.. well it's armhf (32bit) build as standard. So I've been getting the dependencies installed (no mean feet as the kf5init-dev package is no longer in existence).. I've now got to the stage I have a C2 64bit indi build and solved the missing dependencies issues.. by installing the entire 64bit KDE framework that is now hogging my drive.. the first attempt at make -j4 to make in parallel resulted in an C++ internal compiler error which may have been memory issues as the C2 has 2GB so I'm now compiling in serial.. *yawn*  The reason for this is that once you start installing 32bits the dependencies need to be 32bit and so in the end you end up with a 32bit system missing the reason for having the ARM v8..

 

 

 

[NickK]

So.. pictures say 1000 words.. well this one says - native 64bit ARM v8 C2 kstars/ekos/indi build  This is a debug build so a little slower than the normal performance release build but still very usable.

Although the C2's model of ARM chip only supports 2GB of memory, the v8 arm chip has wider registers and more instructions which results in a performance increase.

[NickK]

Performance is decent too for a debug build.. even through a vino VNC remote desktop! Moving the star map around is about 30% of one core (the C2 ARM is quad core). Then the VNC remote desktop takes about 50%.

Only thing now todo is to compile the 3rd party drivers.. including EQMOD (the mount) and a couple of others.

If I can't get a 32bit indiserver running beside the 64bit installation then I will need to look at how I can get ATIK onto 64bit.

 

[ChrisLX200]

I noted an email I received from PixInsight team, it seems they are moving into device control using INDI and with a functional server (like yours) it could prove to be very useful:

.oOo.

We are excited to announce the release of a new PixInsight module: INDIClient, an open-source, multiplatform INDI client available on FreeBSD, Linux, OS X, and Windows. The new module is now being distributed as an official update for the latest PixInsight 1.8.4 versions.

The INDIClient project has been created by Klaus Kretzschmar, a German software developer and a member of the PixInsight GitHub team. This is undoubtedly one of the most important milestones in the history of PixInsight development. INDIClient opens a door to hardware control support on the PixInsight platform, and you can bet we are going to open this door completely and go in.

Although this initial version includes just a device controller and a CCD/DSLR frame acquisition tool, it is just the beginning. Think of this first release as a functional proof of concept, just to demonstrate what we are working on and how we are doing it. The roadmap for INDIClient development in the short-medium term includes the following tools, by priority order:

   - Camera control

   - Mount/telescope control

   - Focuser control and autofocus

   - Autoguiding

Of course, all of these tools will be, as are the device controller and frame acquisition tools right now, fully scriptable in JavaScript from the PixInsight Core application.

INDIClient is an open-source project available on PixInsight's GitHub repositories:

   https://github.com/PixInsight/PCL/tree/master/src/modules/processes/contrib/kkretzschmar/INDIClient

If you are a software developer and would like to contribute, please contact us. If you can't or don't want to contribute with code, but have suggestions or ideas to improve our development, please also let us know. This exciting project can benefit from the collaboration and help of all PixInsight users.

For the latest detailed information on the INDIClient module, see the official announcement thread on PixInsight Forum:

   http://pixinsight.com/forum/index.php?topic=9852.0

We want to say a huge thanks to Klaus Kretzschmar for his initiative in creating this important project. Thanks also to all PixInsight users and supporters who help us keep the PixInsight project alive and relevant to the astronomy community.

The PixInsight Team at Pleiades Astrophoto

__________________________________________

 

 

ChrisH

[NickK]

2 minutes ago, ChrisLX200 said:

I noted an email I received from PixInsight team, it seems they are moving into device control using INDI and with a functional server (like yours) it could prove to be very useful:

.oOo.

We are excited to announce the release of a new PixInsight module: INDIClient, an open-source, multiplatform INDI client available on FreeBSD, Linux, OS X, and Windows. The new module is now being distributed as an official update for the latest PixInsight 1.8.4 versions.

The INDIClient project has been created by Klaus Kretzschmar, a German software developer and a member of the PixInsight GitHub team. This is undoubtedly one of the most important milestones in the history of PixInsight development. INDIClient opens a door to hardware control support on the PixInsight platform, and you can bet we are going to open this door completely and go in.

Although this initial version includes just a device controller and a CCD/DSLR frame acquisition tool, it is just the beginning. Think of this first release as a functional proof of concept, just to demonstrate what we are working on and how we are doing it. The roadmap for INDIClient development in the short-medium term includes the following tools, by priority order:

   - Camera control

   - Mount/telescope control

   - Focuser control and autofocus

   - Autoguiding

Of course, all of these tools will be, as are the device controller and frame acquisition tools right now, fully scriptable in JavaScript from the PixInsight Core application.

INDIClient is an open-source project available on PixInsight's GitHub repositories:

   https://github.com/PixInsight/PCL/tree/master/src/modules/processes/contrib/kkretzschmar/INDIClient

If you are a software developer and would like to contribute, please contact us. If you can't or don't want to contribute with code, but have suggestions or ideas to improve our development, please also let us know. This exciting project can benefit from the collaboration and help of all PixInsight users.

For the latest detailed information on the INDIClient module, see the official announcement thread on PixInsight Forum:

   http://pixinsight.com/forum/index.php?topic=9852.0

We want to say a huge thanks to Klaus Kretzschmar for his initiative in creating this important project. Thanks also to all PixInsight users and supporters who help us keep the PixInsight project alive and relevant to the astronomy community.

The PixInsight Team at Pleiades Astrophoto

__________________________________________

 

 

ChrisH

Yup - I saw that last night

The main issue I have is architecture. 

PI is x86/x86_64 and it's speed is based around the hand coding of some SSE style processing along with having multiple cores, large amounts of memory etc. The C2 has a quad core ARM v8 but is limited to 2GB ram. It may be worth me explaining the components of the kstars/indi setup for readers that have not come across it.

Kstars - this is the desktop app like stellarium. It provides a the GUI scroll and click plus the menu/profiles options to easily manage Ekos and INDI. You can point at a target then say "track this" etc.

Ekos - this is the sub application inside kstars that provides astrophotography support - including automated schedules, mount polar alignment (using astrometry), target acquisition (again using astrometry), guided star tracking and also automated focusing that can be done between the exposures etc.

These two components have typically run on the linux desktop PC with either Ekos running an internal or attaching to a remote INDI server.

INDI - think of this as 'indiserver' managing the indi device drivers as ASCOM does however it can run locally to the kstars/ekos install or it can be run on a seperate system and operated remotely.

 

The PI architecture will run on your Intel PC then connect directly to INDI's local or remote indiserver. The announcement means they are looking to move into the space that kstars/ekos sits.

The odroid C2 has enough power to run the kstars/ekos/astrometry.net/indi all in the same little box allowing you to connect in form any computer and use it's desktop without needing a bulky laptop hanging around or being powered all the time. It's possible that the C2 indi server can be used remotely and support the PI with this new functionality running on the macbook. Not bad for a $40 C2.. (a little bit more if you get the faster eMMC storage). If anyone is interested in the C2 please don't be afraid to ask. I would recommend it and I would recommend that you get at least a 16GB eMMC for it's at least 2-5x the speed of the SD card option.

The MBP I have is a 8 core i7 with 16GB and discrete GPU with it's own memory.. it does outperform the ARM. However that's not surprising and will still be used for the post processing of images.

[NickK]

Actually there is ONE annoying thing with the C2.. there's no realtime clock (so you need to net-sync the clock each time) as the ARM chip doesn't have it.

However I know that odroid are creating an inexpensive realtime clock that uses a battery to maintain it.. once installed the system will remember the time..

I'd like to add my Garmin GPS too.. there's a linux GPS package that knows how to interact with many forms of GPS and a driver could be written for INDI using that package..

[NickK]

Thinking about the PI announcement more.. I do hope that they feedback improvements of INDI back to INDI itself.

I see on the code that the guy has duplicated some of the INDI code into his own repository.. so I hope that we don't see divergent INDI forks appearing.

 

[Gina]

I'm seriously considering going over to Linux for imaging software - I'm fed up with the unreliability of Windoze.  But although I have some experience of Linux I have some trepidation in changing over.  Maybe I could take it in stages eg. get a tracking setup going first to control the EQ8.  Unfortunately, I have noticed a reduction in "the little grey cells" over the years and I'm not as good at getting my brain round complicated things as I used to be.

[NickK]

2 hours ago, Gina said:

I'm seriously considering going over to Linux for imaging software - I'm fed up with the unreliability of Windoze.  But although I have some experience of Linux I have some trepidation in changing over.  Maybe I could take it in stages eg. get a tracking setup going first to control the EQ8.  Unfortunately, I have noticed a reduction in "the little grey cells" over the years and I'm not as good at getting my brain round complicated things as I used to be.

It seems that kstars/indi is developed on the debian distribution using KDE (very popular windowing system).

The main irritation with linux is the package dependencies. A needs B that needs C etc. With the tools out there all called different things - each distribution has it's own package management tool.

When you install the distribution they have a set known (and trusted) binary/source repositories set up for the tool - each hold a list of packages you can install quickly without needing to compile anything by hand. You can add additional repositories (repos) and expand your 'universe' of packages but 90% of people don't need todo that.

Installing on ubuntu uses debian packages so it's all through the tool "apt" (aptitude) which is the package manager. However with the C2 odroid it's a new architecture so it's growing in support hence some issues. 32bit is very well supported. To upgrade your ubuntu it's as easy as "sudo apt-get dist-upgrade" (i.e. moving ubuntu v14 to v16) or update your existing system to newer versions ("sudo apt-get update").

You can remove packages too to make space..

I found in the past the big difficulty I had was around the package dependencies because I'd develop and install new software not in the repositories.

To install kstars and indi?

sudo apt-get install kstars

sudo apt-get install indi-full

The standard builds work and are available through the ubuntu package repository directly - you don't need to play around in the same way as I had to. Arduino IDE is a matter of "sudo apt-get install arduino"

There's even a virtual machine image "build" that INDI provide so you can down load that and it has linux, ubuntu and kstars, indi + all the drivers etc installed.. no mess, no pulling hair out just run in your virtual machine on your windows box. It means it's all neat and contained in it's own bubble, but you can set it up so that the VM can access the directory on the host machine to store captured images. This may be your best choice to test with a toe in the water.

 

The C2 has a eMMC solid state disk (literally a chip) that plugs into the underside of the board. I use that for the OS and apps then use an external USB SSD for the astrometry index (32GB) and as an intermediate capture location before offloading to the laptop.

[NickK]

I've also managed to build the 3rd party drivers for indi - including eqmod mount. Only issue I had compiling is with the ASICAM driver that wouldn't compile due to needing a library I think.

However I've noted a couple of runtime issues I'll be reporting - double free and an issue with the standard moonlite focuser driver I'm looking to use initially for my focuser.

[NickK]

Finally got the 3rd party drivers working.. it appears that the standard ubuntu mate install runtime linter doesn't attempt to look at the stored shared library paths defined at compile/link time but rather uses LD_LIBRARY_PATH.. 

So set that and provide the 32bit libcfitsio for the atik drivers by running a local 'remote' indiserver..