Change the delay-before-turning-off? (Spike Prime)

[FLL-Team-24277]

I don't know what length of time the delay is before automatically turning the Spike hub off, but it seems too short. Many of the kids on my team complain about it. Is there a way to adjust the elapsed time before automatically turning the hub off?

[dlech]

Can you explain more about the use case? I'm guessing they are running the program without being connected to Pybricks Code?

[FLL-Team-24277]

Thanks @dlech

When we are working on our programs, let's say I just ran it and there is something that needs to be updated in the code. So the program has ended, but the hub is still on. I'm not sure what the exact time is, but if another program isn't run soon, the hub will turn off, presumably as a battery-saving feature. If that happens, when the programmer tries to upload the code again, if they haven't noticed that the hub has turned off, the connection will fail and throw an error in the terminal (we are using VS code). This can be confusing to some kids, but they usually figure it out.

My point is, the delay seems to be too short, whatever it is. I am proposing that it would be helpful if we can set that delay to something longer.

[FLL-Team-24277]

By the way, I think the way this would be implemented would be as a setting while flashing the pybricks firmware on the hub, along with the name of the robot. I can't see any reason why this would ever need to be changed "at run time", which really doesn't make sense here.

[FLL-Team-24277]

@dlech is this something that we can already configure and perhaps I missed it, or would it be possible that an upcoming release contain this feature?

[laurensvalk]

The hub stays on for as long as it is connected. This is normally the case with Pybricks Code.

pybricksdev is not officially a recommended solution, but I can see why it is used 🙂. In the ideal world, we'd replace that use case with a Visual Studio Code extension that works just like Pybricks Code, staying connected, but that's not on the roadmap at the moment.

It could theoretically be added as a firmware config option, but I'm not too sure if we should do it .

[abliss]

Just want to chime in that this is pretty disruptive to the vscode workflow, especially if you are pairing with an LLM like copilot. The LLM makes lots of errors (like hallucinating apis) that can (afaik) only be detected at runtime. So the LLM "agent" needs to be left alone for a long time with many chances to run things on the hub. But it often thinks for many minutes between runs, during which the hub falls asleep.

I am trying to find a workaround. The first thing I tried was (1) add a wait-loop at the end of the program so it never terminates, then (2) use a launcher script that kills pybricksdev after a set amount of time so that the terminal command tool can return the output to the LLM. This succeeds in keeping the hub awake, but the second time the LLM tries to run a program, pybricksdev times out trying to connect to the hub (I guess the hub does not listen for new connections if it is still running the old program, even if the pybricksdev process on the PC has been killed?).

[dlech]

We recently added a new --stay-connected option to pybricksdev run. I think that could help.