After upgrading from ROS indigo to kinetic, an instance of rosserial_python/serial_node.py generates the following error, repeatedly:
Serial Port read returned short (expected 99 bytes, received 64 instead).
Prior to the upgrade, the instance worked fine. Arduino code was simply recompiled with the kinetic's support code.
My investigation leads me to believe that the serial port read behaviour is not suitable for specified timeout. In SerialClient.py, Line 401, tryRead(), it seems that rosserial_python expects a serial read operation to return exactly the amount of data requested:
However, as per the pySerial documentation, this is true only if timeout is set to 0. That isn't the case for the serial port used in SerialClient.py (By default), as seen around Line 324:
With the default arguments, the timeout value is nonzero.
The issue is fixed when tryRead() is changed such that self.port.read() gets called in a loop until length amount of data. This was a stopgap measure from my side; if the client actualy stops short, the read operation will get stuck.
I don't know why migrating from trusty/indigo to xenial/kinetic aggravated this issue.
May be related to #186.
After upgrading from ROS indigo to kinetic, an instance of
rosserial_python/serial_node.py
generates the following error, repeatedly:Serial Port read returned short (expected 99 bytes, received 64 instead).
Prior to the upgrade, the instance worked fine. Arduino code was simply recompiled with the kinetic's support code. My investigation leads me to believe that the serial port read behaviour is not suitable for specified timeout. In SerialClient.py, Line 401,tryRead()
, it seems thatrosserial_python
expects a serial read operation to return exactly the amount of data requested:However, as per the pySerial documentation, this is true only if timeout is set to 0. That isn't the case for the serial port used in SerialClient.py (By default), as seen around Line 324:
With the default arguments, the timeout value is nonzero. The issue is fixed when
tryRead()
is changed such thatself.port.read()
gets called in a loop untillength
amount of data. This was a stopgap measure from my side; if the client actualy stops short, the read operation will get stuck. I don't know why migrating from trusty/indigo to xenial/kinetic aggravated this issue. May be related to #186.