Discussion

Left ArrowBack to discussions page
Samuel_BouchardSamuel_Bouchard Posts: 149 Handy
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?
Tagged:

Comments

  • matthewd92matthewd92 Posts: 889Founding Pro, Tactile Sensor Beta Testers Handy
    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.....


  • Samuel_BouchardSamuel_Bouchard Posts: 149 Handy
    @matthewd92 yes it does, thanks! @PierreOlivier_Proulx what would be your take on this?


  • PierreOlivier_ProulxPierreOlivier_Proulx Posts: 67Beta Tester VIsion 1.1 Program, Vacuum Beta tester Handy
    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.
    Pierre-Olivier Proulx
    Software Designer
    [email protected]
  • matthewd92matthewd92 Posts: 889Founding Pro, Tactile Sensor Beta Testers Handy
    @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?
  • PierreOlivier_ProulxPierreOlivier_Proulx Posts: 67Beta Tester VIsion 1.1 Program, Vacuum Beta tester Handy
    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.
    Pierre-Olivier Proulx
    Software Designer
    [email protected]
  • matthewd92matthewd92 Posts: 889Founding Pro, Tactile Sensor Beta Testers Handy
    @PierreOlivier_Proulx could you post the function and how you guys are using it?
  • Grady_TurnerGrady_Turner Posts: 67Founding Pro, Partner, Beta Tester VIsion 1.1 Program, Wrist Camera URCap 1.3.0 Handy
    @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
  • matthewd92matthewd92 Posts: 889Founding Pro, Tactile Sensor Beta Testers Handy
    @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.
  • abeachy_HG24abeachy_HG24 Posts: 79 Handy
    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".
  • PierreOlivier_ProulxPierreOlivier_Proulx Posts: 67Beta Tester VIsion 1.1 Program, Vacuum Beta tester Handy
    @matthewd92 @Grady_Turner We don't use that function. I'm just aware it exists. The function signature is :
    assert(Boolean, Boolean)
    The first argument is the expression you want to test. The second I don't know what its effect is. I'll ask UR from more information.
    Pierre-Olivier Proulx
    Software Designer
    [email protected]
  • Grady_TurnerGrady_Turner Posts: 67Founding Pro, Partner, Beta Tester VIsion 1.1 Program, Wrist Camera URCap 1.3.0 Handy
    @PierreOlivier_Proulx  can you give an example of using the assert function?  What kind of fault occurs when the first argument is false?
  • PierreOlivier_ProulxPierreOlivier_Proulx Posts: 67Beta Tester VIsion 1.1 Program, Vacuum Beta tester Handy
    @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.
    Pierre-Olivier Proulx
    Software Designer
    [email protected]
  • Grady_TurnerGrady_Turner Posts: 67Founding Pro, Partner, Beta Tester VIsion 1.1 Program, Wrist Camera URCap 1.3.0 Handy
    @PierreOlivier_Proulx  So it is effectively an E-stop based on a condition.

    Thanks!
Sign In or Register to comment.
Left ArrowBack to discussions page