Pyuarm 2.2.5.1 strange behaviours

uArm Swift (Pro) Troubleshooting
1

Using firmware 2.2.1 with pyuarm 2.2.5.1 and I’m finding some strange behaviours that I thought would be useful to document.

  1. Using set_position(x,y,z,speed,relative) with the relative=True is currently always returning False.

I’ve found that the only way to avoid this and actually control the robot in relative terms is to set speed=0. If speed is not zero, the uArm returns error “E10”; which is undocumented in the new protocol pdf.

  1. get_analog and get_digital do not appear to be parsing the uarm response correctly.

Outputting the raw response from the uarm reveals that the uarm is reading the analog pin correctly: “$4 OK V473”; however the value returned from get_analog is always None. This is the same for get_digital().

Looking at uarm.py, this appears to be due to these functions parsing the data using the method for the old communication protocol?

To others, if you’re trying to use the new pyuarm and finding issues with non-functioning read functions, check the raw response in uarm.py and check this matches with the parsing method. If you find non-functioning command functions, try experiment with parameters…

2

Much agree with you, both the protocol document and the “pyuarm” are horrible…

3

Hi asena,

pyuarm has been updated to V2.2.5.3, which can fix the get_analog and get_digital problem

pyuarm V2.2.5.3 changes:

  1. Support wait for set_position
  2. Fix get_analog, get_digital

the problem of controlling uArm in relative terms is a bug of firmware V2.2.1.
Now we’re fixing it.
I’ll keep you updated.

4

Hi cleo,
pyuarm 2.2.5.3 with firmware 2.2.1 problem:

" pylogger.info(msg)
AttributeError: ‘int’ object has no attribute ‘info’ "
in util.py file

5

Hi, i failed to reproduce the problem.
Could you please send your codes and the feedback you received to the email address below?
developer@ufactory.cc

6

Sorry it was my fault, I was trying to initialize with uarm(port,baud rate)