Release of URCap SDK 1.8.0, PolyScope 5.5 and 3.11 - and a new UR16e!

[jbm]

Dear valued developers,

Universal Robots is delighted to announce, that we are now releasing a new software, to continuously deliver more value to you and our customers. The new release consist of:

• PolyScope 5.5.1 for e-Series
• PolyScope 3.11.0 for CB3
• URCap SDK 1.8.0 including URCap API 1.8.0 for both platforms

And furthermore, we are expanding our e-Series lineup with a brand new robot model;

The UR16e

The UR16e offers unparalleled payload capacity of 16 kg, with a reach of 900 mm.
It is Built To Do More, and ready to join our flagship family of e-Series robots.
Find more information about UR16e.

Key Features of the software release

The key features in this release is:

API

We are introducing a new type of Contribution in the URCaps API; the Driver contribution.
URCaps can now contribute a Gripper to PolyScope, allowing the creation of this device type in a new device-contextual API.

• URCaps can implement Gripper driver contributions to add functionality for gripping devices to PolyScope:
  • Benefits:
    • Makes it significantly easier to create a new Gripper in PolyScope
    • Developer can focus only on the interfacing between UR and the Gripper
    • Users gets a simple and uniform user experience when operating gripper devices.
  • Extension Points:
    When creating a GripperContribution, the following extension points in PolyScope are automatically used:
    • A Program Node for the gripper, top operate this in the context of the program.
    • A Toolbar, allowing the user to “live control” the gripper while programming / operating the robot. (only e-Series)
    • An optional Installation Node, to allow users to configure various settings for the gripper (defined by the URCap).

Check out the new URCap Driver samples at GitHub!

Other features

• RTDE now supports 6 simultaneous clients (previously 3)
• Improved debugging of programs, including line numbers in PolyScope

Notice:

With this release and going forward, when a URCap needs to depend on the version of the URCap API included in this release (i.e. version 1.8.0) or newer, the approach previously described in the URCap tutorial should not be fully followed:

• It is no longer required to update the version range under the <Import-Package> section in the ‘pom.xml’ for the URCap project
• It is still necessary to update to the desired version in the URCap API dependency under the <dependencies> section in the ‘pom.xml’ file

Note, that if the versions range under the <Import-Package> section is updated, the result could be that the URCap will fail to start when PolyScope starts up.

Get started with the new API

You can download the latest URCaps SDK and URCaps Starter Package under the Download Center.
Find the latest PolyScope software on the UR Support Site.

URCap SDK and API release notes

Please find the release notes related to the URCap API and SDK 1.8 below:

URCaps API

• URCaps can implement Gripper driver contributions to add functionality for gripping devices to PolyScope:
  • Benefits of support for Gripper driver contributions:
    • Makes it extremely easy and fast to create URCaps supporting grippers in PolyScope by reducing development complexity and time significantly
    • Allows URCap developers to focus on implementing the specific functionality related to how their product works instead spending time on implementing, e.g. UIs, handling of defined/undefined program node state and handling storing/retrieving data.
    • Provides users a simplified and uniform user experience when working with grippers in PolyScope.
  • A Gripper driver contribution will automatically add the following to PolyScope:
    • A program node for the gripper with a corresponding standard screen which allows the user to program grip and release actions. The configuration options available to the user are based on what functionality the gripper supports.
      
      
      
      
      
    • A toolbar for the gripper providing the user quick access to perform grip and release actions using “default” gripper action parameters.
      
      
      • Note: The toolbar is not available on CB3 robots.
    • An optional installation node for the gripper which allows the user to setup the gripper using a custom UI (only if the URCap chooses to define one)
      
      
  • A Gripper driver contribution enables the URCap to:
    • Specify a name for the Gripper driver contribution. The name is used as title in the program node, installation node and the toolbar.
    • Optionally provide a custom logo. The logo is displayed in the program node, installation node and the toolbar.
    • Optionally contribute a TCP for the gripper to PolyScope.
    • Optionally read the settings of the Tool I/O Interface as well as request exclusive control of the configuration of the Tool I/O Interface resource and exclusively configure the settings of this interface if the control request is granted to the URCap.
    • Support “default” grip and release actions. This is mandatory for all Gripper driver contributions.
    • Optionally support one or more gripper capabilities:
      • Supported types of capabilities:
        • Width: The gripper can move to a user configurable position, i.e open/close (grip/release) to a specified width
        • Speed: The gripper can perform grip and release actions using a user configurable speed
        • Force: The gripper can grip using a user configurable force
        • Vacuum/Pressure: The Gripper can grip using a user configurable vacuum/pressure level (by suction cups or pneumatically operated fingers)
      • The parameter range supported by the gripper as well as a default value for a grip and/or release operation are specified when a capability is registered.
      • Parameter ranges and default values can be updated after registration, if these need to change based on a different setting, e.g. depending on the fingertips mounted on the gripper. If the current configuration of a gripper program node in the program becomes invalid after the parameter range has been updated, the program node is automatically marked as undefined.
      • The parameters are displayed in the program node to allow the user to configure the registered capabilities
      • See the new ‘contribution.driver.gripper.capability’ Java package
    • Optionally generate script code necessary for initializing the gripper. The script code is added to the preamble section of a robot program.
    • Generate script code for performing grip and release actions when:
      • A program (with a gripper program node) is executed
      • The user tests a configuration of a gripper program node
      • The user operates the gripper using the toolbar
    • Optionally define a custom UI in the installation node using a general framework for building UIs to allow the user to setup the gripper:
      
      
      • Supported user input types:
        • Integer input: Allows the user to enter an integer in a specified range through a number text field (with a specified initial value)
        • Double (decimal number) input: Allows the user to enter an integer in a specified range through a number text field (with a specified initial value)
        • String input: Allows the user to enter a string through a text field (with a specified initial text)
        • IP address input: Allows the user to enter an IP address through a text field (with a specified initial IP address string)
        • Boolean input: Allows the user to make a selection using a checkbox (with a specified initial selection)
        • Selection input: Allows the user to make a selection using a combo box:
          • There are two options for the initial selection in the combo box:
            • One of the elements is pre-selected
            • The initial selection is a specified string. The string should inform the user what is to be selected or describe what action to do, e.g. “” or “”. Note: Only static content in the combo box is supported, i.e. it is not possible to update/change the content after the user input has been registered. Validation of user inputs: Integer, double and IP address user inputs have default error input validators pre-defined For integer, double, IP address string user inputs, it is possible to optionally add a custom error input validator Supported non-user input UI element types: Description text: A single description text for the installation screen Text element: A text with an optional icon, e.g. for displaying status information to the user. Filler element: An element not visible on the screen, that can used to control/group the layout. Support for handling backwards capability between versions of the URCap: Enables the URCap to migrate/adapt an existing value of a user input saved with an older version of the URCap to a new user input definition/format defined in a newer URCap version, so the user’s previously stored configuration is not lost. This is achieved by marking an old user input as deprecated, converting the old user input value and using the converted value to register a new user input. Deprecating user inputs is useful when a previous version of the URCap had a need for the given user input, but the current version no longer needs it. This can for instance be relevant when the “format” of the user input needs to be changed in a new URCap version, e.g. a previously defined checkbox user input needs to be changed to a combo box user input. See the ‘deprecateUserInput(UserInput)’ method in the ‘CustomUserInputConfiguration’ interface in the new ‘contribution.driver.general.userinput’ Java package. General functionality: A maximum of 10 user input and non-user input UI elements can be added (not including the description text). User input and non-user input UI elements are added in a two-column layout grid (except for the description text) When all user inputs and non-user input UI elements have been added, the custom UI is automatically generated and made available in the installation node. Any gripper program node in the program is marked as undefined, if the custom setup in the gripper installation node is incomplete, e.g. if the user has not yet made an selection in a combo box input or a user input contains an error. See the content in the new ‘contribution.driver.general.userinput’ Java package. See the all content including the ‘GripperContribution’ main interface in the new ‘contribution.driver.gripper’ Java package. The following functionality is automatically handled for the URCap: Retrieving and storing of data The defined/undefined state of the gripper program node Extended the ‘RobotType’ enum in the existing ‘RobotModel’ interface (in the ‘domain.robot’ Java package) with the new UR16 robot type. URCaps can create and insert Screwdriving Nodes into the Program Tree: See the new ‘ScrewdrivingNode’ interface in the ‘domain.program.nodes.builtin’ Java package See the new ‘createScrewdrivingNode()’ method in the existing ‘ProgramNodeFactory’ interface (in the ‘domain.program.nodes’ Java package). Note: The Screwdriving Node is only available on e-Series robots. Before attempting to insert a Screwdriving node, remember to check if the node type is available on the system using the ’ SCREWDRIVING’ value in the new ‘ProgramNodeCapability’ capability enum (in the ‘domain.system.capability.programnodefactory’ Java package) with the ‘hasCapability(Capability)’ method of the ‘CapabilityManager’ interface. URCaps SDK URCap SDK: Added new URCap samples: ‘Simple Gripper’: Demonstrates how to create a gripper driver contribution for a basic gripper that only supports the mandatory “default” grip and release actions. The URCap uses I/Os in the script code generation to trigger grip/release actions. ‘Advanced Gripper’: Demonstrates how to create a gripper driver contribution for a more advanced gripper that supports several optional gripper capabilities and configures the output voltage setting of the Tool I/O Interface. ‘Custom Setup’: Demonstrates how to define a custom UI for setting up the gripper in the installation node as well as how to add a TCP for the gripper to PolyScope. ‘Custom User Inputs’: Demonstrates most of the options available when defining a custom UI. This includes how to: Use different types of user inputs and non-user input UI elements Use the filler UI element for controlling/grouping the layout of the custom UI Add a custom input validator for detecting errors for enterable user inputs (in this case an IP address user input) The new samples are located under the new ‘samples/driver/gripper’ and ‘samples/driver/general’ folders. Added document “URCap Gripper Driver” which describes the properties of Gripper driver contributions and how they work inside of PolyScope (gripper_driver.pdf file). Changes to the ‘pom.xml’ file for URCap projects: Updated the “11: Creating new thin Projects using a Maven Archetype” and “12: Compatibility” sections in the URCap tutorial to reflect that it is no longer required to update the version range in the “<Import - Package>” section of the ‘pom.xml’ file for a URCap project. Adapted the ‘newURCap.sh’ script (for creating new empty URCap projects) and all samples in the URCap SDK to this change. Controller / RTDE It is now possible to subscribe to all RTDE output variables from single client using one recipe. Number of allowed RTDE clients increased by three. Up to 6 external clients can connect simultaneously. Bugfixes Fixed issue where False value was assigned to RTDE input_bit_register_95 to input_bit_register_127 Fixed issue where killed XML-RPC calls with arguments in thread caused wrong arguments Fixed an issue where calling any of the getter methods in the ‘IOModel’ interface in the constructor of an Installation node contribution would result in a null pointer Java exception when loading an installation for the first time, or return a list containing the I/Os defined in the old installation when loading a new installation. Fixed an issue where the title in the header of an Installation screen the was displayed in bold for Swing-based Installation node contributions. Fixed an issue where calling the ‘setAnalogInputModeConfig(AnalogInputModeConfig)’ method in the ‘ToolIOInterfaceControllable’ interface with an ‘CommunicationInterfaceConfig’ instance, where the value of the baud rate parameter was ‘BaudRate.BAUD_57600’, would apply the ‘BaudRate.BAUD_38400’ value instead. Fixed an issue where the “Unhandled exception in URCap” dialog could be displayed twice, if a Java exception occurred in the code of a URCap while it was generating script code. Fixed an issue where the “There is an error with the URCap that contributes this node” screen displayed instead of the UI for an Installation node contribution (when an error occurs while entering the URCap installation screen) would only be displayed properly the first time. Fixed an issue where undoing a user action, which added a value (only applied to some object types) to the data model of a program node contribution, would put a ‘null’ value into the data model instead of completely removing the value. You can find the complete and general release notes here: Release Notes 5.5 Release Notes 3.11 Happy development, The Universal Robots+ Team