×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Scheduling Locally...

  • Posts: 57
  • Thank you received: 28

Replied by Ilia on topic Scheduling Locally...

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.
Last edit: 6 years 6 months ago by Ilia.
6 years 6 months ago #19053

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

Replied by Jasem Mutlaq on topic Scheduling Locally...

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.
6 years 6 months ago #19055

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

  • Posts: 57
  • Thank you received: 28

Replied by Ilia on topic Scheduling Locally...

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.
6 years 6 months ago #19061

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

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Scheduling Locally...

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
The following user(s) said Thank You: Ilia
6 years 6 months ago #19067

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

  • Posts: 57
  • Thank you received: 28

Replied by Ilia on topic Re:Scheduling Locally...

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)
typedef void* sched_arg[2];
INDI::CCD::CCD() {
...
INDI::BaseDevice::AddScheduler("SCHED_EXPOSURE");
...
}
...
bool INDI:CCD::Schedule(char *name, void* args, timespec *tp) //virtual from INDI::BaseDevice
{
    ...
    else if("SCHED_EXPOSURE"== name) {
        timer_t timerid; //should not stay here
        sched_arg arg;
        arg[0] = (void*)this;
        arg[1] = args;
        struct sigevent sevp;
        sevp.sigev_notify = SIGEV_THREAD;
        sevp.sigev_notify_function = sched_start_exposure;
        sevp.sigev_value = arg;
        if(timer_create(CLOCK_REALTIME, &sevp, &timerid) == 0 && timer_settime(timerid, 0, tp, NULL))
            return true;
    }
    else return false;
}
...
void* sched_start_exposure(void* arg)
{
    sched_arg args = (sched_arg)arg;
    INDI::CCD *sender = (INDI::CCD *)args[0];
    sender->StartExposure((double)args[1]); //PROBLEM: protected member...just an example BTW
}
Last edit: 6 years 6 months ago by Ilia.
6 years 6 months ago #19071

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

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Scheduling Locally...

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
6 years 6 months ago #19085

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

  • Posts: 57
  • Thank you received: 28

Replied by Ilia on topic Re:Scheduling Locally...

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
Last edit: 6 years 6 months ago by Ilia.
6 years 6 months ago #19086

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

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Scheduling Locally...

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
6 years 6 months ago #19089

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

INDI drivers were not designed to meet real-time constraints. I think even before discussing a local scheduler, find if you can truly develop an INDI driver that could meet such demands.
The following user(s) said Thank You: Ilia
6 years 6 months ago #19095

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

  • Posts: 57
  • Thank you received: 28

Replied by Ilia on topic Re:Scheduling Locally...

Hmm.. Actually I have not the need to schedule by itself, but to know if I can get accurate timing informations about captures in detectors and exposures in CCDs.
I have to take a capture from different detectors "almost" at the same time, so scheduling with a precise timestamp seemed to be my solution.
Fortunately the captures may be one- seconds or more, and got the initial timestamp I can re-align the frames after.

I realize that it's not common and not much constructive the argument of this thread.
By the way, Thank you all.

Best Regards,
Ilias.
Last edit: 6 years 6 months ago by Ilia.
6 years 6 months ago #19097

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

  • Posts: 1029
  • Thank you received: 301

Replied by Eric on topic Re:Scheduling Locally...

It seems syncing an exposure to a specific timestamp could be a good feature though. So perhaps you should reformat your wish with this intent if you have a need for it.

-Eric
6 years 6 months ago #19128

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

  • Posts: 57
  • Thank you received: 28

Replied by Ilia on topic Re:Scheduling Locally...

I'm reading your description, and found maybe something closer to your idea:
Basically in IsNewNumber there's maybe the need of a usleep() before StartExposure().
Is this what you meant?

Best Regards,
Ilia.
6 years 6 months ago #19129

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

Time to create page: 0.195 seconds