- BetegustafParticipantFebruary 19, 2019 at 11:43 amPost count: 16
I’m trying to make a sequence of a high number of operations (only n.move_pose) generated from a gcode (only moving along x and y axis) but each time I’m experiencing this error :
Traceback (most recent call last):
File “./traj2.py”, line 275, in <module>
File “/home/niryo/catkin_ws/src/niryo_one_python_api/src/niryo_one_python_api/niryo_one_api.py”, line 275, in move_pose
return self.execute_action(‘niryo_one/commander/robot_action’, RobotMoveAction, goal)
File “/home/niryo/catkin_ws/src/niryo_one_python_api/src/niryo_one_python_api/niryo_one_api.py”, line 191, in execute_action
raise NiryoOneException(‘Goal has been aborted : ‘ + str(response.message))
niryo_one_python_api.niryo_one_api.NiryoOneException: Goal has been aborted : Trajectory timeout – Try to restart the robot
I think that the Niryo arm doesnt have enough time to calculate his trajectory so I reduced the velocity to 50% and made a pause of 0.5sec between each movement instruction. Seems to be a litttle bit better sometimes but it still stops at a moment and never finish the complete program.
Is there any way to avoid this problem using Python API ? By pre-calculating trajectories or maybe using ROS could be faster..Edouard RenardKeymasterFebruary 20, 2019 at 9:21 amPost count: 239
If you want to parse some Gcode and execute many move commands quickly, using the Niryo One Python API with move_pose and move_joint is not a really viable solution.
When using move_pose, the Rpi will compute a whole new trajectory, with start and stop accelerations. The whole process (compute traj, send traj, execute traj, return status and message), as you guessed, is quite heavy and not suited for small and very quick trajectories following each other.
If you want to correctly use Gcode, you’ll have to adapt or write some code. I guess one solution could be:
– Create a Gcode parsing program
– Interpolate directly the linear path
– For each point, compute inverse kinematics with the /compute_ik service (already set up when using the Niryo One ROS stack with Moveit)
– Send the IK directly to the “/niryo_one_follow_joint_trajectory_controller/command” topic (see how joint trajectory controller is working with the topic interface)
I haven’t tested it, so I can’t tell if it works well or not.BetegustafParticipantFebruary 22, 2019 at 12:29 pmPost count: 16
Thanks for the answer I had the same idea to accelerate the process so it might work, but if I can use all the great work you have done it would save me some time (if possible) so I have investigate a little and made few tests to understand the origin of this problem. It appears that this error sometimes prompts with just 1 or 2 movements instruction wich is quite annoying. I also made a test to see the limit for quick steps : the robot is going on a line of 10cm and I increase more and more the number of intermediate points (steps) the result is that niryo seems to easily be able to do at full speed quick steps (0.6mm) on these 10cm, just to make an extreme test: for 0.3mm steps niryo succeeds to do some but not the complete 10cm line.
I think the problem comes more from positions where MoveIt can’t resolve or take too much time to resolve and make a trajectory, this happens randomly even on easy trajectories/path (when we check the CPU usage while running the programm on the arm we clearly see a peak just before the error occurs).
Trying to reduce these errors I’m exploring some modifications for example in kinematics.yaml: “kinematics_solver_timeout: 0.05” instead of 0.005 seems the be a good way but I cant tell if it is really slighlty better.
I didnt find any problem of that kind on internet and I don’t know if people are experiencing this problem with their niryo.. maybe you are more aware and got some ways to solve/hide this error ?Edouard RenardKeymasterFebruary 22, 2019 at 2:02 pmPost count: 239
Increasing the kinematic solver timeout could indeed reduce the error numbers. If you want to set this param with the code directly, here’s the file on github.
One thing to take into account is that the Niryo One ROS stack is running on a Raspberry Pi 3B board. The computation power is really limited compared to standard laptops used in robotics research with ROS. Most of the ROS stuff you can find on the Internet is running on fast and powerful computers.BetegustafParticipantFebruary 28, 2019 at 11:35 amPost count: 16
I ‘m trying to make a python file (as a “normal programm” using python API for flexibility) to calculate trajectories and then execute it, I would like to use the cartesian path (with move_group.compute_cartesian_path) wich is what I want at the end (I’m not sure if it’s possible and as easy with the niryo /niryo_one_follow_joint_trajectory_controller/command).
I ran into a problem :
when I use “move_group.get_current_pose().pose” if I print it I get a difference on rotation x,y,z (value returned is approximately half of the value printed on Niryo One studio) resulting in error ABORTED: Solution found but controller failed during execution
I guess I made a mistake when using:
group_name = “arm”
move_group = moveit_commander.MoveGroupCommander(group_name)
Here is my file if you have any advice :
https://github.com/Tmehault/cartesian-path/blob/master/CartesianPath.pyEdouard RenardKeymasterMarch 1, 2019 at 3:56 pmPost count: 239
Instead of using the “move_group.get_current_pose().pose”, I suggest you get the current pose from the “/niryo_one/robot_state” topic. This data is maybe more up to date, directly listening to the current state of the robot.
See here the code with the publisher for this topic, so you have the reference to write a subscriber.
Let me know if this gets any better!BetegustafParticipantMarch 5, 2019 at 11:48 amPost count: 16
This was the solution to the problem, I also had to make a start state from a RobotState Moveit msg (different from Niryo One RobotState msg: easiest solution is to import it with a different name) and now the robot is moving great. Pre-processing is super efficient for what I wanted: for anybody who wants this specific solution here is a little comparison of what you can get from this method : On a 10 tries gcode test containing 172 points
-Python API via n.movepose() : 7 errors, average elapsed time when success 161.375sec
-Compute_cartesian_path() : 0 errors, average calculation time: 1.151sec, average execution time:14.77sec
Compute cartesian path is a really good solution to have a smooth trajectory, it has great results but you will not be able to move the tool as n.movepose() do.
- You must be logged in to reply to this topic.