We are wanting to control reachy directly from a macbook to make computation faster by connecting the Luous module directly to the mac through USB, and did as I outlined here to find the relevant port to connect to.
I am now running a simple script which initialises the arm through that port, makes the motors stiff, sets the PID to [32, 0, 0] and simply calls goto() to a point in 3D space.
This works completely fine with the arm connected to the raspberry pi.
However, calling the script through the laptop caused the arm to move in an extremely jerky manner! (Imagine PID being set to something extremely high and you can visualise how the arm is moving when being controlled form the laptop).
It looks as if the laptop is sending the commands at a slow rate rather than continuously?
All I ran on my mac was pip3 install reachy and that seemed to be enough to be able to successfully connect to reachy. Perhaps there’s something else I am missing?
Any ideas as to why this is happening? Would massively appreciate any help on this!
It turns out this is an issue that only showed up when controlling the arm through my laptop. When I tried communicating with reachy through a colleague’s macbook, it worked fine. Strange but at least it works now!
Exception in thread Thread-1:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/threading.py", line 932, in _bootstrap_inner
self.run()
File "/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/threading.py", line 870, in run
self._target(*self._args, **self._kwargs)
File "/Users/<user>/.virtualenvs/cv/lib/python3.8/site-packages/pyluos/io/serial_io.py", line 89, in _poll
to_read = self._serial.in_waiting
File "/Users/<user>/.virtualenvs/cv/lib/python3.8/site-packages/serial/serialposix.py", line 467, in in_waiting
s = fcntl.ioctl(self.fd, TIOCINQ, TIOCM_zero_str)
OSError: [Errno 6] Device not configured
We are getting it frequently and randomly during arm operation only when connected to the mac, never with the Pi. When the error occurs, the arm stops responding to the commands and since it’s on a thread, the main thread continues but the arm stays as it is.
I feel that it is unlikely that the first option is the issue as the same program is used on the Pi with the same threads and with no issue (unless the macbook has some internal program that simultaneously talks to the serial port?)
In case the second option is the reason, would there be a way to add some retry logic to prevent the single call during the boot process?
I’m using a MacBook as well and I sometimes got this kind of issue when using an USB-C to USB2 adapter only powered by the USB port. Maybe this could also be your problem?