Is this to much for the technic hub?

[Flippoel]

Hi, we nearly finished our program for the Lego model dredger.
The last part was the grab-crane.
We and up now with a question if our program: is to much for a technic hub? And is there a way to make the program easier so, that the hub can handle it?
Here you can see the grab-crane running on the Technic hub: https://youtu.be/c0zYWZ6jL2Q
We also tried the same program on a spike prime hub, and that looks much better: https://youtu.be/TnsT0XV-zGI But still you see the motor which should be faster according to the program, is slower. At 0:10 you can see one motor stops, while the other runs for another second or so.
The program includes also a number of other functions to send to other hubs, this is because we want to use only one controller to control al these functions.
hub_Kraan_BB.py.zip

[Debenben]

That is a nice dredger, thank you for sharing! I had a look at the videos but was not able see an obvious problem. What you describe seem to be two separate problems:

(1) Motor should be faster. That sounds like a battery problem. The lithium ion battery of the spike prime tends to have a higher voltage and higher power output than your average AA batteries. You could print the voltage under load (=when motors are running) to confirm. The block to get the voltage is located at the bottom of "Input" section.

(2) Motor keeps running for another second. This sounds like a problem in your code. To identify what parts are responsible you could do some profiling. You could define an integer variable and increment it in the loop with the slow reacting motor. Every time the variable modulo 100 is zero, you print the value and/or toggle the hub led on/off. Then you keep deleting parts of your program until the loop runs as fast as expected. If you know what functions are responsible, there are probably ways to improve them.

The best way to find the problem is still the profiling, but I noticed that you have a couple of loops without any await inside of the loop like this

This means the hub will keep requesting the motor angle as fast as it can. Internally the hub handles the multitask sequentially. If some 20ms wait somewhere expired or it recieved some response from some sensor that needs to be handled those tasks might have to wait in a queue if the hub is busy doing something else. If you do not have any await in the loop, the hub will always be busy. If you look at the python that is generated from your block code you see that it automatically puts await wait(0) at the beginning of every loop for you. For every function that has await in front it has the opportunity to jump to some other task that might be waiting for execution. It could help to wait for 20 milliseconds in those loops like you have done in other places which would probably improve the situation but not solve the underlying problem. For a motor to run a second longer than it should it would need to execute something that is blocking one second. Something like this could be e.g. a long running calculation which I do not see in your code therefore it might be a function with bad implementation in pybricks firmware.

[laurensvalk]

Does it also stop if you just have those two movements? So just those 3 blocks tested in a separate program?

It is generally not a good idea to have 3 parallel stacks all try to use the same motor. (Physically that can't work, let alone in code).

I think you're trying to protect them from running simultaneously with the A/B/X/Y true/false variables, but they are not instantly set since that stack of your code waits on other things. So it looks like there are conditions where multiple blocks can be trying to run the motor at the same time?

[Flippoel]

Hi Laurens,
Thanks for helping us!
This weekend we had water in our bassins in Nijkerk (for the first time after the winter), so it was first 'sailing time', have a look: https://youtu.be/fKQtHQ9bTTs

So we had not that much time for the crane this weekend, but I just tested this:

And also this:

But both didn't solve the problem. If I'm right Bert did a suggestion that the multitask can be the problem, is there a way around that, or can you improve these blocks?

To clarify a little more on the original plan, we would like to find a way to press just one button one time and after that the crane should start doing it's work on it own. That's why we made the whole A/B/Y/X program and true/false variables to make that possible.
As long as we don't press any other button then the X to stop the repeat, I think there's no issue with blocks that runs the same motor.

And the last program is definitely not with multiple blocks on the same motor.

I hope you can help us improving this program. Thanks again.

[BertLindeman]

Flip,

Thanks for the link to a nice and sunny sailing day movie.

To prove if multitask is a problem in this case, I took your last program and let it run without the magnificent model.
Just dropped the controller as it's not used.

I do not see any stuttering of the giek motors. But there is no load on my setup.

Will add a movie shortly.

[EDIT] movie added:

issue_2129_20250406.4.mp4

Bert

[Flippoel]

Hi Bert,

Thanks, two issues, 1) we use a technic hub, and 2) I hope to try also without the controller, maybe that's the problem. I will let you know.

[BertLindeman]

Good catch Flip.

I just had a robot inventor with 4 motors laying around. So lazy as I am sometimes, I used it.

Will also do it on the technic hub.

Bert

[BertLindeman]

More or less the same result on the technic hub.

Probably not helpful

What I see on the Technic hub (beta firmware) that the motor on the B port is faster than the one on the C port.
There is roughly nearly half / quarter of a second time between the giek_SB motor (On C) and then later the giek_BB motor (on B).

Swapped the B and C cable and then it seems almost the same result.
The motor on B now is slower.
So it's the motor that makes the difference, not the program.

Took another motor to swap the slowest motor and now the difference is not visible

[Flippoel]

Hi @Debenben and @BertLindeman,
Thank you very much for helping in the first place. This is quite difficult for us.
If it's not to much for one of you, can you make a plan step by step how we get this running on the hub?

[BertLindeman]

Sure Flip.

No rocket science.
You program in code.python.com or beta.pybricks.com as you use to.
The site where you have your sources.

In the UI select the plus to add a new source file (bumpy yellow circle):

fill the pop-up and make sure to first chose "python" like this

No need to select a template.
Fill in the source name. I used issue_2129_helperfile
but you can take any filename you like, as long as you use the same name in the setup of the imports.

On the new file in the editor copy / paste the small helper file like this:

# file issue_2126_helperfile.py

# from issue 2129 discussion:
# https://github.com/orgs/pybricks/discussions/2129#discussioncomment-12845711

def setpid(motor, args):
    motor.control.pid(*args)

def setstall(motor, args):
    motor.control.stall_tolerances(*args)

async def setpid_async(motor, args):
    motor.control.pid(*args)

async def setstall_async(motor, args):
    motor.control.stall_tolerances(*args)

And the rest is to adapt your existing program to add the imports on the setup and the use of them like in the programs above.

And ask if unsure.

Does this help?

Bert

[Flippoel]

Thanks Bert, I hope to test it this weekend, but I'm not sure I have time enough. I will let you know.

[Flippoel]

Hi,

We tried this, but for now, it made the problem worse.

`from pybricks.hubs import TechnicHub
from pybricks.pupdevices import Motor
from pybricks.parameters import Button, Color, Direction, Port, Side, Stop
from pybricks.robotics import DriveBase
from pybricks.tools import wait, StopWatch

hub = TechnicHub()

file issue_2126_helperfile.py

from issue 2129 discussion:

https://github.com/orgs/pybricks/discussions/2129#discussioncomment-12845711

def setpid(motor, args):
motor.control.pid(*args)

def setstall(motor, args):
motor.control.stall_tolerances(*args)

async def setpid_async(motor, args):
motor.control.pid(*args)

async def setstall_async(motor, args):
motor.control.stall_tolerances(*args)`

https://youtu.be/ZXYno76xgkQ

[BertLindeman]

Flip,
And it is only the BB side as it was.
So strange.
@Debenben do you have a hint?

[Debenben]

You mentioned you were using an external powersupply? Maybe you have the opposite problem of very little load and the motors have more power than usual? Then reducing the proportional term should help.

…

On 18 April 2025 17:35:40 CEST, Bert ***@***.***> wrote: Flip, And it is only the BB side as it was. So strange. @Debenben do you have a hint? -- Reply to this email directly or view it on GitHub: #2129 (reply in thread) You are receiving this because you were mentioned. Message ID: ***@***.***>

[BertLindeman]

Flip,

I know the Spike program did not show this behavior, but ...
did you try to move the grabber arms by hand? With the actuators disconnected.
Just to know these are moving both the same.
And while the actuators are disconnected do the motors behave the same?

Thanks Debenben.

Bert

[Flippoel]

Hi, here an end report of today's tests.
We disconnected the arms from the actuators and also the crab. The arms move smoothly and nearly exactly the same. Jeftha and I felt a tiny, tiny differents, but that makes the problem bigger, because the BB (the motor with the problems) was some smoother then starboard.
Then we moved the actuators without the arms, here the result: https://youtu.be/tYM3yrNASEQ
BUT, this was not with the 'helperfile', so we hope to do that soon.
As you can see the problem is still there even with way less load.

@Debenben is this the 'proportional term'? what value should you suggest?

[BertLindeman]

Thank you so much Flip for keeping us updated.
Positive: The problem is not in the arms. That's what you proved.

Bert

[Flippoel]

Good morning, keep in mind this video, it's possible to run it as we want, so we hadn't much expectations the arm separately.
@Debenben can you suggest which value we need to put in the 'proportional term' as you suggested, and where we need to put that value.
Thanks again!

[Debenben]

Yes, the number you marked with the circle is the proportional term. The pybricks default value depends on the motor and potentially on the hub you are using. The one that is best depends on your setup, you can only determine experimentally. One approach would be to set the integral and derivative term to 0 (the next two values currently =none=default) and increase the proportional term until the motor is oscillating around the target position. Then use half of that value. Did I understand correctly that the problem disappears if the motors are running independent of each other? In that case there might be some resonance effect between the two in which case it might be best to put and leave the integral term at 0.

…

On 19 April 2025 12:18:01 CEST, Flip and Jeftha van der Poel ***@***.***> wrote: Good morning, keep in mind this [video](https://youtu.be/5hCrr_U-Bqw), it's possible to run it as we want, so we hadn't much expectations the arm separately. @Debenben can you suggest which value we need to put in the 'proportional term' as you suggested, and where we need to put that value. Thanks again! -- Reply to this email directly or view it on GitHub: #2129 (reply in thread) You are receiving this because you were mentioned. Message ID: ***@***.***>

[Flippoel]

Thanks again for helping, I'm sorry, but it sounds quite difficult for us beginners.
Two questions and a note for now.

1. can you show with a screenshot which values we need to change?
2. can I increase the acceleration back to 1000? It's now on 100 and that's not where we want to have it?

Note, we have no time anymore this weekend, so maybe next weekend we are able to do some new tests.

[Debenben]

1. The parameters are the ones described in pybricks documentation here https://docs.pybricks.com/en/latest/pupdevices/motor.html#pybricks.pupdevices.Motor.Motor.control.pid, I marked them in your screenshot below. In your case it should be sufficient to only use a proportional term and set the integral and differential term to zero, making the PID-controller a P-controller, but feel free apply more sophisticated techniques e.g. https://en.wikipedia.org/wiki/Proportional%E2%80%93integral%E2%80%93derivative_controller#Manual_tuning. If SB and BB side behave differently, they need different PID settings. In case the problem is some resonance effect between SB and BB motor, use an overdamped setting for both or at least for one of them.
   
2. Yes, changing acceleration was not part of any suggestion in the first place. I just put a slow acceleration in my test program because the PID controller tends to struggle at slow and fast speeds and using low acceleration I could test both in one test program.

[Flippoel]

Hi @Debenben,
We tried your suggestion, and it seems that round 12000 there is the 'oscillating' point. But when we fill in then half of that: 6000, the problem still exists.
So are we doing something wrong in this test?
Here a video: https://youtu.be/4CWwXlbo_io

BTW, this is really above our head, so we have now idea what we are doing, but when we find a solution, we will test everything you suggest.
@laurensvalk do you maybe already have time to look into it as well?

[Flippoel]

Hi @Debenben @BertLindeman,
Laurens helped us in a quite simple way, just setting up a drive base. Until now it seems to work well, we need to finish the whole program, but it looks good. Part of the problem was also the crab, because it should run to 45 degrees, it was not possible to get there, so now we use the same block as in the beginning 'run to end stop'
Thank you all for helping.

[BertLindeman]

Thank you Flip for the positive feedback.

Great project!

Bert

[Flippoel]

Hi,
It took a while, but here we have a video of a crane which is working properly.
https://youtu.be/-o8caHNtAZ0
Again thanks for your help!

[BertLindeman]

Great project, Thank you very much.

Bert