Open cxrodgers opened 2 years ago
Ok I think I found the problem.
Workaround: add a pref called PIGPIOD and set it to "true". Fix (TODO): consistently call this variable either PIGPIO or PIGPIOD. Also check whether autopilot.setup is setting it to false (I probably forgot to check this box during setup, but it probably also should default to true if the user forgets)
I would also propose that starting pigpiod should not be a side effect of initializing a hardware pin .. it should only be initialized when the Agent is booted. The current side effect doesn't work anyway because initializing hardware happens in a thread, and threads can't use "signal" (apparently). The only reason "signal" is being used is to connect a "kill" to pigpiod, but this doesn't seem to be working reliably anyway (we have to kill pigpiod on every autopilot restart). So we should probably just remove this use of signal (https://github.com/auto-pi-lot/autopilot/blob/04b5968ba02c8a1413a27eb6a138b6a186b130f1/autopilot/external/__init__.py#L85).
YES. that is extremely annoying. Making Prefs explicit is the thing I didn't have time to get to when switching over to formal data models for v0.5.0. The way it works now is bad for exactly this reason (not clearly documented, some prefs are implicitly accessed, etc.)
related to : https://github.com/auto-pi-lot/autopilot/issues/155
Launching pigpiod as a byproduct of initializing a GPIO object is for the purpose of being able to use them outside of a task/agent context, which was a requested (and useful) feature, but pigpio is just a pretty fussy program generally and so yes we need a better way of killing the process. A better way of launching it than is done now (a function call with an implicit global module state) would be to have explicit process handling classes, just haven't had the time to implement yet.
Having trouble initializing hardware on a Child Pi. As far as I can tell, the first time a GPIO is initalized, it creates a subprocess for pigpiod and stores it in a global variable PIGPIO_DAEMON, unless that global already exists, in which case it uses the existing value. Problem occurs because for some reason the
signal
line can't be executed in any thread except the main one, and I guess the Child task is being run in a thread? I do not get this problem on the Parent Pi.Seems like the fix is to call external.start_pigpiod() in the main thread on the Child, if I can figure out how to do that.