Hey guys! We are progressing fast through the autonomous code and stumbled across another issue. Here’s the code:
def on_autonomous_enable(self, payload: AvrAutonomousEnablePayload):
did_message_recieve = payload[“enabled”]
logger.debug(f"visible tag: {self.visible_tag}“)
logger.debug(f"recieved auton enable: {did_message_recieve}”)
start = time.time ()
finish_1 = start + 4
finish_2 = start + 5
finish_3 = start + 6
# Check if there is a visible april tag, if the vehicle is within specified horizontal tolerance, and if the vehicle has not already dropped the water
if self.visible_tag == 0:
timing_message_1 = True
self.open_servo(0) # Open servo on channel 0
while time.time () < finish_1:
pass
logger.debug(f"timing_message_1: {timing_message_1}“)
self.blink_leds(0.5) # Blink LEDs 1 times at 0.5 second interval
while time.time () < finish_2:
pass
self.blink_leds(0.5) # Blink LEDs 1 times at 0.5 second interval
while time.time () < finish_3:
pass
self.blink_leds(0.5) # Blink LEDs 1 times at 0.5 second interval
self.close_servo(0)
self.has_dropped = True
logger.debug(f"self.has_dropped: {self.has_dropped}”)
Our problem is that the PCC doesn’t receive messages until the function has run. For example, it will run through the code, spit out the logger messages, go through the delays, and finally spit out the self.has_dropped result. Only then does it send the messages to open and close the servo, as well as the LEDs. This causes it to do it all at once, bypassing out timing and screwing everything up. We have them sitting in another function, could that be the problem? Or do we have to use the serial messages shown in pypi.org? Any help is appreciated.
Okay, so what I would recommend is to use MQTT messages to control the PCC, rather than a serial connection. I’m pretty certain the PCM module will block the connection to the serial device to some extent, which is likely causing your timing issues. The architecture of the software stack as a whole is such that each module is sort of a hardware-to-MQTT translator, so I highly recommend sticking with 100% MQTT communications.
Unrelated, your:
while time.time () < finish_1:
pass
loops, can easily be replaced with time.sleep(number) statements instead, where number is the number of seconds to wait.
We tried time.sleep() and it stopped all code on the jetson, causing it to stop and it caused the GUI to crash. Also, we are using MQTT messages already, right? If so what is causing out problem?
Something that I just thought about trying would be to put the send message thingy to the PCC inside of the main function instead of separating it into different, external functions.
Some good news, I can replicate the problem, just running your Sandbox code on my desktop, without any PCC or Jetson, so I think this is a pure Python programming issue. I’ll reply back once I figure something out.
Short explanation: It’s a bug in the bell-avr-libraries package that prevented MQTT messages from being sent until after a callback function was complete
Long explanation: With how paho-mqtt works, it holds onto a mutex (mutual exclusion) during callbacks to prevent multiple MQTT events from happening at once and getting lost. What this meant, was the sending messages were getting queued until the function returned, and then they’d be sent all at once. We’ve never run into this before, since we never put time.sleep in our MQTT callbacks. Thankfully, they expose a way to pre-emptively send messages, if you’re using the loop_forever() function, which the Sandbox does.
This PR should fix the issue once it has been merged and published: