motor - run until stalled

[KusneNIST]

Hi, will the package eventually support motors stopping when stalled, similar to the pybricks functionality? Or is this not possible with the HAT? Is there a way to implement this with the current python-build-hat library?
Thank you!

[mutesplash]

You mean detect if the motor is binding when it was asked to move and do something about it?

[KusneNIST]

My scenario is: having the motor move and once the motor reaches an obstruction and stalls, the motor stops.
This reduces the need for combining a motor with a sensor that detects when the motor has stopped.
Since the HAT has only 4 LEGO ports, this reduces the number of LEGO devices needed for motion control.
Alternatively we're looking at combining two LEGO HATS through a stack board, but there are pin address collisions. So we're also looking at ways to combine two HATS with the ability to multiplex between them.
Thanks again!

[mutesplash]

It's certainly possible to detect a stuck motor by analyzing the progress via the combi data during the time the library is waiting for the ramp command to end. I'll poke at this and see what kind of granularity can be obtained. Pybricks seems to base stalling on total runtime or speed thresholds, but it seems like "failure to demonstrate angular progress" might be another measure? Not sure how to algorithmically determine this.

In regards to the multiple HATs, you would need some sort of electrical interposer that makes the second HAT avoid all the pins BuilHAT uses and then have the serial port show up in the OS some other way than how the standard HAT drivers work. That seems real hard. I seem to recall reading somewhere about how the EEPROM ID prevents the stacking but I can't recall if this was a firmware or hardware limitation. Or you could just use two RPIs and have them do RPC at the Linux level over wifi or bluetooth between separate BuildHAT programs or IPC in python via an ad-hoc GPIO protocol. That's a whole other discussion that probably belongs on the Raspberry Pi HAT forums, though.

[KusneNIST]

Thank you for taking a look at this!

[mutesplash]

I tried doing a stupid simple solution for this and got halfway through and realized it wasn't going to work due to weirdness. I went and looked at pybricks and their code is amazingly complicated (and excellently documented) and has the benefit of working directly on the motor and its signals. All this is to say I wouldn't get your hopes up, but I'm not done poking at it.

[laurensvalk]

Hi, will the package eventually support motors stopping when stalled, similar to the pybricks functionality? Or is this not possible with the HAT?

Pybricks developer here.

We define stalled as "unable to reach target speed or position given the available feedback torque". The torque and speed thresholds are configurable. Using the internal motor control state, this can get very responsive.

On that note, would there be any interest in a fully open source firmware for the Build Hat?

I've seen a few of such requests here and on the Raspberry Pi forums. It could potentially solve most motor and sensor related problems, and perhaps improve the hat's responsiveness quite a bit.

It's certainly possible technically, and we'd be happy to chat about it with the Raspberry Pi Foundation. I don't know if we should open an issue here (@chrisruk ? ) but we can also be reached via email (team@pybricks.com) or on GitHub.

[mutesplash]

I would say there's not enough political capital in online discussions with the Raspberry Pi Foundation to get any meaningful action on the firmware, as no reason for the closed source has been even offered, despite the chip being produced by the Foundation itself. The Pybricks team may have enough, if the issue of BuiltHAT being not well suited for precision robot applications due to firmware limitations was raised in their own official channels.

I do like the BuildHAT, but I can't even get it to replace EV3Dev in some projects I have due to the imprecision in motor control.

[laurensvalk]

Thanks for your response! But crucially, this approach doesn't require the original firmware source to be be disclosed.

Pybricks already has open source drivers for all LEGO motors and sensors. These drivers could be adapted to run on this architecture. They can run without MicroPython on top as this would not be needed in this application.

The Build Hat seems like it has a lot of potential just waiting to be unlocked :)

[mutesplash]

The firmware is signed, so looping in Pybricks to run on the RP2040 would be a significant development structure change, if I understand you correctly.

If the firmware were open sourced, which seems to require external pressure on the Foundation to do so, then improved and adapted drivers could at least be formally entertained as options.

[hollielucas]

I've come here as I have recently obtained a RPi 3 B and, being an AFOL who enjoys motorising builds, immediatly considered a build HAT. However, having read this thread, and others, I'll give it a miss. Consider:
Pyricks on the Technic Hub works.
Pybricks on the EV3 works.
EV3Basic on the EV3 works.
Arduino (with hacked wiring) works.
So many alternatives work as intended. Why put up with h'ware and s'ware that does not work.
So much good open source software out there that I have gained great pleasure, satisfation and knowledge from. Why this attitude by RPi Foundation?