×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

Returning to ASCOM

  • Posts: 36
  • Thank you received: 1

Returning to ASCOM was created by Tim

Thank-you everybody on here who has tried to help me with my dome driver development. I have come to the conclusion that my programming skills are not up to the challenge of developing for INDI which is a shame and to date I have not found enough tutorial resources to help me through the issues. The video tutorials on environment set up for example are so out of date that I could not even get a debugging environment going. So I'll go back to ASCOM now, for which I wrote a pretty good driver and look back in on INDI from time to time to see if the situation has improved.

Tim
3 years 4 months ago #66263

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74

Replied by Clive Stachon on topic Returning to ASCOM

Why doesn't Indi provide basic "generic" drivers for most devices that would allow developers, such as the above, to "bend" there devices to fit. Yes some functions within a driver will have to be dummy actions but providing a generic driver allows quick conversion of existing non Indi devices. Longer term they can then be improved.


Just a thought!
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
3 years 4 months ago #66266

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic Returning to ASCOM

There are many dome drivers available already, all open source. The documentation can definitely use some improvement. Maybe I'll do a video tutorial on this at some point.
3 years 4 months ago #66275

Please Log in or Create an account to join the conversation.

  • Posts: 407
  • Thank you received: 74

Replied by Clive Stachon on topic Returning to ASCOM

Hi Jasem,

I realise there are many drivers (for all sorts of devices) but I was thinking more in the line of a few "Indi Standard" generic devices - one per type maybe - that people can test there devices against before writting a new Indi driver (may not need too as the Standard Generic might be spot on). They may even use the Generic protocol therefore saving more devices to support. Lets face it for example a standard Focuser is a focuser and cant really function very differently even if the "commands" are different . Might also save a lot of unneccessay duplicated documentation which people sometimes hate to do :-).

Again just a thought :-)
RPI3 Ubuntu 16.04 / AMD desktop Kstars under Ubuntu 16.04 Mounts :azeq6 ,SWAZGoTo

RPI3 Fedora testing out on AMD desktop Fedpra 28 - running kstars 2.9.4 , Indilib 1.7.4 ?????
3 years 4 months ago #66279

Please Log in or Create an account to join the conversation.

  • Posts: 269
  • Thank you received: 53

Replied by Ken Self on topic Returning to ASCOM

They already exist under the example tutorials in the git repo. The simulators also provide good, simple examples.
Maybe what you mean is some kind of device emulator? Of course, someone would have to write them.
3 years 4 months ago #66303

Please Log in or Create an account to join the conversation.

  • Posts: 180
  • Thank you received: 31

Replied by Joaquin on topic Returning to ASCOM

Why not to select/recommend a (mock?) device (p.e raspi or arduino-based) easily accesible to everybody and build and document an example driver for it ?
This will allow people like me, with programming background but having difficulty swallowing the whole linux-indi-c++-hardware-Qt development ecosystem in the short time I have left to live, to get in business faster.
That could by a nice toy to play and learn.
Does something like this already exist?
Last edit: 3 years 4 months ago by Joaquin.
3 years 4 months ago #66327

Please Log in or Create an account to join the conversation.

  • Posts: 36
  • Thank you received: 1

Replied by Tim on topic Returning to ASCOM


Rendering Error in layout Message/Item: array_keys(): Argument #1 ($array) must be of type array, null given. Please enable debug mode for more information.

Please Log in or Create an account to join the conversation.

Replied by Jasem Mutlaq on topic Returning to ASCOM

Thank you Tim for the great detailed feedback. I'm going to put aside $500 to any of the existing developers to work on re-writing the documentation again (for both drivers + clients) using detailed & clear to use instructions with images + text + examples...etc. If anyone is interested in taking this task, please let me know.
The following user(s) said Thank You: Tim
3 years 4 months ago #66331

Please Log in or Create an account to join the conversation.

  • Posts: 36
  • Thank you received: 1

Replied by Tim on topic Returning to ASCOM

I look forward to seeing the results of your documentation project, it's definitely the right thing to do.
I just had a long chat on the phone with one of my professional programmer friends. He had looked at the documentation in an effort to help me but also found it somewhat sparse and confusing. I really think that once this is sorted the uptake of Indi will be much stronger and that uptake could be exponential. I would also imagine that even more device manufacturers would then be in the position of having to write Indi drivers much as in the past they had to write ASCOM drivers for their product to be accepted into the astronomy community.
3 years 4 months ago #66333

Please Log in or Create an account to join the conversation.

  • Posts: 216
  • Thank you received: 120

Replied by Rick Bassham on topic Returning to ASCOM

Hey Tim, thanks for the really good and detailed feedback. We can't get better as a project and community without knowing what we need to fix. I can talk to at least one of the points. The reason it took you so long to get to that information is that I didn't create it until you voiced your issues with the existing documentation. I threw that together basically overnight to try to fill in the gaps, trying to remember my pain points when initially getting into INDI development. Obviously I didn't quite fill in enough of them, but if you are willing, I'd like to work with you make it better. I've been doing C++ development for a long time, so I forget the learning curve of someone new, and having your perspective would be nice as I'm updating the docs.
3 years 4 months ago #66337

Please Log in or Create an account to join the conversation.

  • Posts: 36
  • Thank you received: 1

Replied by Tim on topic Returning to ASCOM

I am very grateful you put that tutorial together. It helped clear up many points for me :)
I would say the most important documentation to start with would be a very detailed account of how to set up the development environment. Especially with the removal of KDESudo and the new look QTCreator. Also a look at what the difference is between native and 3rd party drivers. Am I developing a 3rd party or a native driver ? I have no idea. And which should I produce ?
Then for both client and driver developers a detailed look at how the messaging between them occurs. I don't mean at the protocol level that indiserver implements but at what that means for developers. For a driver what functions get called by a client and when. Can a driver send a message to the client at any time etc etc. So some practical examples with diagrams as to how this all works. For example a diagram of what the server sends to a driver when it connects. When does the driver creator function get called ? When does the initproperties function get called etc etc. So a timeline drawing of how the client, indiserver and driver interact during the initial connection, for the interactions during normal operation and finally during shutdown.
I know that the project is very focussed on error free communication, that is obvious from the sample code. However it does not make the sample code easy to read when a large part of the functionality is built into the condition statement of an If Else. Much more readable would be to separate that out. So the functionality sets a local variable to true or false which is then tested. The conditions that have double negatives in them are even worse. I know this makes for elegant code that shows off the skill of the programmer as to how much he can get done in a single line, but for a C++ newbie it means 10 minutes deciphering a single line of code !
I would suggest some code with no error checking is published. Not for operational use of course but to make the basic program flow easier to understand. Then a version with error checking included but in the simple manner I describe above, and then the preferred final version. Only then can the student get their head around the flashy code that the best programmers can write :)
All this could be done in a simple driver that just talks to an arduino or some such device to get and set a single value and display it. Maybe with a switch element as well. Then the student can play with everything they need to know. It's all very well having tutorials that don't talk to a real device but that leaves a steep learning curve as to how to actually do serial communications with the hardware for which it seems Indi has some useful functions.
I was also very confused about where everything gets put in the development environment. I wound up with the source code, a build folder and I was never sure where the installed code I was writing got run from. I wound up with multiple binaries of my driver and didn't have a clue which one was actually being used when I invoked them from EKos to try and debug. I would up always changing a bit of text in my code, like the name of the driver, so I could see from the client what was being actually run.
And that's before we get onto XML files, where they go and if I need one for my driver for Indi to see it.
So a map of where all the files go during the development process on a standard Linux machine and what are being run when would really really help.
Hope this helps, if it sounds confused it's because I am :)
Last edit: 3 years 4 months ago by Tim.
3 years 4 months ago #66339

Please Log in or Create an account to join the conversation.

Time to create page: 0.885 seconds