INDI

[JamesF]

Has anyone tried/used the INDI platform for controlling mounts, filter wheels etc. at all?

I was looking at it last night and it looks quite interesting. However, whilst the project doesn't appear moribund it doesn't seem massively lively either and it doesn't appear to me as if that's because they've achieved everything that could be done.

James

[AstroTux]

The only INDI I've ever tried was to control an SPC900 from within KStars on a Linux system. It worked quite well but unfortunately I don't have any other kit that is compatible with it. I have to admit that I was looking into it and wondering if I could write drivers to handle some of the projects I have lined up - someday................................. :embarrassed:

[JamesF]

It does seem fairly limited in terms of the hardware it supports which is one of the reasons I get the impression that it's not really making much headway.

Were I starting such a project from scratch I think I'd probably start by layering things on top of dbus (I'd quite like to do that with a home automation setup, too) because a lot of the comms work is already done and it makes life easy to add new clients at any point.

James

[AstroTux]

I'd not thought of that!! But then again, digging into dbus has never been at the top of my list of priorities . I was just glimpsing at INDI in one of those 'maybe I could use this someday' moments.

Alan

[JamesF]

I started looking at dbus because I wanted to be able to take data from various different sources (multiple weather station data streams, for example) and share them between various consumer processes, but I never got further than deciding it was worthy of deeper consideration. It probably helps that I've been a user of UNIX and UNIX-like operating systems for getting on for thirty years, so client-server type architectures integrating with tools rather than monolithic applications very much appeal to my sense of what's right

James

[AstroTux]

Now that you've fired my interest, I think I'll have to have a look at dbus.

Like you I started playing with computers ( if you call working for DEC playing ) well over 30 years ago. Yes, I was the European support focus for their new range of personal computers back in 1982 . Since then I've spent a long time in the Internet field working with traffic shapers, routers, switches, VPN devices, etc., and nearly all of these are based around Unix/Linux so as you can see I am also quite familiar with client/server architectures.

Since moving all my home PCs to Linux over 6 years ago, I've rediscovered the 'joys' of having a real system to play with ( I like command lines - they remind me of VAX/VMS :grin: ) and programming them so they do what I want. Having got the hang of GTK+ and other things, I think I might just branch out and have a look at dbus.

Thanks James,

Alan

[JamesF]

Were you at DEC Park in Reading?

James

[SnakeyJ]

Cheers James and Alan,

Nice to know I'm not the only old and bold tech with fond memories of DEC - worked on lots of VAX and Alphas (alongside some IBM RS6000) mostly running VMS & Mumps and DEC Unix in healthcare. Never quite the same once the batton passed to Compaq then HP - but I know that at least two of these boxes are still running today which says something for the quality. Don't ask me anything on programming though, I was more systems maint and then network - finally killed of the last of the LAT in 2000 after segmenting the networks to L3 IP though not without some hybrid L3 routing and L2 bridging to get there.

Oh for the days when a terminal server ran lat and connected to VT420 terminals - Guess I must be getting a little long in the tooth now.

[AstroTux]

Were you at DEC Park in Reading?

Yup!! Then got moved to Viables in Basingstoke. Don't tell me your someone I used to talk to on the phone????

Alan

[AstroTux]

Oh for the days when a terminal server ran lat and connected to VT420 terminals - Guess I must be getting a little long in the tooth now.

LAT - now that brings back loads of memories.......

[JamesF]

Yup!! Then got moved to Viables in Basingstoke. Don't tell me your someone I used to talk to on the phone????

No My wife worked at DEC when I met her though. I worked in Newbury at the time (and not at Vodafone, shock, horror I vaguely remember working on some of the Alpha boxes at one point as the team I managed did a fair bit of porting work between all sorts of different UNIX platforms.

James

[AstroTux]

No My wife worked at DEC when I met her though.

Sorry to take so long getting back to you, but SWMBO was working late last night and when she gets in I have to drop everything :evil: .

Whereabouts in DEC did your wife work as we may have bumped into each other? Just to give you a time-frame, I started in DEC in 1980 working in a small shack at the back of Huntley & Palmers called V7. We then moved into DEC Park the day it opened and were located near the back end of 'the street' ( a long corridor that ran the length of the building ) on the ground floor. In late 1982 we moved to Viables in Basingstoke. Sometime in 1984 I left DEC to join Rapid Recall, one of their distributors.

Alan

[JamesF]

Ah, that would be before my wife was there. She didn't start until 1990 I think.

James

[AstroTux]

Ah, that would be before my wife was there. She didn't start until 1990 I think.

Ah well, by that time I was working for dear old Racal Datacom and well away from Reading........

Alan

[NickK]

Has anyone tried/used the INDI platform for controlling mounts, filter wheels etc. at all?

I was looking at it last night and it looks quite interesting. However, whilst the project doesn't appear moribund it doesn't seem massively lively either and it doesn't appear to me as if that's because they've achieved everything that could be done.

James

There's also CloudMakers who are creating a commercial implementation of the standard: http://www.cloudmakers.eu/jindi

However for a framework to add value it requires both device drivers and be used by applications for the user to use. The helpfulness of both sets of parties vary wildly!

[JamesF]

There's also CloudMakers who are creating a commercial implementation of the standard: http://www.cloudmakers.eu/jindi

However for a framework to add value it requires both device drivers and be used by applications for the user to use. The helpfulness of both sets of parties vary wildly!

My preference is for open source so I'd probably not touch the commercial implementation given the choice. Either way t still requires all the clients and drivers though and there really doesn't seem to be much of a commitment to those. I wonder if that's because there aren't that many coders who are into astronomy, or vice-versa.

James

[NickK]

My preference is for open source so I'd probably not touch the commercial implementation given the choice. Either way t still requires all the clients and drivers though and there really doesn't seem to be much of a commitment to those. I wonder if that's because there aren't that many coders who are into astronomy, or vice-versa.

James

A developer will only have a portion of kit. Now multiply the number of products out there and then divide by the number of developers that would be prepared to put in the hours to make it usable by all. Further divide that by the number of applications out there that want to use it - people are interested in writing the apps they can sell not the enablers that really bring value to everyone.

If it see YASA (Yet Another Sky Atlas) I'm going to scream.. now why don't people do something useful like make an auto-aligner stacker for "night vision" on top of that atlas that's set behind the atlas.. so you see more in the FoV if the camera is left.

[AstroTux]

I wonder if that's because there aren't that many coders who are into astronomy, or vice-versa.

You've either hit the nail on the head there, or too many of them are still in the grasp of Windoze...... :grin:

Maybe you and I need to put our heads together and write some stuff for INDI for the popular 'scopes and mounts. I've had a look at the support on my systems:

but there is no mention of mounts like EQ5s, etc.

Alan

[JamesF]

Hmmm. Isn't the Orion Atlas the same as (one or more of) the Skywatcher EQ6 variants? That could be a quick bit of code to write

I have a "bigger picture" in mind here. I think it would be great to have all the tools to make an automated observatory in such a way that the control systems can be distributed and share data between multiple applications, without all the clutter of GUIs and all that sort of stuff if necessary. So, for instance, if I have a weather station I'd like to be able to record data in a database, create graphs, upload them to a webserver and so on. I'd also like an indication that it's raining to get routed to various parts of an astroimaging system to stop an imaging run, park the scope, close the observatory roof and so on. It could even trigger dew heaters to be turned on if circumstances warranted it. But on the other hand if I turn all my imaging gear off, I'd still expect the weather station to carry on working and logging its data. There might be other bits, too. Say, an all-sky camera that runs during the night but gets turned off when a sunlight sensor on the weather station says it's getting light, or when some other alarm triggers it because the Sun should be up.

Fundamental to it all though is some sort of application- and hardware-neutral "message brokering" system that allows "information consumers" to "subscribe" to information provided by "information providers" (and of course providers may well be consumers) as well as allowing direct communication between devices if required without prior knowledge of where on the network they are. Perhaps INDI is the way to achieve that. Perhaps dbus is. Or perhaps something else needs to exist (I'm aware of RabbitMQ too, for instance).

This is all a bit vague and jumbled. It's the first time I've actually tried to write down what's in my head

James

[JamesF]

A developer will only have a portion of kit. Now multiply the number of products out there and then divide by the number of developers that would be prepared to put in the hours to make it usable by all. Further divide that by the number of applications out there that want to use it - people are interested in writing the apps they can sell not the enablers that really bring value to everyone.

To a point, yes. But that doesn't explain, for example, Linux (or FreeBSD or any of the other open source BSD variants).

If it see YASA (Yet Another Sky Atlas) I'm going to scream.. now why don't people do something useful like make an auto-aligner stacker for "night vision" on top of that atlas that's set behind the atlas.. so you see more in the FoV if the camera is left.

Agreed. I think we have quite enough of those (far more than necessary, if I'm honest) than are really required.

Of course with Stellarium, Cartes du Ciel and KStars the change you suggest could be made by anyone with the skills and motivation, as they're all open source.

James

[NickK]

To a point, yes. But that doesn't explain, for example, Linux (or FreeBSD or any of the other open source BSD variants).

I may be a bit biased with being a Mac-head.. but supporting multiple distributions can be a nightmare. Not all vendors are happy putting their IPR out as opensource.

[AlexRoman]

Hmmm. Isn't the Orion Atlas the same as (one or more of) the Skywatcher EQ6 variants? That could be a quick bit of code to write

I have a "bigger picture" in mind here. I think it would be great to have all the tools to make an automated observatory in such a way that the control systems can be distributed and share data between multiple applications, without all the clutter of GUIs and all that sort of stuff if necessary. So, for instance, if I have a weather station I'd like to be able to record data in a database, create graphs, upload them to a webserver and so on. I'd also like an indication that it's raining to get routed to various parts of an astroimaging system to stop an imaging run, park the scope, close the observatory roof and so on. It could even trigger dew heaters to be turned on if circumstances warranted it. But on the other hand if I turn all my imaging gear off, I'd still expect the weather station to carry on working and logging its data. There might be other bits, too. Say, an all-sky camera that runs during the night but gets turned off when a sunlight sensor on the weather station says it's getting light, or when some other alarm triggers it because the Sun should be up.

Fundamental to it all though is some sort of application- and hardware-neutral "message brokering" system that allows "information consumers" to "subscribe" to information provided by "information providers" (and of course providers may well be consumers) as well as allowing direct communication between devices if required without prior knowledge of where on the network they are. Perhaps INDI is the way to achieve that. Perhaps dbus is. Or perhaps something else needs to exist (I'm aware of RabbitMQ too, for instance).

This is all a bit vague and jumbled. It's the first time I've actually tried to write down what's in my head

James

Just jumping in here with my first post as I found this thread and believe I have something valuable to add..

In my opinion, the cross-platform and open-source framework for astronomy equipment is INDI. It's already there, it works. Even if something about its underlying communication mechanism is not that efficient or flexible, that can change. But the framework can be kept as is (keeping all existing drivers) and change the underlying mechanism, if needed.

The biggest problem with INDI is that it lacks certain drivers. For example none of my CCDs are supported by INDI as of yet. I have a QHY5V, QHY5-II and QHY9c. I also have a HEQ5 Pro mount which should work with one of the Celestron NexStar protocols as far as I know. I just got the mount set up next to my dev PC so I'll be able to figure it out for sure soon.

Now on to the non-existing drivers. I am in the process of writing drivers for the latter 2 cameras for INDI (have 10+ years of embedded software development experience). I no longer use the 5V because I have a different guide scope and the chip is just too small on the camera.

There probably is a lack of software developer astronomers (or the other way around). Not much can be done about it, except to perhaps try to interest our fellow software developers in astronomy, or vice-versa -- a slow process with no guaranteed results.

That being said, those of us who are interested in both areas can do a great deal to contribute to the state of open source astronomy equipment control software. In the QHY CCD world, there are a number of programs for Linux that can use several QHY cameras and in addition INDI does support the plain QHY5. Why there was no coordinated effort to bring support for these cameras to INDI and use it that way, I cannot fathom. It's rather counter-productive to have to re-implement drivers over and over again. For this reason, I choose to develop my drivers for INDI so that, at least, somebody else can make use of them with whatever software they choose.

I guess what I'm trying to say is that we, astronomer software developers, need to coordinate our efforts and come up with a consistent story when it comes to open source astronomy software. There's just way too many directions people are pulling at it, thus hampering headway. On Windows devs stuck with ASCOM and look at how rich and well supported that platform is. By the way, INDI runs on Windows as well, with support for ASCOM drivers (only on Windows) so there is absolutely no reason for INDI not to take over eventually -- we just need to get our story straight

[NickK]

As a developer I feel when I look at code and to me it feels wrong for the requirements. If you're a long in the tooth developer you'll know what I mean (it's not meant as inflammatory).

[JamesF]

Nice to have this thread woken up again

Can you explain why you think INDI isn't the right way to go, Nick?

James

[NickK]

Hi James, for me it's inefficient and has evolved with the requirements specific requirement for those that have implemented it which also will cause the general use scenarios issues. We switched architecture from V1 to V2 of AOSX for this reason - thinking that the existing frameworks had the right idea.. no they had the idea that was fashionable technically but not what solved the end problem.

Also attempting to support linux is a nightmare - getting the user to install the right packages and not have issues with the dependencies. Now you could write it all as a wrapper..but the valuable time then moves from resolving the astro problem to solving the linux dependency problem (which varies depending on what other packages the user has installed or the development libraries require).

Lastly it's the end user experience - and I'm sad to say linux apps with QT/vxWidget look ugly on all the platforms but natively the GUI development time than the likes of OSX/Win.

I've developed on linux with Java too in commercial high speed environment (lead AT&T SMS network network integration) and in my experience that really is not the way to go. We wrote a bespoke system because the bus/queue technology being touted is too slow. The problem INDI has to solve is not a business problem with business speeds - it's more akin to network packet routing. Have a several 100fps cameras on then look at the problem that way.

The tone above may sound hard but you're talking about the feeling rather than the logic of why the structure is incorrect. To get people involved, for free, requires them to believe in the same goal for the same reasons.