Bug? Two-Way Broadcast/Observe slows down very quickly on two City Hubs

[lebenski]

I'm unsure whether I should raise this as a bug but figured I'd start with a discussion just incase there is something I can change in my setup to make this work. As a bit of a background I've spent a couple of days trying to debug a quickly degrading performance in my two-way broadcast/observe City Hub setup. I boiled my code down to the absolute basics and it seems to me that for two hubs that are both broadcasting/observing to each other, the speed of execution quickly slows to a complete crawl.

I'm using Pyrbricks Code and two City Hubs. Both hubs are disconnected from the computer and the programs are run by using the button on the hub to rule out the bluetooth connection to the PC causing any slowness.

To recreate..

Hub1.py

from pybricks.hubs import CityHub
from pybricks.parameters import Color
from pybricks.tools import wait

hub = CityHub()
hub = CityHub(broadcast_channel=9, observe_channels=[1])

while True:

    hub.ble.broadcast("hub1-turn-red")
    hub.light.on(Color.RED)
    
    while not hub.ble.observe(1)=="hub2-turn-red":
        pass
    
    hub.ble.broadcast("hub1-turn-orange")
    hub.light.on(Color.ORANGE)

    while not hub.ble.observe(1)=="hub2-turn-orange":
        pass

    hub.ble.broadcast("hub1-turn-green")
    hub.light.on(Color.GREEN)

    while not hub.ble.observe(1)=="hub2-turn-green":
        pass
    
    wait(5000)

Hub2.py

from pybricks.hubs import CityHub
from pybricks.parameters import Color
from pybricks.tools import wait

hub = CityHub()
hub = CityHub(broadcast_channel=1, observe_channels=[9])

while True:

    while not hub.ble.observe(9)=="hub1-turn-red":
        pass

    hub.light.on(Color.RED)
    hub.ble.broadcast("hub2-turn-red")

    while not hub.ble.observe(9)=="hub1-turn-orange":
        pass
    
    hub.ble.broadcast("hub2-turn-orange")
    hub.light.on(Color.ORANGE)

    while not hub.ble.observe(9)=="hub1-turn-green":
        pass

    hub.ble.broadcast("hub2-turn-green")
    hub.light.on(Color.GREEN)

As you can see it's a very simple program where Hub2 is simply copying the light pattern of Hub1, from Red to Orange to Green. Then finally when Hub1 has received a message that Hub2 has turned Green, it waits for 5 seconds then starts the loop again.

I timed how long it takes between Hub 1 turning Red to Hub 2 turning Green and these are the first 8 loops ignoring the first which darts by in a second or so. Timings are approximate.. I did this using a manual stopwatch as I'm unable to see debug output when running the code on the hubs, obviously.

Loop 1: 4.03s
Loop 2: 11.93s
Loop 3: 21.04s
Loop 4: 34.58s
Loop 5: 46.86s
Loop 6: 63.04s
Loop 7: 81.17s
Loop 8: 81.83s

So as you can see it takes no time to degrade to a complete crawl.

Am I doing something wrong in this code? Is this a known issue? Should I raise it as a bug?

EDIT: I should add that I also tried both Hub1.py and Hub2.py on each piece of City Hub hardware to rule out one of them being faulty. The same issue occurs.

[laurensvalk]

Which firmware are you using? You can see it in the bottom right.

If you aren't doing so already, could you try this with the latest beta version, installing the firmware from there? To do so click "Try New Beta Features" on the settings panel of the app.

Thanks!

[lebenski]

That did the trick! Thanks so much.. my setup is running so much quicker now :) I don't suppose you happen to know the Issue number of the bug that was causing this so that I can read about it? No worries if not. Thanks for your help again.

[lebenski]

Oh wow adding broadcast(None) really does make a big difference! I assume this is because without it the train still continues to broadcast it's "I'm ready for the next card" message which just clogs up the bluetooth traffic between the two hubs?

And that train motor looks brilliant! I have one of those knocking around so will order a few more gears and get to work trying that out. This has been such a useful conversation for me, thanks again!

[lebenski]

Hey @laurensvalk .

Just wanted to report back to say that I took all of your advice and it's working much better! Having the color sensor on the train just makes the whole setup a lot quicker and more responsive so I'm definitely prepared to forgo the ability to easily extend the train. I also set up the train to run off a standard Large Technic motor (88013) and it runs a lot better now. Fast with consistent speed and smooth acceleration. I'm not sure if my gearing setup (or in fact the build in general) is ideal but it seems to work well enough. I'll be looking to add a bit more weight to the train and carriages to improve overall stability but I feel like this portion of the project is 90% there now. Here's an updated video of my setup

https://www.dropbox.com/scl/fi/6jqnriru0dh91zxum13qr/IMG_5625.MOV?rlkey=twuxcl1dsgbt6fnqjkbfrc41b&dl=0

Thanks again, Ben

[laurensvalk]

Looks awesome!

I'm not sure if my gearing setup (or in fact the build in general) is ideal but it seems to work well enough

You may be able to get even smoother motion by gearing down instead of up (smaller gear on the motor axle).

This gives you more rotations of the motor for the same amount of train motion, so a higher resolution of millimeter train movement per degree of motor turned.

[lebenski]

Thanks. I’m just learning the basics when it comes to gearing. As I understand it going from a small gear to a big gear would provide more torque (stability) but less rotations of the wheels, and hence less speed. Is that correct?

[laurensvalk]

Correct, but you can then tell the motors to drive a bit faster to keep the same overal train speed. (From the video, I think you're not at the maximum speed yet). These motors tend to be more accurate at higher speeds because of the relatively high friction at low speeds.