DoF - a Robotiq Community
Warning sign
The Dof Community was shut down in June 2023. This is a read-only archive.
If you have questions about Robotiq products please reach our support team.

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.....


I think it's great to apply software engineering practices to robot programming. Versioning is a must and I think it pays when tracking a bug introduced in a previous commit. You only need to rewind your software history to find what change is faulty.

Unit test is also useful and I think its main benefit is to give confidence in the code. If your code is under a test harness, you can be confident that modifications to your code won't break previous functionalities (given the tests cover the programmer's initial intentions). By the way, UR has the assert(<boolean>) function that can be useful for unit testing.

On our side have started to setup a build server to test our UR functions. We use
jenkins to do so. Broadly, what jenkins does it to monitor our repository for new commits. Once the repo changes, jenkins pulls the changes and executes a script. That script first launch a URSim instance and then sends various urscript tests to the simulator. Those urscript tests report the expectations back to the server using a raw tcp socket. This way we can make sure that changes we make does not break previous functionalities. But more important I think, is that if UR changes the behavior of their api, we will know it before we get a service call. This is still embryonic but I'm confident that it will be useful.