Hans replied to the topic 'kstars-bleeding 6:3.3.4+201908080145~ubuntu18.04.1 crash' in the forum. 4 weeks ago

(gdb) up 3
#3 0x0000564d1dfde790 in Ekos::Capture::processPreCaptureCalibrationStage (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:5562
warning: Source file is more recent than executable.
5562 void Capture::toggleVideo(bool enabled)
(gdb) list
5557 }
5558 }
5559 }
5560 #endif
5562 void Capture::toggleVideo(bool enabled)
5563 {
5564 if (currentCCD == nullptr)
5565 return;

(gdb) up 1
#4 0x0000564d1dfde8cd in Ekos::Capture::updatePreCaptureCalibrationStatus (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:2988
2988 abortedJob = job;
(gdb) list
2983 SequenceJob * abortedJob = nullptr;
2984 for(SequenceJob * job : jobs)
2985 {
2986 if (job->getStatus() == SequenceJob::JOB_ABORTED)
2987 {
2988 abortedJob = job;
2989 break;
2990 }
2991 }

No idea why abortedJob triggered yet.


Hans created a new topic ' kstars-bleeding 6:3.3.4+201908080145~ubuntu18.04.1 crash' in the forum. 4 weeks ago

kstars-bleeding 6:3.3.4+201908080145~ubuntu18.04.1

After capturing 6 frames kstars/ekos segfaulted with :

(gdb) bt
#0 raise (sig=<optimized out>) at ../sysdeps/unix/sysv/linux/raise.c:51
#1 0x00007f32a64257f9 in KCrash::defaultCrashHandler(int) () from /usr/lib/x86_64-linux-gnu/libKF5Crash.so.5
#2 <signal handler called>
#3 0x0000564d1dfde790 in Ekos::Capture::processPreCaptureCalibrationStage (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:5562
#4 0x0000564d1dfde8cd in Ekos::Capture::updatePreCaptureCalibrationStatus (this=0x564d23bf4aa0) at ./kstars/ekos/capture/capture.cpp:2988
#5 0x00007f32a0c4d0d4 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6 0x00007f32a0c410db in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7 0x00007f32a209682c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8 0x00007f32a209e0f4 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#9 0x00007f32a0c119a8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007f32a0c69d8e in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007f32a0c6a589 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x00007f329c151417 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007f329c151650 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007f329c1516dc in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x00007f32a0c6a8ef in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007f32a0c0f9ea in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007f32a0c18a84 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x0000564d1dc99c92 in main (argc=<optimized out>, argv=<optimized out>) at ./kstars/main.cpp:331

The logfile has :

[2019-08-25T00:08:57.697 CEST INFO ][ org.kde.kstars.ekos.focus] - "Autofocus complete after 9 iterations."
[2019-08-25T00:08:57.699 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 7000" startup 2 "24/08/19 22:54" state 3
[2019-08-25T00:08:57.699 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-08-25T00:08:57.705 CEST INFO ][ org.kde.kstars.ekos.capture] - "Ekos will refocus in 3600 seconds."
[2019-08-25T00:08:57.706 CEST INFO ][ org.kde.kstars.ekos.capture] - "Focus complete."
[2019-08-25T00:08:57.707 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Focus State "Complete"
[2019-08-25T00:08:57.725 CEST INFO ][ org.kde.kstars.ekos.guide] - "PHD2: Guiding Resumed."
[2019-08-25T00:08:57.726 CEST INFO ][ org.kde.kstars.ekos.guide] - "Guiding resumed."
[2019-08-25T00:08:57.727 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Guide State "Guiding"
[2019-08-25T00:08:57.727 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Calibration & Guide stage...
[2019-08-25T00:08:57.727 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'NGC 7000' guiding is in progress."
[2019-08-25T00:08:57.728 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Get next action...
[2019-08-25T00:08:57.729 CEST INFO ][ org.kde.kstars.ekos.capture] - "Meridian flip configuration has been shifted to the mount module. Please configure the meridian flip there."
[2019-08-25T00:08:57.730 CEST INFO ][ org.kde.kstars.ekos.scheduler] - "Job 'NGC 7000' capture is in progress..."
[2019-08-25T00:08:58.353 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking job stage for "NGC 7000" startup 2 "24/08/19 22:54" state 3
[2019-08-25T00:08:58.353 CEST DEBG ][ org.kde.kstars.ekos.scheduler] - Checking Park Wait State...
[2019-08-25T00:12:00.858 CEST WARN ][ default] - QSocketNotifier: Invalid socket 8 and type 'Read', disabling...
[2019-08-25T00:12:00.858 CEST WARN ][ default] - QSocketNotifier: Invalid socket 16 and type 'Read', disabling...
[2019-08-25T00:12:00.858 CEST WARN ][ default] - QSocketNotifier: Invalid socket 10 and type 'Read', disabling...

The console :

The konsole shows not much help either
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = kstars path = /usr/bin pid = 8677
KCrash: Arguments: /usr/bin/kstars
KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from kdeinit
[1]+ Stopped kstars
~/ $?=147 INDI server localhost/7624 disconnected.
INDI server localhost/7624 disconnected.
Unable to start Dr. Konqi
Re-raising signal for core dump handling.5


Richard Horn thanked Hans in topic INDI DSLRs FAQ 3 months ago

Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 4 months ago

sterne-jaeger wrote: github.com/sterne-jaeger/kstars/tree/ekos_observatory

Awesome. Do you generate kstars/ekos/observatory/observatory.ui with some tool ? and if so how does that work ?


Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 4 months ago

sterne-jaeger wrote: ... I started testwise to develop a dedicated tab for the observatory.

Hey that's great that you started this ! Please tell me this lives in a branch in github somewhere :) (we can arc it to phabricator later :-P )

We need to add things like which dome/roof driver is in use, make a distinction between roll-off roof and dome with shutter, which safety system is in use and what its status is (I see weather is already there), enable or disable closing on bad weather, we need a flexible close order (like dome park first, then close cap, then close shutter). And a hysteresis setting, like if we closed down and things are safe again wait with opening for X time. Retries, how many ? Logic like if dome park fails do we still want to try to close the shutter or not ? Maybe even pre and post scripts or curl calls per action. And a wake-human alerting system, which may be just another script to be called so to defer the actual implementation to the user. Do we need to support multiple mounts in an observatory here too ?

-- Hans


Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 4 months ago

With EKOS 3.2.2 closing up the observatory again on bad weather (live tested and verified last night, yay !) I'll adapt sentinel to handle the that the mount may already be parked etc. so that sentinel turns into a second defense line, an independent safety mechanism.
-- Hans


Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 4 months ago

Hi Ferrante,

fenriques wrote: I'm adapting the script to my setup, 2 out of 4 of my devices work:
1) Roof is ok. Only updating the property was needed:
2) Weather is ok. Just used '_PARAMETERS' instead of '_STATION_INDEXES' :
And changed the variable names accordingly in the script.

Great !

3) Mount. I'm using 'LX200 10Micron' drivers. There's no PARK property there. Are you using the same driver?

I would hope so, I get this :
indi_getprop | sort -u | grep 10micron | grep PARK
What do you get ? Is your scope parked when you try this ? Or has the scope been parked with this instance of the INDI driver once ?

4) Camera. The property 'ZWO CCD ASI071MC Pro.CCD_COOLER.COOLER_ON' is not listed using getprop with ASI071. Anyway when I execute the script it returns true but the cooler is still On. The only other property related to cooler is 'ZWO CCD ASI071MC Pro.CCD_COOLER_POWER.CCD_COOLER_VALUE' but doesn't change the cooler power neither.

In the ZWO asi_ccd.cpp code we have
bool ASICCD::initProperties()

    IUFillSwitch(&CoolerS[0], "COOLER_ON", "ON", ISS_OFF);
    IUFillSwitch(&CoolerS[1], "COOLER_OFF", "OFF", ISS_ON);
    IUFillSwitchVector(&CoolerSP, CoolerS, 2, getDeviceName(), "CCD_COOLER", "Cooler", MAIN_CONTROL_TAB, IP_WO,
                       ISR_1OFMANY, 0, IPS_IDLE);

    IUFillNumber(&CoolerN[0], "CCD_COOLER_VALUE", "Cooling Power (%)", "%+06.2f", 0., 1., .2, 0.0);
    IUFillNumberVector(&CoolerNP, CoolerN, 1, getDeviceName(), "CCD_COOLER_POWER", "Cooling Power", MAIN_CONTROL_TAB,
                       IP_RO, 60, IPS_IDLE);
As you can see there the CCD_COOLER parameter is IP_WO, a write-only parameter. You get to see these with indi_getprop when you add -w
indi_getprop -w | sort -u | grep CCD_COOLER
And writing to CCD_COOLER_POWER is indeed not allowed as it's IP_RO , Read Only.
But writing to CCD_COOLER.COOLER_ON should work still. If it does not then that is a ZWO ASI and/or INDI driver bug. You can file a bug for that ;-)

5) Cap. Didn't test the cap.

Neither can I, I don't have a cap (yet).

-- Hans


Eric thanked Hans in topic Partitioning the Scheduler code 4 months ago

Hans replied to the topic 'Partitioning the Scheduler code' in the forum. 4 months ago

TallFurryMan wrote: Hans, do you agree to make your Ekos Sentinel a parallel project to what is done in that Observatory module?

Yes that was my intention. To follow any upcoming EKOS' observatory close down changes and keep it only as a failsafe system for the cases where EKOS does not close down while it should. (I consider this to be a different situation from an EKOS crash where the INDI watchdog driver can kick in.)

We would follow the same approach as the Ekos Internal Guider developed in parallel to Linguider and PHD2.
That means your project needs to formalize a notification interface, and that means Observatory needs to clearly separate its safety management to accept external services. That would be a benefit for both I think.

That sounds perfect. Where are the parts of the Linguider/PHD2 interfaces that EKOS uses described ?
Ekos Sentinel can now only command the scheduler to start or stop. It cannot ask what the scheduler is doing. The new observatory module should have an API where external programs can query these things, and it would be great if the observatory module could inform sentinel that it is going to do something, and that it expects to take X seconds at max. I propose I add a REST API interface to Sentinel for this.

-- Hans


Hans replied to the topic 'Full Automation and Weather handling in the Scheduler' in the forum. 5 months ago

fenriques wrote: i'm struggling to adapt your script to my setup, it's not as simple as adapting the initial configuration.

I'll try to help.

You are using Weather Meta, that driver is not extending the Weather base class.

Right, INDI Weather Meta Driver watches up to 4 weather drivers and report worst case of each in a single property.

So there's not the standard INDI weather property available (that should be WEATHER_STATUS). This property should then have a State (I mean IPState) related to the weather condition.

I don't think that's how it works. I see for instance this :
indi_getprop | sort -u | grep WEATHER_STATUS



So OpenWeatherMap which does OpenWeatherMap : public INDI::Weather also does not have a single WEATHER_STATUS property but has 5 sub properties.
Weather Meta has 4 of those, and Weather Safety Proxy has 1.

I didn't succeeded yet replacing the Meta 'station_indexes' in your script with the standard WEATHER STATUS property.

Can you show which exact property you're targetting ?

What I found is that no weather driver sets WEATHER_STATUS directly. They all use min and max parameters :
void WeatherInterface::syncCriticalParameters()
sets critialParametersL[i].s = IPS_ALERT;
if ((ParametersN[j].value < ParametersN[j].min) || (ParametersN[j].value > ParametersN[j].max))

-- Hans


Hans replied to the topic 'Partitioning the Scheduler code' in the forum. 5 months ago

sterne-jaeger wrote: From my perspective, the Scheduler remains the top level controller, even if we separate for example the observatory management. All these other modules should work on their own with the Scheduler orchestrating them.

In my opinion a weather/safety tab need to be able to guarantee safety, and thus stop or pause the scheduler (and park stuff) when conditions are not safe. As such it is the top level controller.
Safety includes manual sessions where the scheduler is not even used. When someone just manually uses the other tabs to open the observatory, point the telescope, etc.

-- Hans


Hans thanked Eric in topic Partitioning the Scheduler code 5 months ago