Pybricks
Replies: 8 comments 8 replies
-
|
Are you able to reproduce the same behavior in a smaller program? |
Beta Was this translation helpful? Give feedback.
-
|
Apparently no. I tried two very simple programs, one receiver and one sender, with parts of the program above, but without the HandleComms object, and I could not replicate. Then I tried to put the HandleComms and it started to seem to have delays like the program above... but I quit, because the program above is much easier to debug than having two separate programs... One could think it is related with tasks, but with City and Prime everything works fine. |
Beta Was this translation helpful? Give feedback.
-
|
Today I did some more tests with this setup, and for some reason, I went to a different room in my apartment. And there there was no problem! Coming back to the initial room and the problem is there! It seems this is related with the location where I test it! But with City and Prime I could not reproduce the problems… |
Beta Was this translation helpful? Give feedback.
-
|
Can you share the simplified program that reproduces the error in the bad room? |
Beta Was this translation helpful? Give feedback.
-
|
I used the version above.... you see the version above has a simple exit mechanism (double click)... very useful for testing and retesting. maybe later today I can get some time for a simpler version... |
Beta Was this translation helpful? Give feedback.
-
|
It would be good to have a test with just the hub, no motors or special setup, no multitasking. Making the test as small as possible rules out other issues. |
Beta Was this translation helpful? Give feedback.
-
|
I am sorry if I didn't said anything else, but the problem vanished... I cannot replicate it anymore. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, As the main failure I'm getting is from broadcast or observe generating the error "OSError: This resource cannot be used in two tasks at once." or one hub trying to get an acknowledgment for it's location broadcast message, but only getting the location broadcast from the other hub, I've been searching for any discussion of hub to hub comms and multitasking. _ which brought me here. However the code example above is quite complex and I'm struggling to establish what's happening when. Are there any good resources/examples for explaining broadcast/observe, especially if they include multitasking. As for example code - mine is harder to follow than the example above... |
Beta Was this translation helpful? Give feedback.
-
|
Hi! Bidirectional broadcasting is a difficult process but it works. The code above was written when I was starting to use it. It tries to illustrate a strange situation which turned out to be very difficult to replicate... If I remember, the Anyway, broadcasting and tasks... here are some thoughts.
Here is some example code for a simple communications object. You make the class Queue:
def __init__(self):
self.fifo=[]
def append(self, element):
self.fifo.append(element)
def get(self):
if len(self.fifo) == 0:
return None
return self.fifo.pop(0)
def next(self):
if len(self.fifo) == 0:
return None
return self.fifo[0]
class CommunicationsHandler:
# This class is supposed to be a singleton but nothing is done to ensure it.
COMMS_WAIT_TIME=const(300)
def __init__(self, hub, observe_ch):
# hub =TechnicHub() or something like that
self.hub=hub
self.send_counter=1
self.observe_ch=observe_ch
self.rec_last_counter=None
self.rec_queue=Queue()
self.send_queue=Queue()
async def loop(self):
while True:
await wait(10)
rec=self.hub.ble.observe(self.observe_ch)
if rec is not None and rec[0] != self.rec_last_counter:
self.rec_last_counter=rec[0]
self.rec_queue.append(rec[1:]) # Remove counter
while self.send_queue.next():
to_send=self.send_queue.get()
await self.hub.ble.broadcast(to_send)
await wait(self.COMMS_WAIT_TIME) # To be sure it is broadcasted properly, give it some time
def send(self, value): # value must be a tupple
self.send_queue.append((self.send_counter,) + value) # add counter
self.send_counter+=1
def next_received(self):
return self.rec_queue.next()
def get_received(self):
return self.rec_queue.get()Hope it helps! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that looks very useful and I shall try it shortly. pseudo code on hub 1 : from pybricks.hubs import CityHub
#from pybricks.parameters import Button, Color, Direction, Port, Side, Stop
from pybricks.parameters import Color
from pybricks.tools import wait
from urandom import randint
hub = CityHub()
hub = CityHub(broadcast_channel=1, observe_channels=[2])
tram_ID = 1
def talk_to_other_tram(message_no, data):
data = [tram_ID, message_no] + data
print(f"Broadcasting {message_no}")
hub.ble.broadcast(data)
print("Waiting for a response.")
while True:
# Receive response broadcast from the other hub.
data = hub.ble.observe(2)
if data is None:
# No data has been received in the last 1 second.
hub.light.on(Color.RED)
else:
# Data was received and is less that one second old.
hub.light.on(Color.GREEN)
print(f" Received : {data}")
if data[1] == message_no:
print(f"That looks like an ack for message {message_no}")
break
wait(200)
return True
for message_count in range(20):
delay = randint(7000, 12000)
print(f"Snoozing for {delay / 1000}s")
wait(delay)
station_ID = message_count % 4
lap_count = message_count // 4
talk_to_other_tram(message_count, [lap_count, station_ID])simplified version of actual code intended for all hubs : from pybricks.hubs import CityHub
from pybricks.parameters import Color
from pybricks.tools import multitask, run_task, wait
from urandom import randint
hub = CityHub(broadcast_channel=2, observe_channels=[1])
my_ID = 2
async def linear_move():
# Simulates hub moving between stations and returns station ID on arrival
print("Moving....")
await wait(10000)
print("Arrived...")
return randint(1,4)
def listen_for_other_tram(tram_ID, last_message_no):
last_message = (tram_ID, last_message_no)
print("waiting for data...")
while True:
data = hub.ble.observe(tram_ID)
if data is None:
# No data has been received in the last 1 second.
hub.light.on(Color.RED)
else:
# Data was received and is less that one second old.
hub.light.on(Color.GREEN)
(sender_ID, message_no, lap_count, stop) = data
print(f" Received message no : {message_no}")
if (sender_ID, message_no) != last_message and sender_ID == tram_ID:
print(f"Message {message_no} : from {tram_ID} " +
f"says Hi from stop {stop} on lap {lap_count}")
last_message = (tram_ID, message_no)
print(f"Braodcasting ack for message {message_no}")
hub.ble.broadcast([my_ID, message_no, True])
print(" Done...")
await wait(1000)
return [lap_count, stop], last_message
await wait(500)
async def main():
last_message = -1
for operations_count in range(11):
print(f"Main : Start of operation {operations_count}")
info = await multitask(linear_move(), listen_for_other_tram(1, last_message), race=True)
print(f"Main : Got \"{info}\" back")
if info[0]: # moving has got to a station...
await wait(1000)
pass # clearly need to do something here....
else: # A message has been recieved from the other tram.
(message, message_ID) = info[1]
last_message = message_ID[1]
print(f"Main : End of operation {operations_count}")
await wait(1500)
run_task(main())Looking at your example code - thanks again, it seems to me that the intention is to launch the 'comms' once for the whole duration, whereas I had planned on reestablishing comms for each 'move'. As the moves are likely to be discrete and variable, I'm guessing to use a single comms object, I'd have to put the move tasks into a nested multitasking routine. I'll have a play, thanks again. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, do a limited number of tasks since the beginning of the program. Send and acknowledge receive won’t work with this broadcast stuff, broadcast was simply not done for that. Put yourself in the train’s "mind". To take the decision of going to a station does not require to acknowledge to the other train that you have received its location (I assume...). |
Beta Was this translation helpful? Give feedback.
-
|
Thank you ever so much for your help. When you try to put yourself in the train's mind, I'm afraid your assumption is wrong. They're sharing the same track, which has passing places, so before tram A can set off, it needs to know the line to the next passing place is clear (they can travel in opposite directions on a single line - no loop) so it needs to know where tram B is. It also (I think - maybe I'm wrong) that it needs to know tram B has acknowledged its location and thus isn't about to head into the same section. Curiously my first (several) attempts with your example got about 4 trips in before a message got lost (possibly when both hubs tried to broadcast location at almost the same time). So now, in the loop around checking for the other train's location and looking for an acknowledgement of this train's location there is a counter and after 40 passes (each loop has a wait(250) in it, it rebroadcasts it's current location and listens for an acknowledgement. This has (you have) got me through 11 'simulated trips' for both trains, which looks robust enough for now..... (famous last words) I now have to re-implement the logic about whether it's safe to proceed, introduce a potential "after you" message for when they're both waiting for the same section from opposite directions and remodularise bits so some logic about acknowledgements and re-broadcasting is handled within the comms package you so generously provided rather than in the "safe to proceed" motor control routines... That said - I've had a blast today playing with the code. |
Beta Was this translation helpful? Give feedback.
-
|
I don't see it that way: every train should be always broadcasting and observing at the same time. This means that train A is assured that train B received its location because train B acts like A does…. Always broadcasting and always observing. So, acknowledgment is implicit and it happens ”always”. This makes the communications layer much simpler. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps I'm overcomplicating things (bad habit of mine). When you say train A is always broadcasting, do you mean it should repeatedly broadcast either "I'm at station x" or "I'm moving from station x to station y" ? Because I can see a logic to that, I just didn't want to swamp the airways with messages as eventaully there will be other 'groups' of hubs talking to one another on a different track. Maybe at that stage I will have to introduce a controller unit to coordinate messages. In my head it just seems easier if the sender knows the message arrived. Some of the messages take a noticeable amount of time to 'arrive'. seconds rather hundreds of milliseconds- that is often when things are going wrong atm. |
Beta Was this translation helpful? Give feedback.
-
|
It's actually the Bluetooth chip that repeats broadcasts at a certain interval. This is just how Bluetooth Low Energy advertisements work. We can set the interval, but it we set it too fast, the Bluetooth chip crashes and if we set it too slow, it there is too much latency to be useful, so we tried to find the best balance. A key point to keep in mind though is that Bluetooth Low Energy was designed to communicate state rather than events. If we can design our programs to use it as the designers of BLE intended rather than trying to make it do something it wasn't designed to do, we can get better results. For example, it should work better to have a message that "the train is X distance from the station" rather than "the train has just arrived to the station". This way, decisions can be made on the current state, no matter what it is rather than having to try to catch a single message for an event. Similarly, the two trains should not be trying to have a conversation (no ack). Both trains should just broadcast their own state and the other train should be programed to react to that state. Another alternative it to not use BLE advertisements (broadcast/observe), but rather have both trains connect to a computer or other BLE device that does the coordinating. Using a connection is much more reliable than advertisements. Reliable enough to use a message based protocol like you have. |
Beta Was this translation helpful? Give feedback.
-
|
Sadly, Christmas has come to an end and it's time to pack up and go back to work. I couldn't get this to work as I had hoped. Each individual element worked, but when running as a multitask operation it all became a too unreliable. Last year, using the lego app on a phone, I had one tram shuttling reliably between 3 stations on a single line, using coloured tiles to indicate where to stop and where to change direction. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everybody!
I wanted to test multitasking and bidirectional TechnicHub hub to hub communication.
So I did a fancy test program that launches several threads and uses one hub button to change the state of the other hub.
The same program runs on each hub, the program detects that there is a motor connected to port A or B, to setup the communication channels.
Almost everything works fine, in fact it seems a funny demo program but:
The very first time I click on one of the hubs, the message is received by the other hub only after about 8s.
Then, everything seems to work fine in that direction. The same problem in the opposite direction.
I also tried with CityHubs and PrimeHubs and it seems to be a problem only related with TechnicHub message reception.
The program is below. The comments includes further details.
Is this a real issue?
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions