Is there any way to schedule an operation using the driver's system clock?
I mean a field where one sets a precise (or less) local date/time to do any kind of operation, like slew, track, start an exposure/capture, change filters...etc, and avoid network delays.
What do you think?

As opposed to using KStars clock?

I mean something with the less possible lag between the command and hardware execution time.
KStars stays at the client side. I mean something at server side or better driver side.
KStars should issue the scheduling command, after polling ping-like delays between the client and the device, then, based on this delay, the driver should issue the hardware command with the best precision possible (using GPS clock one can reach 1us).
This could be useful for time-logging features also, like precise high-speed photometry.

I was thinking along the same lines, but for a different purpose. For time-sharing on a remote robotic scope, it could be a good idea to have a scheduler server (and client).
My future (and as of yet a bit hypothetical) use case is :
- Two or more users connect to a remote scope using Kstars as a client, Indi on a server connected to the scope.
- Each can send long-term scheduling orders (covering several days or months of observations). The scheduler would find the most relevant order based on best match for the target and weights
- Some automated processes can also send orders (i.e. for asteroid tracking, supernovae, etc.), superseding existing orders (higher weights, less stringent evaluation of match)
I believe this could be done by having a local install of Ekos on the scope server and some scripting, but I haven't yet played enough with scripting Ekos to know for sure. Ideally, as several people pointed out, it would be great to be able to access Ekos functions outside of Kstars (in particular in a headless install), through an API.

I haven't yet started to build my fixed observatory, but meanwhile, I mean to spend a bit of time experimenting along those lines.

I would propose something different than a local install of Ekos, like a new driver called "scheduler", which creates an instance of itself for each device connected to the server. This driver should implement an internal INDI client connected at localhost.
Another option would be adding on the base device new fields like "when to run changes": immediately or after a delay or at a specific time.

So let's talk specifically here. You want a specific device on the server side to perform an action (like start capture) at a very specific instant of time? The current Ekos scheduler cannot be used for that, there are delays in various pipelines before a command is issued. Since few seconds do not matter for most people, it is not strict about timings. Even a local "scheduler" is not guaranteed to execute commands at 1us resolutions due to delays in TCP/IP if connecting as a client to the INDI driver.

Only solution for this is to have real-time extension for drivers that require it, and maybe some real-time scheduler to manage them.

Unfortunately the best method should be linking against an user space library that uses kernel's scheduling capabilities.
I think that this is too much however: 1us is really small as delay, and there is still the problem in hardware execution time, like the internal delays in USB or serial communications.
A practicable solution would be such extension to have controls of the default properties of the driver's base class, a client would activate it with a switch and schedule as the user requires. This will stay inside the driver's code, this way the delay will be acceptable and obviously will use driver's local clock, which is the most important thing.

The precision of the clock sync of a computer using NTP should be a few tens of milliseconds. If the CCD driver is updated to accept a timestamp at which to take a capture, does that sound like a beginning of your idea?
The other problem is to configure the real-time characteristics of the INDI drivers so that they may react fast enough: RT processes can indeed execute in user space.
Also, managing the trigger delay to the hardware could be required to homogeneize between captors.

-Eric

Yes, exactly. I meant this for basic member functions of each device interface, like in CCDs:

• StartExposure ()
• AbortExposure ()
• StartGuideExposure ()
• ...
• GuideNorth ()
• GuideSouth ()
• ...and so on

There should be a function for adding targets called "AddScheduler(char* name)"
and scheduling calls like "Schedule(char *name, void* arg, timespec *tp)" where name is the same as AddScheduler and arg is the parameter to the callback, like exposure in case of CCD captures.
example (ccd driver base class)

My personal opinion is that what you describe moves too much intelligence to the drivers. It's not up to a driver to choose when to do something, thus my previous proposal to possibly have an additional API to synchronize an action, that is, tell a driver when to do something. But even there, that makes things probably complicated.

What is true is that INDI drivers offer no guarantee of doing things under a controlled time-frame. Delay, settle, response time and things like that. That should probably be thought of.

However I tend to understand from your description that Ekos would need to be divided into two parts: one part specialized into planning and organizing things, and one part specialized into executing things from a plan. Once this is properly separated, the execution part could more easily be moved to a different client with its API, or even an INDI orchestrator driver. But even there there are issues.

But that's my own opinion.
-Eric

I perfectly agree on this. The driver does not manage scheduling, it's up to an external client to issue the Schedule() call. The driver actually only creates a timer that calls an internal function. There's even not much problem of making a FIFO where to store the scheduling timeline this way.
The reason I wrote this into the driver is that I need driver's local clock for this operation.
The client should issue an XML string (ex. fantasy "<newSched exec="SCHED_EXPOSURE" args="10.0"...") and the driver should call Schedule() upon reception of such command.
This is the quickest solution, in fact would permit to skip initial Ekos coding.

Best Regards,
Ilias

You can't introduce an asynchronous mechanism in the driver and keep the design stable at the same time.

At the very most, I think you could ask a driver to do something at a certain timestamp, and wait for it to do that before you can continue with its features. That would be like running a "delayed exposure", with the usual possible abort.

In terms of implementation it would be easier for the driver to choose how it waits for the timestamp, and how it manages the slack in configuring the underlying hardware.

Then there's the question of the clock source. That could be part of prerequisites for an INDI driver.

However to me there's not much need for this specific improvement to be generalized to all drivers. A local client orchestrating execution of plans with conditional gates should be discussed separately.

-Eric