The HAL Robotics Framework

Underpinning our services is the HAL Robotics Framework, an extensible and modular software which facilitates inter-device communication, adaptive programming of robot tasks, and motion planning for one or many robots working together.

 

The Framework covers an end-to-end workflow from cell modelling right through to robot execution and deployment.

Model

The first step in developing an application is to model the robot cell. This includes:

  • environment e.g., fencing, structure & pedestals
  • automation equipment e.g., robots & external axes
  • process equipment e.g., tools, sensors and material stores
  • control equipment e.g., robot controllers & PLCs

We have a collection of 1000 robots from various manufacturers ready for immediate use but our modelling tools allow the creation of any kinematic system. This allows us represent the latest dual-armed collaborative robots in the same way as custom filament-winding machines.

Alongside these virtual mechanical assemblies, we also have presets for virtual robot controllers, configurable to mimic their physical counterparts and connected to them via the network.

Program

With a digital twin of our cell in place, we are ready to program it.

Programming a cell in the HAL Robotics Framework requires assembling actions, which represent the fundamental things a robot can do, into procedures. They define, for example, how a tool should be moved or how the robot controller should communicate with other equipment like sensors.

 

Typically, these actions are not manually created but are rather generated based on some form of data like a CAD model or a user input, such as some text that needs to be engraved. This approach enables our programs to be modified extremely quickly when variations are required,and that we can give our clients a means to reprogram their own robots with relevant, human-readable inputs. It also allows us to have CAD-associative trajectories which automatically adapt to any changes in 3D models, and reduce the programming time for variant parts to nil.

Simulate

Once we have defined what the robot(s) should do, it’s critical that we validate that any execution will run successfully. We do this through two stages of simulation, solving and visualisation.

Solving a program allows us to verify the behaviour of a cell extremely fast. During this phase we compute the position, speed and acceleration of the joints of each mechanism over the course of the program and use this to check for standard issues like out of reach, singularities and collisions, as well as custom diagnoses like maximum weld length.

 

We can then visualise these results either as a full simulation in a 3D environment to ensure any motion is as expected, or graphically through graphs or logs for more involved analysis such as cycle time and utilisation.

This virtual commissioning can really help convey the result of a proposal prior to making any final decisions and incurring any capital expenditure.

Translate

Until this point in the workflow all of our programming has been entirely vendor-agnostic, meaning that our procedures are not constrained to a particular manufacturer’s language. This allows us easily change which robots we want to use at any stage up to and including simulation. However, to run our programs on a physical robot we need to convert them into the relevant machine code. For example, ABB robots require RAPID code whilst for KUKA robots we need to translate to KRL, or URScript for Universal Robots, to name but a few.

 

The HAL Robotics Framework handles this conversion automatically based on the type of controller selected during the modelling phase.

Connect

With ever more devices connected to networks and an increase in the need to automate reprogramming, we have tools to communicate directly to your machines. This can be leveraged to upload and run machine code directly from an operator’s workstation or monitor devices and create feedback loops.

Monitor

A communication connection to you robot can be used to monitor the current state of your machines and any connected sensors. This data can be stored and analysed offline later to determine the cause of any issues or it can be interpreted in real time to update the robot’s behaviour by adjusting speeds and goals. We have found that often this data can be used in between different parts or passes to tweak programs, and compensate for any potential issues in future cycles before they arise.

Deploy

We have designed the HAL Robotics Framework to be as flexible as possible. This covers not only what processes and machines it can handle, but also where it can be deployed. Our technology can run on hobbyist hardware like Raspberry Pis running Linux, to operator workstations on Windows, or even in containerised environments in the cloud. We run the exact same libraries on the edge or in a datacentre meaning inherent compatibility when communicating between the two and leaving plenty of options for deployment.

Workflows

The HAL Robotics Framework is adapted to a large choice of workflows, ranging from Offline Programming (OLP) to teleoperation, and is flexible enough to accomate mixed programming strategies with feedback loops.

Do you have a process with unique requirements?