UART-BLE communication "quirks" with CM-550

This is a report about a communication issue that I encountered when I tried to use both UART and BLE ports to control a CM-550 robot (Pan-Tilt Commando, PTC). The CM-550’s UART port is used by an RPi4B (with a Pi Cam) to transmit Object Tracking Data over to the CM-550 so that PTC can be autonomously controlled to keep the object “centered”. The BLE port is used by the ENGINEER App running on a Samsung S6 Lite so that “simultaneously” the human operator can “interfere” into this autonomous behavior. The enclosed video has more details, but essentially I found that the current CM-550 firmware seems to “favor” BLE over UART regarding the data packets that the CM-550 received via both Ports at the same time.

UPDATE 4/17/2021:
Very glad to report that I had found a solution to my communications needs and this was the first time that I got to use all THREE COM ports on the CM-550. Please see first picture below for the overall communications scheme used:

  1. The RPi4B is using an OTG-USB cable to send Remocon packets to the CM-550 through its micro-USB port. The CM-550 is not sending anything back to the RPi4B in this project.
  2. The CM-550 is communicating (both ways) to the ENGINEER App via the BLE port.
  3. The CM-550 is sending its Console Printing data (IMU’s Yaw Angle) to a Desktop PC - via the Program Output Monitor of TASK 3 (see 2nd picture below), and it is using the CM-550’s UART Port and a BT-210 Receiver.

In the second picture, on the RPi4B, I was using Visual Studio Code and Python (right window). The CM-550 was running its own TASK code with SMART Calls to the ENGINEER App. For the discerning “eyes”, you can see that the Object Data (X, Y, Area) triplet USED by the CM-550 (as shown in the Upper Left Window for the ENGINEER App) is half-a-cycle OFF as compared to the triplet sent out by the RPi4B (i.e. the Area item was from the “previous” triplet sent out by RPi4B). But all communications were stable otherwise!!!
The robot was able to maintain tracking of the blue Ping-Pong ball, although not “very fast” (as compared to the same job on the Desktop PC - of course :wink:).
These results show that there is a path forward to use a Desktop PC in a Supervisory Control role with respect to several RPi+CM-550 based robots, while receiving Sensors (and other) data from them as needed. :grinning:.