adding softreboot via crtl d

[OutOfTheBots]

I have used main line micropython for some time and a number of different port. Usually crtl d in the repl gives a soft reboot which is handy to clear all RAM and reset.

Can this be added to pybrick even it is only for spike and robot inventor that have enough space to add features

[dlech]

A soft reboot is performed every time the user program is stopped. And CTRL-D should already work in the REPL. What behavior are you seeing?

[laurensvalk]

I suppose we'd need Arduino to sponsor Pybricks then 😄

[OutOfTheBots]

During a soft-reset, hardware drivers are not reset as this would mean losing the bluetooth connection and losing sync with all motors and sensors. For the IMU, it would mean losing the yaw information (even though we don't have this yet). This behavior is consistent with the LEGO firmware by the way.

I understand that during a soft reboot that you don't want to loose Bluetooth or USB connection to PC but in most cases the reason your doing a soft reboot to reset all motors, sensors, IUM data and clear all RAM.

Imagine running your program then doing a soft reboot then running your program a second time but now your robot's encoders and IUM isn't zeroed at the start up of your program but rather remembers data from before the soft reboot.

I would suggest that a soft reboot resets everything except connection to PC as it is a pain the only way to reset everything is a complete hard reset

[dlech]

This pretty much happens already. IMU support is unfinished and really shouldn't be advertised as working yet so bugs are expected there. Motors are stopped/reset each time the user program stops (including CTRL+D in REPL). The MicroPython runtime is completely restarted, so all of the RAM used in the user program or in the REPL is freed.

[laurensvalk]

This is actually being done for the most part. In fact, much more so than what would happen in a standard micropython board.

For example, unlike the REPL in the LEGO firmware or some MicroPython boards, we take care of stopping the motor and getting them back in a clean state.

Basically, a hard reset should never be needed. If you find there’s a need, that indicates there’s a bug (as you’ve seen with the IMU, and it is logged as such).

As for the IMU, that’s actually one of the things that should not be reset. You wouldn’t want it to start calibrating just as your code begins, because this is typically when the robot is moving.

It could still make sense to have the yaw value start at 0 (this is what the heading method will do) but that has nothing to do with resetting the hardware or driver.

[OutOfTheBots]

@dlech thanks for the clarification on the soft reboot.

As for the IMU, that’s actually one of the things that should not be reset. You wouldn’t want it to start calibrating just as your code begins, because this is typically when the robot is moving.

I think this is more fuel for the idea that the IMU shouldn't start on boot up but rather the user has to call an initialization method something like IMU.init(orientation=axis.X) that way the user can ensure the robot is still during the startup of the IUM and also specify which rotation axis needs to be tracked for yaw as the other 2 axis orientation is known by sensing the linear pull of gravity.

I am of the opinion that soft-reboot should also reset the IMU the same as the motors and sensors.