Jump to content


Photo

Open Source Mount Control Suite

  • Please log in to reply
96 replies to this topic

#76 Alph

Alph

    Surveyor 1

  • -----
  • Posts: 1755
  • Joined: 23 Nov 2006
  • Loc: Melmac

Posted 27 July 2013 - 11:18 PM

The current ASCOM guy who responded, Chris, expressed willingness, in fact desire, to do a cross-platform version; they just don't know how.



A dynamically or statically linked library written in plain old C would do the trick. Most programming/runtime platforms (except JavaScript within a browser, and VBScript) would be able to use such a library. VBScript would require a COM wrapper and JavaScript would require JSON over HTTP and a server process.

#77 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5362
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 28 July 2013 - 01:30 AM

I am also of the opinion that something like JSON over HTTP is a better choice than yet another XML encapsulation.

That said.. the current state of software development on non-Windows platforms is simply horrific. With ASCOM you have a small group of people controlling the direction, with UNIX you have nobody. A disparate group of people are all writing their own software, in many cases duplicating each other's work...

and much of the existing software only aims to ape the Windows functionality.. including its dependence on a high-resolution screen, mouse, etc. Not very useful for my desire for a headless controller.

What I want is something that was done at UC Berkeley 15+ years ago - http://astro.berkele.../telescope.html

That also said, it seems that the more telescope equipment vendors start exposing their devices via HTTP - such as the SBIG STF/STT - the better. QHY also already has one such model, the IC8300. This does add cost (you're basically putting a small BeagleBone-class processor on every device to handle the TCP/IP and HTTP stuff).

#78 cn register 5

cn register 5

    Viking 1

  • -----
  • Posts: 760
  • Joined: 26 Dec 2012

Posted 28 July 2013 - 04:32 AM

The fundamental reason ASCOM uses COM is to for the scripting support, otherwise, as Alph says, dlls would do.

We would love to have more people actively involved in developing ASCOM but it's very difficult to get them. We can't even get people to test beta software.

We value stability very highly, maybe too highly, but being backward compatible is probably one of the strengths of ASCOM

Orlando's idea of a series of separate programs all communicating with the mount hardware has the challenge of getting multiple applications to connect to the same serial port at the same time. What you end up with is a single mount-specific process that handles all the mount control and exposes a common interface for other applications or scripts to use. That's all that ASCOM does.

It would be quite easy to map the existing ASCOM specifications to some text based protocol that could go over any connection that supports strings with terminators. My preference is for a CSV format, something like:
send "get,RightAscension\r"
receive "get,RightAscension,15.765\r"
This sort of thing can map directly onto the existing ASCOM protocol.

Each platform could write shims that converted the programming interface of their choice to and from this line protocol.

The discovery and selection of drivers over a network will be a challenge.

It's the state of development and support on non-windows platforms that puts me off getting involved in it.

Chris

#79 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5362
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 28 July 2013 - 10:49 AM

Chris - you're right. The fragmented nature of development on non-Windows platforms is a complete :tonofbricks:

Of course it is unreasonable to expect equipment vendors to support non-Intel platforms; the fact that they support Linux Intel is already a significant concession on their part.

#80 Alph

Alph

    Surveyor 1

  • -----
  • Posts: 1755
  • Joined: 23 Nov 2006
  • Loc: Melmac

Posted 28 July 2013 - 11:33 AM

Chris - you're right. The fragmented nature of development on non-Windows platforms is a complete :tonofbricks:

Of course it is unreasonable to expect equipment vendors to support non-Intel platforms; the fact that they support Linux Intel is already a significant concession on their part.


I am not sure what you mean by all that. You can use Eclipse on Windows, Linux, Android and other OS’s. Millions of apps for Android and iOS and millions of web applications prove that it is possible to develop without Visual Studio, VB6, and/or .NET. I have a feeling that ASCOM guys are stuck in a time warp. They will have to bite the bullet and learn new techniques or ASCOM will be doomed if it is not already. Look at the latest browser statistics and trends. Microsoft is just one of the players and it is not the most important one anymore.

http://www.w3schools...wsers_stats.asp

#81 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5510
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 28 July 2013 - 11:56 AM

I have encountered http visible hardware before in Newport motion control stages. The controller shows up directly in browsers if you hit its address on the TCP/IP network (they connect to ethernet directly in that case). It transmits an html page which shows all of its parameters in plain text and has boxes for adjusting values manually, which also tell the address for any control program you are using to reach out and touch to get automatic responses, as well as what addresses to ping to get data outputs. Note, since it is a standard page, you can automatically set up the stage if you pay attention to how it's formatted.

Of course, it's deep in proprietary territory, but it serves as a sort of style guide for what may be made to work, here. It does seem to me there needs to be a mechanism to do this at the mount in the near term. There are quite a few drives which are wirelessly enabled these days. And all we are talking about really is having the ability to push and pull data off of something. Perhaps something like that could be a model for doing this.

-Rich

#82 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5362
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 28 July 2013 - 12:09 PM

Alph, what I meant is the nature of astronomical drivers and software for amateur astronomy on non-Windows platforms. Not development on non-Windows, that's self-evident.

The astronomy vendors aren't really interested in supporting non-Intel platforms (Windows, Linux, and OS X are all Intel these days). If you've looked through the state of the various open-source projects attempting to support CCDs and mounts, do autoguiding, etc. the support is very patchy and uneven.

I think this is because the astronomy hobby is small enough, and non-Windows is a tiny fraction of that.

I think this thread is wandering all over..

Do we want:

1) open-source platform for existing CCDs, focusers, and mounts, or...

2) an open-source mount firmware?

#83 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5510
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 28 July 2013 - 12:15 PM

I would suggest the full-up computer model is still firmly in place, though it is more because of historical reasons now than the installed base, which was the reason when it came about. ASCOM was obviously the way to go when the only thing most people could be counted on having was a PC. Now that has changed- the mobile stuff is far more common, to the point where deciding on what to do isn't really that obviously a computer answer. Look at what is being done with those little Parrot quad-rotor aircraft- they wirelessly support flight control, two channels of video, and automatic goal recognition onboard, and no computer is in the loop.

http://ardrone2.parrot.com/

-Rich

#84 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5362
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 28 July 2013 - 01:40 PM

But the thing is RC aircraft and quad-rotors are far more popular than astronomy.. and the cost of entry is much lower as well. Plus, a lot of equipment such as MEMS gyros and accelerometers, which are very useful for these drones, are dirt-cheap due to their use in smartphones.

I can't see anything (except SkySafari) from the smartphone revolution that directly benefits astronomy...

#85 cn register 5

cn register 5

    Viking 1

  • -----
  • Posts: 760
  • Joined: 26 Dec 2012

Posted 28 July 2013 - 03:10 PM

I'm using an electronic compass module as an azimuth sensor for a dome.

Meade's LS technology must use level sensors and compasses similar to what's in a smartphone.

And lots of scopes use GPS modules.

The revolution that's just starting with the Raspberry Pi and BeagleBone is to some extent driven by the smartphone world demanding vast amounts of computing and graphics processing at a low cost in terms of power and price.

The problem I see is that the smartphone technology has raised exceptions, possibly unrealistically. The cost of development is almost fixed and it makes a big difference if you can spread that cost over millions of phones or thousands of scopes.

Chris

#86 pfile

pfile

    Gemini

  • -----
  • Posts: 3163
  • Joined: 14 Jun 2009

Posted 29 July 2013 - 02:25 AM

i wonder what software the iTelescope people are using. watching a run play out in the console, it sure looks like unix/linux. maybe they wrote their own stuff...?

#87 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5362
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 29 July 2013 - 03:07 AM

iTelescope = GRAS.

I used their system extensively for my astronomy postgrad work when I couldn't get data myself due to weather.

It is Windows based, and is using TheSkyX. Pretty much a no-brainer considering that they are an all-Software Bisque house.

#88 pfile

pfile

    Gemini

  • -----
  • Posts: 3163
  • Joined: 14 Jun 2009

Posted 29 July 2013 - 02:28 PM

interesting, the console sure looked like unix-based stuff. perhaps that's just their scheduler rather than the actual telescope/camera control. i've only used it once or twice.

#89 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5362
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 29 July 2013 - 10:05 PM

The guiding output messages in the web GUI are exactly the same as the guiding output messages in MaximDL - because it is MaximDL. Post-processing of the images after capture is also done with MaximDL.

I believe the scripting is done with VB.

#90 pfile

pfile

    Gemini

  • -----
  • Posts: 3163
  • Joined: 14 Jun 2009

Posted 29 July 2013 - 11:15 PM

okay, i believe you, it just had a very unix-y feel. not used to seeing that kind of console output in any windows program. been using unix since bsd 4.2, and basically know zero about windows :)

#91 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5510
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 30 July 2013 - 10:39 PM

SkySafari is indeed pretty cool. I've been looking at the Astro Devices Nexus and BETI with a mind to use with straight encoders. The lack of a drive makes for low power consumption. Still not a route to what we have been talking, but its in the right direction.

-Rich

#92 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5362
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 30 July 2013 - 11:04 PM

Skysafari + Nexus is a good solution for those of us with old, non-GoTo, encoder-equipped mounts.

The Skysafari folks have also stated that they can look into a multi-star modeling algorithm instead of the current two-star (for the next version). This would put their pointing algorithm on a par with Argo Navis and improve pointing accuracy.

It does not address the issue of automation though.

I think supporting existing mounts is not a problem, so long as the mount communicates via a well-known protocol over serial or IP.

It's the cameras which are the issue. The good news is I found some old code for the QHY8 and passed it to the developer of CCD - https://sourceforge.net/projects/cccd/ - (who also wrote Lin_Guider).

Since there are so many projects out there scratching various itches, one has to choose one. Anat chose to support CCD, Lin_Guider, INDI, and astrometry.net for his stand-alone controller solution based on an Android mini-PC.

since he spent 3 years working on that (and he has a Ph.D.!) i won't duplicate the work - all I've done is work towards support for my camera in CCD. Eventually other cameras may be supported.. I know if I get another camera I would also work towards having it supported in CCD.

#93 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5510
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 31 July 2013 - 09:31 AM

If the hobby were larger, that approach would get things supported pretty quickly. Then again, another way to approach it is back white this sort of project to make a common camera support cape come into being. So far, that's pretty hard, though things like written out SD cards with images in recognizable formats are immediately recognizable to computers. So, that does make it a little bit of a stupid question- why can't the file generator be so easily dealt with?

-Rich

#94 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5362
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 31 July 2013 - 09:41 AM

well you have to write a FITS. which means you need to have a decent processor on the camera. that is definitely the direction (SBIG STT, QHY IC8300) but it will take a while, I guess..

#95 Starhawk

Starhawk

    Space Ranger

  • *****
  • Posts: 5510
  • Joined: 16 Sep 2008
  • Loc: Tucson, Arizona

Posted 01 August 2013 - 09:51 PM

Lots of stuff writes RAW formats, and also output a jpeg. The data for alignment and such isn't in the 16 bit signal to noise ratio of 1.1 regime. So, what about trying to do something with that?

-Rich

#96 orlyandico

orlyandico

    Fly Me to the Moon

  • *****
  • Posts: 5362
  • Joined: 10 Aug 2009
  • Loc: Singapore

Posted 02 August 2013 - 09:39 AM

Intel weighs in with their own BeagleBoard-alike. Made by the same company that makes the BeagleBoard:

http://www.tomshardw...Pi-Atom-E640...

it costs $200 though :(

As an aside, I got Astrometry blind plate solving working on my Bone. It takes 43 seconds to solve one 6MP image from the QHY8!!! and 15 seconds to solve a 4x4 binned image.

So building a pointing model with this thing would be... slow. An Odroid U2 is $90 though and has a quad-core ARM Cortex-A9. Certainly more powerful than the $200 single-core Intel board.

#97 visaman

visaman

    Lift Off

  • -----
  • Posts: 15
  • Joined: 10 Sep 2013

Posted 26 October 2013 - 04:48 AM

http://www.cloudynig...6158261/page...






Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics