Development of hardware products – what and how it works

Hi, my name is Dmitry Karzhitsky, I work as a QA Lead in the Belarusian hardware startup Rozum Robotics. Recently, together with Innopolis University, we held a meetup dedicated to the development of hardware products. In the footsteps of the meetup, I want to tell you about the specifics of developing and testing robots and about the specifics of organizing work in a hardware startup.

It seems that the realm of hardware is less visible than software, at least in terms of the number of references. Everyone knows about web and mobile app developers who write code on MacBooks while drinking smoothies. And hardware specialists have the image of a classic bearded engineer who can solder a board and write a code. If a good Java programmer must cope with the task of developing top-level software, then in embedded one cannot do without understanding hardware.

The development of new products, including in hardware, can be divided into two broad areas: commercial products (startups) and research and development (R&D). Development and testing processes and approaches can be similar, tasks and scope differ. The product is developed for specific users based on the idea and research that potential customers need your development. There are more risks in this approach. One of the risks is the difficulty of scaling the product. It is inexpensive to release a new version of the application, and it is still quite difficult and expensive to create a copy of the robot. I will discuss other risks below.

Examples from the development process will be based on the PULSE collaborative robotic arm (cobot). This is such a movable iron hand that can be programmed for different tasks.

Software production process

My main tasks right now are working on updates for cobots. The team devotes a lot of time to software: updating software for users, developing and maintaining an API that allows programming complex algorithms for the behavior of a cobot.

The process of developing a new feature looks like this:

  1. Users ‘or businesses’ wishes are added to the backlog.
  2. Next, we analyze, decompose into tasks.
  3. Then we formalize the task in User Story.
  4. For each task, we collect the requirements and break them down into features.
  5. The feature enters the development stage.
  6. Developers take a task and write code.
  7. When the code is ready, upload it to the robot and test it.
  8. We are releasing new functionality. Users download and install the update to their robots.

It turns out that a mini-team is assembled for a specific task. Somewhere you need a business analyst or an embedded software developer – the teams are always different.

If you look at the stages of developing software for a robot, then this is a classic pipeline: planning, coding, testing, publishing software for download, and operation.

When a feature is ready and it requires the development of hardware – a new motor, for example, the production stage begins, and the Technical Control Department (QCD) is connected. Quality control department goes through everything that comes to the warehouse to assemble the robot, including materials and equipment. After that, the robot is assembled and goes back to the quality control department, where the build quality is checked. After all the checks, a new version of the software is uploaded to the robot.

With the software update, everything is clear, we upload the new version of the software to the web service. When the robot is online, it downloads the update and, after user confirmation, deploys the release – much like a new firmware for a phone.

Updating hardware is more difficult. The robot is modular, you can replace any motor or the whole arm, leaving the control box, or replace the control box, leaving the arm. The operation is not particularly difficult, but it can only be performed by specialists familiar with the cobot device.

Difficulties of toffee

One of the risks in hardware development is the lengthy production process. It is unclear whether the product will be in demand in the market at the time of launch. The development of a new version of software is one time frame, a new version of a motor or robot is completely different. Getting feedback quickly will not work, you have to spend a lot of time and money.

To somehow minimize risks, we actively use prototyping to test hypotheses. After testing the prototype, we make a decision – to launch small-scale production or release one copy in order to test the viability of the product with minimal investment, and identify weaknesses during operation.

Since we are a startup, there is a bus factor when many processes are tied to one person and there is no duplication of roles. Recruiting new people for one position is not the most rational option, so we try to create a friendly team that you don’t want to leave just like that.

Development and specialists

In hardware, there is a global division into software of the upper and lower levels. The code for the top is written in Java and Python. For the lower one (embedded) – in C, C ++, engineers have to actively work with mathematics. In embedded development, it is important to understand hardware, be able to use a multimeter, an oscilloscope and measure physical parameters. There are few such specialists on the market. Usually these are people with specialized education in robotics.

A Java task means that a good programmer can handle it even without knowing hardware. Moreover, if the hardware and software are separated as much as possible at the interface and microservices level, so that there is no dependence between the upper and lower levels. Then you can easily change the top-level software regardless of the hardware on which it runs, and you don’t need to take into account 10,000 versions of different environments if there is a specific list of versions.

Testing tasks can be handled by specialists without experience in working with hardware. On the other hand, it’s great when a testing specialist can check the iron part, make measurements, localize problems. It is difficult and expensive to find such specialists on the market. It’s easier to take a beginner and train for the tasks of the product.

Development, especially high-level development, is similar to software. The developer also writes code, runs it on a computer or emulator. A nice bonus is that the code runs on a robot and works in the physical world. It is not a program in a browser, but a device that moves and performs actions. Testing this can be a lot of fun.


Cobot feeds me with marshmallows

How we test cobots

At some level of abstraction, there is no fundamental difference in what to test. If you know the input parameters and the expected result, then how exactly the black box does its job is not so important.

Working in the physical world imposes its own checks, but many processes are built according to the classical software development scheme. We did not reinvent the wheel, we took the time-tested ISO 9283 standard as a basis. This approach allows us to evaluate the operation of a robotic arm not according to invented criteria, but within the framework of the standard, where characteristics are prescribed by parameters: accuracy and repeatability of arrival at a given point, accuracy and repeatability passing a given trajectory, speed, time characteristics, cornering.

Testing is applied at all stages of production. Much has been taken from testing microservices, separate unit testing, integration testing, there are autotests for software integration at the API level, acceptance tests cover the entire system, canary releases allow loyal users to check the work of software in production. After the release, we do not have the opportunity to follow the robots online, so we have a chat with each user to monitor the operation of the equipment, we constantly collect feedback.

Most of our testing is classic API and web interface testing with some quirks. It should be borne in mind that the device moves at a decent speed. If you make a mistake in the logic of security functions, this is a serious threat to the safety of users.

Safety tests take place in several stages. First of all, we check that the robot is safe for people and will not damage the equipment and itself, then we check the functional features. First, our specialists check, then users who are ready for unforeseen situations, after that new functions are shared.

We also conduct mandatory tests for work in the physical world: temperature conditions, load capacity, influence of third-party equipment, humidity, for example, depending on the country – all this affects the structure of the material that is used for production.

What is happening now in the field of hardware-automation

The covid situation has catalyzed the processes of automatization in areas that have not traditionally considered this possibility. Even before the pandemic, there was an interest in robotic processes in entertainment and services – from large retail, to bars, shops and restaurants. The owners of progressive establishments understand that many routine operations can be entrusted to a robot, pouring drinks, for example. There is a potential economic benefit to this, but it is more of a fun for visitors now. Robot bartenders can be found on cruise ships or in a bar in downtown Milan.

When the crisis began, the way people used to consume services began to change. Ordering coffee to go causes slight discomfort, so interest in non-industrial robotization is growing. We see this by the number of inquiries from potential clients and investor deals in the world. Now the topic of automation with the help of safe cobots on the hype, but this is logically explained by economic and social factors.

Industrial enterprises, on the other hand, have frozen funds that they planned to use to automate production. With supply chains disrupted and the market falling, many deals were slowed down, canceled or postponed.


We hope that we have helped to better understand modern hardware product development. We are planning another article on this topic from the point of view of the R&D tasks of the NTI Competence Center in the direction of “Technologies of Robotics and Mechatronics” on the basis of Innopolis University. Write in the comments about what aspects of hardware in research and development you want to learn.

All performances from the It is hard meetup

YouTube playlist

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *