FindingNiryoParticipantOctober 10, 2018 at 7:43 pmPost count: 105
Using only constants on move commands is very restrictive.
Shift <axis> by NN does not maintain values for the other five axis and
introduces significant accumulated errors in position.
Probably caused by using the current value for all axis rather than previous target for all values.Edouard RenardKeymasterOctober 15, 2018 at 5:01 pmPost count: 239
Yes, you’re right about that. The shift_pose will take the current state of the robot, not the previous command data.
What you should do here is use only move_pose but with incremental values. Which is not fast to do with Blockly. And that’s where you find yourself at the limit between using visual programming and using real programming.
Blockly is really something made for non technical person who don’t know how to program. It’s fine to create simple programs, but once you want to go further (for example, your use case, or creating much bigger functions), you should really use real programming. This will be much simpler to maintain and to use. The Google creator of Blockly stated that Blockly is really for people to learn programming without the syntax, so they can later use programming with real language. So it was not made to create complex stuff, almost on purpose. And we also don’t want to add so many features that it will over-complicate things for new users. Hope you understand.
Great for you: The Niryo One Blockly Blocks are in fact directly calling the Niryo One Python API. You can directly use this API to control the robot, which will let you have all the benefits of direct programming with Python.
You can run your script through ssh so you have a full remote control over the robot !FindingNiryoParticipantOctober 15, 2018 at 5:07 pmPost count: 105
I understand the decision to keep blockly simple and appreciate your suggestions about the python API.
I do not understand having Shift <axis> by NN based on current position. This seems to make this API command unusable.Edouard RenardKeymasterOctober 16, 2018 at 8:53 amPost count: 239
In fact, all the “move” functions are directly linked to the “move” function of Moveit!, the motion planning library for ROS that we use.
You can find the doc here, and see more info about “move_pose_target”, “move_joint_target”, and “move_shift_target”.
It does make sense for Moveit to add a Shift pose starting from current position. Though I agree that on Niryo One, as the robot is not so precise as an industrial robot, the function is quite limited. Also I guess that they didn’t develop a “shift pose from current target” because that’s something totally doable in the code where you use the Moveit library.
You must be logged in to reply to this topic.