Skip to main content

General Discussion

I've released software version 7.0

This includes a complete Python API for the robot, new features for the virtual offline robot as well as a few minor bug fixes on the Modbus communication and kinematics.

Please checkout the new software and let me know if you have any questions or issues. Reach out to me anytime at info@anninrobotics.com

  • 2 likes
  • 5 comments

bsom

Is this only for the MK5? Can I use 7.0 with my MK3 robots?

Chris Annin

bsom Yes you can use the software for your MK3. If you go to the Robot Parameters tab, select the AR3 defaults and then click save that should load the correct parameters for your MK3. Reach out to me if you have any issues.

David Rohrbach

I run into the following issues with the 7.0-version on my AR4-MK4 (using the corresponding defaults): When I try to move the robot to certain positions, the software freezes and the position is not reached (e.g. for position [x,y,z,rz,ry,rx] = [420, 147, 90, 0, 170, 0]). I need then to reopen and recalibrate the AR4. When trying to reach this postion using the python-API, I obtained the error in the serial_connection.write(command.encode()) ('SerialException("WriteFile failed ({!r})".format(ctypes.WinError()))') .
Is this already a known issue?

Chris Annin

David Rohrbach 
Thanks for reporting this. I would definitely like to dig into it further. The WriteFile failed serial error is particularly useful information because that normally indicates that Windows was no longer able to write to the Teensy COM port, rather than simply the robot being commanded to an unreachable Cartesian position.

There are a few possibilities I want to investigate. Version 7.0 includes a number of changes to the kinematics and motion handling, and it is possible that a particular Cartesian position/orientation is exposing an edge case in the inverse-kinematics calculations. If the Teensy firmware were to hang or reset while processing a move, that could explain both the HMI appearing to freeze and the Python API subsequently reporting a serial WriteFile failure. I also want to rule out an incorrect or unapplied MK4 parameter set, or a more general USB/serial communication issue.

Could you please email me at info@anninrobotics.com with the following information?

  • The exact HMI 7.0 version/build you are using and the exact Teensy 7.0 sketch/firmware currently loaded on the controller.
  • When you say you are using the “corresponding defaults,” can you confirm that you selected Load AR4-MK4 Defaults and then clicked SAVE, and that no robot parameters were manually changed afterward? A screenshot of the Robot Parameters screen would also be helpful.
  • Please send the complete Python traceback, particularly the actual Windows error contained inside WinError(...).
  • When using the Python API, does WriteFile failed occur on the first move command immediately after connecting, or does it only occur after a movement has already frozen or failed?
  • While reproducing the problem, please watch the Teensy COM port in Windows Device Manager. I would like to know whether the COM port disappears and then comes back, which would indicate the Teensy is resetting/USB is disconnecting, or whether the COM port remains present but the controller simply stops responding.
  • If possible, please try the same Cartesian position while slightly changing the Ry value—for example 168°, 169°, 170°, 171°, and 172°—while starting from the same robot position each time. This may help determine whether we are crossing a particular kinematic solution boundary.
  • Finally, if practical, please try the exact same move using the AR4-MK4 6.7 HMI with the matching 6.7 Teensy firmware. If the position works consistently in 6.7 but fails in 7.0, that would be extremely helpful in isolating this to a 7.0 regression.

Also, for the Python test, please send me the exact move_cartesian(...) command you are using. The HMI and Python API describe the orientation arguments slightly differently, so I would like to verify that as well. For the specific [420, 147, 90, 0, 170, 0] example it probably does not make a difference because the first and last rotation values are both zero, but it could matter for some of the other positions you have seen fail.

I will start looking into the firmware and kinematics side of this right away. Once we get to the bottom of it and determine the actual cause, I will report back here on this community post with the final outcome and any correction that is needed.

Thanks again for bringing it to my attention,

Chris

David Rohrbach

This issue has been resolved - it turned out that one of my J2 limit-switch wire contacts ground in this special position, causing the Teensy to reset. Unfortunately this issue with my wire isolation just popped up after I did the software-update; directing me in the wrong direction. Thanks Chris for your assistance and putting me back on the right track so quickly.