Forums Niryo One Troubleshooting initial observations after applying v2.0 software updates Reply To: initial observations after applying v2.0 software updates

Edouard Renard
Post count: 239


@duck Thanks for your valuable feedback and your active participation in the Niryo One community! Also I’m glad that you organized the points very well, that will make things much easier to discuss here in this thread.

@FindingNiryo also thank you for adding some of your observations :)

I’ll try to address here all the points from your problems/wish list.

Before doing that, just a clarification on your point no. 7 of the “Great new stuff”. This behavior is not due to a change in Niryo One Studio, but directly from the Niryo Stepper firmware (here’s the commit for that on github)

Let’s start :)

1. We have roughly tested Niryo One Studio on MacOS (we’re PC users), so we haven’t been able to test everything in depth. I’ve taken note of that and we’ll try to solve that. Maybe related to a security setup, so MacOS blocks inputs and outputs to and from the app.

(For people who read this, also note that we’ve discovered some display issues when running Niryo One Studio inside a virtual machine – tested with VirtualBox and VMware. This is an issue due to the Electron framework and we are also trying to see if we can do something about it.)

2. Same as point 1, this is an issue that only happens in MacOS. We’ll look into it.

3. Agree, and we have tried to do that previously. But the main problem is that inside Blockly (the Google library), it’s often not possible to define which block is the last block. For very simple programs it’s easy but if you add a function, or a block on the side, or anything else that adds more complexity, you can see the problem. There is a discussion somewhere on the web about that with the Blockly creator, but I can’t find it again.

For this issue we may be able to put new blocks in different places so they don’t stack on top of each other

4. As pointed by @FindingNiryo, the name is rotation (x,y,z). This is like that to simplify the terms for novice users. And as I can see it can confuse more advanced users :)

5. Note that a position is defined by a couple of joints AND pose (position + orientation). In the interface you don’t see the pose but it’s still here. I’ll add this to the features backlog though and we’ll see what we can do, so maybe you can see the pose when you save the position, so you can edit this if you want.

6. Related to point 5, the pose is also saved. If you select a position in the “ARM command”, you can choose to take the joints or pose. Same in Blockly. Let me know if you meant something different!

7. Could you precise a little bit more ?

8. This can happen for various reasons: motor not following correctly, magnet not fixed correctly. And sometimes, the software controller may have some problems dealing with trajectory, but that’s more rare. We are also looking at how to make the trajectory success rate higher, so in a future software release that may solve some of the problems.

9. We made a lot of breaking changes between V1.1 and V2.0, so it would be hard to know why the V1.1 sequences are not working correctly on V2.0. I guess you’ll have to redo them :(

10. This is probably due to the motor #3.

I’ve checked the max torque we give to the motor #3 for previous hardware version 1 (as I guess from your post, you have applied the V2.0 software but your robot is still hardware V1), and it seems a little bit high. That could cause the issue you have. If you can, please modify the stepper config file (link here, make sure to go in the /v1 folder). Change the “stepper_3_max_effort” param to 110 or 120, instead of 140. If that’s the issue we’ll change the value on github.

Let me know if what I say is not clear.

If it’s not working then please check if the belt is correctly tensed and the magnet correcly fixed on the motor shaft.

If still not working, I wouldn’t mind seeing a video while you are in a non-noisy environment, so I can see the axis moving and hear the sound of the motor.

11. This is a Blockly related issue, and you can see here the evolution for that (seems to be pretty hard to do). @FindingNiryo provided a really nice workaround here, thanks

12. Added that to the feature backlog. A workaround for now: you can export the XML of the sequence, then go back to the sequence, and edit directly the Blockly XML. Copy the exported XML into the Blockly XML field – and that’s where you have the copy/paste bug on MacOS :)

13. This is something we might do, but not sure. It can quickly become complex: what if you send a sequence to someone else, and that sequence depends on another sequence ? You’d have to send every sequence. Also, what if you delete a sequence that is required in another one?

Using functions is for now the best way to handle well complex programs. You can get a tutorial here.


Well, I hope this answers most of your questions :) Feel free to ask for clarifications.

Thanks for the notes on the possible improvements, we’ve added them into our feature backlog and will try to implement them for the next software release (something like 2.1.0 or 2.0.1)