I'd like to hear your advices on robot programming best practices. Do you use any standard in your organisation (commenting, naming variables, tracking versions, cleaning the code, keeping it simple, testing, etc.)? Do you include this in your training? If you're using a standard, why did you implement it and what as been the impact so far?

We have changed the way we program the robots to give us the ability to basically run unit tests on the various steps within the process.  This has given us the ability to quickly debug portions of the code and then move onto new pieces of code and keep going.  We then link all of these small modules back together to make the program that runs on the robot.  It also gives us small modules that can quickly be reused in other programs.

We use a private GitHub account to store our robot program back-ups so that we have them no matter where we are in the country/world and can quickly recover should we experience a catastrophic failure on any of the robots.

As far as variable naming we have moved to camel case for our variables, helps to keep them clean and its easier to type then adding a _ between words.  We do wish however that UR would open up the variable name to more than 15 characters.  We try to be as descriptive as possible with the variable names so that they are easy to reuse

Reusable code, we write a lot of code to be reusable between programs and have a basic framework that we start programs from that include all of our custom API scripts that we have written for doing our own repetitive tasks.  In that is also the framework for the Robotiq gripper script.  We are just now starting to move to the new Robotic URCap but we have historically not used the subprograms from Robotiq but rather just call the scripts.  This makes the code cleaner to read and gives us the ability to use subprograms in our main program and still be able to use the gripper.

As far as simplicity, our code probably tends to be a little more complex than traditional code but we are running robots from afar and so its important that we are able to track exactly what is going on at a customer site as well as quickly update/modify code to meet customer requirements.  Many of these updates can be made remotely so to limit the amount of travel that we are needing to do to make what would be a simple change to the program.  To have the ability to do this easily requires that the code be more modular and therefore a little heavier than what we wrote in the past when the robots were just on the other side of the wall from us.

If we are using pneumatic grippers or opening and closing cylinders we will generally create a script function for that such as openGripper() or closeGripper(), we may even pass in a variable to identify what gripper we are opening and closing or what cylinder.  We do this for readability of the code as well as its just easier to program as we find it faster to type then poke around on the screen.

Another thing that we do that helps speed up the process is use a wireless mouse and keyboard.  Its much quicker to type and use a mouse to move around the screen and its just one of those things that makes our job easier.  Another simple thing that we do is use a selector switch wired in as a freedrive input so that we can put the robot in freedrive and then use both hands to move it around.  This is very beneficial on the UR10 as that thing is hard to move with just one hand.

@Samuel_Bouchard hope this kind of answers the question.....

@matthewd92 yes it does, thanks! @PierreOlivier_Proulx what would be your take on this?

@PierreOlivier_Proulx I am not aware of the UR assert functionality.  Where can I find some information on that?  Or are you referring to UR Cap SDK?

It is not documented. It is a urscript function. I don't recall who told me about it. It takes two parameters. The first one is a boolean expression. When it evaluates to false, it cause a controller fault. The second one is optional and I don't know what it is use for.

@PierreOlivier_Proulx could you post the function and how you guys are using it?

@PierreOlivier_Proulx

I would be very interested in knowing more about the assert function as well.  @matthewd92  have you tested this any further?  If so what did you find?

Also for the original question:  UR's Folder function saves me a lot of time.  Similar to @matthewd92 I like to break down an application into small, separate parts for testing ideas and building "blocks."  I do these all in separate test programs, but the first thing I do in those programs is make a folder with an appropriate name.  From there copying and pasting folders into the actual application program saves me from a lot of hassle

@Grady_Turner I haven't but I don't have any documentation on it either so not quite sure how to use it for testing.  I also use the folders a lot to make copying and pasting easier. It would be nice if with the Polyscope interface you could select more than 1 item at a time to copy and paste.

We have created a standard for how we program the robots and we plan on implementing this into our training for maintenance and manufacturing engineers. I developed a naming standard that has been working great for us, we got lucky and it fits right into the character limit but is still descriptive.

In order to help recover from a power outage or power surge, we are using an installation variable and case statements to step through the program. We are doing this so the PLC can keep track of where the robot is at in its program and we can restart from that point if needed.

To keep the program easy to follow, in each case all of the waypoints are placed in a folder that describes what is happening in that case. And then anywhere we use an "if-statement" a folder is placed in it to describe what happens in within in that "if".

@matthewd92 @Grady_Turner We don't use that function. I'm just aware it exists. The function signature is :

assert(Boolean, Boolean)

@PierreOlivier_Proulx  can you give an example of using the assert function?  What kind of fault occurs when the first argument is false?

@Grady_Turner You can test really anything. The behavior is that the robot will go in fault mode, then in power off mode.

Let say you have an application where the robot must not apply more that a certain level of force. You could add an assert like this: assert(norm(force()) < FORCE_LIMIT). Whenever the force goes above the threshold, the arm is powered off.

@PierreOlivier_Proulx  So it is effectively an E-stop based on a condition.

Thanks!