Blog - Combine | Combine


Emelie has significant experience in talent acquisition and has worked as a Senior Recruiter for one of Sweden’s leading recruitment companies. Through her years within talent acquisition, she has recruited several different roles for different industries. She holds a bachelor’s degree in science of human resource management, and this week she stepped into her new role as People and Culture Manager at Combine. 

“Combine is an exciting company that operates in a growing industry, which I find very interesting. The role as People and Culture Manager attracted me as it is a broad role, where I get to be part of and grow in the company,” says Emelie. 

Emelie’s goal for her future at Combine is to reach new heights together with her colleagues. To develop new efficient routines and working methods and to be involved in creating growth in the organization. “I want to provide support and add value to the employees,” she says. 

The best thing about her job, according to Emelie, is that she gets to work with people and constantly learn new things. “I am always faced with new situations and no day looks the same. I love that I am able to help people to their dream job and at the same time contribute to Combine’s growth.”  

Becoming part of Combine means being a part of our vision. Our success is built on our customers’ success, and we make progress by combining our strengths. 

If you think Combine sounds like the place for you, feel free to reach out to Emelie and have a chat! You can find her on LinkedIn and via e-mail, or a phone call away. 

Read more

What technical debt is and why you should worry about owning technical debt?

So, what is technical debt? We incur technical debt all the time in fast-paced product development. As we are often faced with the dilemma between high speed and high quality, i.e., between a quick solution that can start working in a short time and easy maintenance in the long term, we cannot avoid technical debt. Even though debt is not all bad, it needs to be paid off at some point.

Why should you worry about owning technical debt? The massive availability of ML toolkits has created an illusion that building a complex ML system is easy and fast. However, these quick wins do not come for free. Machine learning systems are built on codes, and thus they are prone to technical debts of normal software programs, e.g., dead code or poor documentation. Moreover, features of ML incur common ML-specific issues. For example, CACE, i.e., “Changing Anything Changes Everything” applies to every tunable aspect of an ML system, including input signals, hyper-parameters, learning rate, etc. If measures are not taken to deal with this feature, subtle changes might lead to catastrophic product behavior change.

The more than common practices that lead to technical debt in ML systems

Glue code. There are so many powerful machine learning packages. One can always find some ready-made open-source packages to accomplish complex tasks in a short time. Unsurprisingly, the availability leads to glue code in practice, where original code is mostly only written to get data into and out of imported packages treated as black boxes. Since you cannot control the future of the packages that have been introduced into your system, unexpected changes on any of the packages will either shut down your product, or lock it in the versions that are getting obsolete.

Unstable data dependencies. Data are usually collected and modeled by different teams. The CACE feature of ML systems means that changes on input data, even if they are improvements on the collected signals such as calibrations, can fundamentally change the information learned from data. The data collection team is likely to only focus on their maintenance and upgrade work, without much knowledge about consequences on all the consuming ML products.

Complexity over simplicity. Engineers are tempted to prefer new technologies over the old ones, higher accuracies over simplicity, or cutting edge over stability. The Occam’s Razor principle says “the simplest solution is almost always the best”. If performance gain is not significant enough, it cannot compensate the increased complexity and vulnerability cost.

For a comprehensive list of ML technical debt, read the papers [1] [2].

What to do?

Wrap imported packages into your own common APIs, save a versioned copy of data together with its model, monitor and test the upstream input data, benchmarking with a simple model, test the impact of each tunable component, test the distribution and impact of different features, test that the distribution of the predicted labels is close to the observed labels, reducing human interventions in the whole pipeline, etc. Sounds like a lot?  Sympathy for data integrates all of these functionalities, together with data analysis & ML tools into one user-friendly API. A fully automated process will free you from technical debt. Excited?

Contact Simon Yngve at or +46 731 23 45 67.


Jin Guo

Read more

Population growth along with economic growth and changing consumption behaviors results in an inevitable increase in food and water demand. Yet, the world’s resources of clean water are shrinking due to climate change, depletion of groundwater, and pollution. Globally, the largest domains for water demand are agriculture, industry, and domestic usage. Agriculture composes for 70 percent of the world’s water demand where the majority of the water is used for irrigation purposes. Since water usage cannot exceed water availability, higher

effective usage of water in agriculture is needed. Still, the most crucial parameter for plant growth is suffcient soil moisture. Within agriculture, agriculturists must supply crops with enough water while preventing overwatering. The plant experience water stress when root zone water is limited and the wilting point is reached when no water is left to extract. Depending on the intensity and duration of water shortage, crop damages could be irreversible.

Thereby, supplying the crops with more water than necessary reduces the risk of plant stress. The field capacity is the maximum soil moisture content where water will not drain due to gravity. The volume of water between the field capacity and wilting point, is referenced as the Total Available Water, TAW, and can be used in the process of creating irrigation controllers. Irrigation controllers can operate with and without feedback from the field. Due to open-loop control’s low-cost properties, open-loop controls are more used worldwide, but the utilization of closed-loop controls is increasing. An example of a closed-loop controller, could be a controller fitted with a soil moisture sensor while trying to keep the soil moisture at constant level.

Challenges of constructing irrigation controllers, is due to the evapotranspiration. This is the sum of water losses due to soil moisture evaporating into air and plants exchanging gas with its atmosphere in a process called transpiration. Due to the complex nature of the soil water dynamics, finding the optimal soil moisture target compose a challenging model problem. AquaCrop is a crop model simulation tool which enables scientist and engineers to develop irrigation controllers before the real experiment. With this simulation tool, it is possible to develop irrigation strategies without conducting costly field experiments.

The aim was to investigate irrigation management strategies and reduce water demand within agriculture. The goal was to minimize seasonal irrigation while only obtaining a small deviation from the maximum possible final yield value. To obtain this, reinforcement learning implementation was conducted within the software AquaCrop. For this, two different irrigation strategies were investigated – net amount irrigation and irrigation with soil moisture target. The goal with this implementation was to find which irrigation would provide sufficiently large yield, but with as little water as possible. To complement the results from this, two grid searches were performed which were used for comparison.

The reinforcement learning implementation included an agent which took different actions in terms of irrigation strategies and was rewarded a bonus depending on the final yield and water usage. The reinforcement algorithms were able to find certain optimal policies if the percentage of max yield to be maintained is sufficiently low, at around 90% for most of the time. The conclusion of this thesis was that it is possible to deploy irrigation management strategies with reinforcement learning and AquaCrop, given a reward system with lower constraints. The Q-learning implementation was however not able to find the same optimal strategies as the grid search. By comparing the irrigation strategy with net amount irrigation and soil moisture target, it could be seen that in general, the irrigation with soil moisture target could generate a higher performance by finding strategies with less water. This is due to the net amount irrigation not considering the water uptake in each crop stage. Furthermore, it would be of interest to test additional optimization strategies in order to decrease irrigation water while maximizing yield.

Do you want to know more?

Learn about how we work with control systems at Combine, and how we may be of service to you.

Read more or contact us

Read more

Training corpus

The model was trained on 10’s of millions of public code repositories on GitHub. The primary goal of the model is that it be used for research purposes and produce original output, rather than simply regurgitating the code it has been trained on. In fact, OpenAI has found that “the vast majority (>99%) of output does not match the training data”. This means that the model was able to capture the structure, syntax, and semantics of programming languages in the same way it has previously done with human languages.


Figure 1: Transformer architecture

The GPT-3 model is built on the atomic unit of a Transformer, first proposed in 2017 in the research paper “Attention is all you need” by a team at Google. The key finding of this research was the idea of self-attention, which allows generative models to be trained on unstructured and unlabeled text – leading to an exponential increase in training data available to such models.

The main difference between the different iterations of GPT is the number of layers, training corpus size, vocabulary sizes and the number of parameters in the model – all increasing successively with every iteration. GPT-2 increased the number of parameters to 1.5 billion from 117 million. The latest model uses a mind-bending 175 billion parameters. As the models expand, so do their capabilities, as we see in Figure 2 of model accuracy in “next word prediction”, i.e., predicting the next word from a given context. What is important to note, however, is that model performance seems to be approaching a plateau, at least in the case of GPT-3, which may point to the idea that future model iterations will focus on other aspects than training data size to improve generalization ability.

Figure 2: GPT model accuracy comparison (next token prediction)


The Codex API currently supports a limited range of tasks that demonstrates some of the more developed modelling capabilities. These include familiar benchmarked tasks such as chat, Q&A, and text summarization. But this growing list also includes tasks that extend to more nuanced assignments, such as programming or code explanation. It currently offers full support for Python, and supports JavaScript, Go, Perl, PHP, Ruby, Swift, TypeScript, SQL, and Shell to a lesser extent.

If Codex can automate code generation from natural language, it also raises the question of whether it can replace an actual programmer. We decided to start with a simple problem and move to a more involved prompt and finally something more in-line with what a seasoned programmer would need to perform.


  1. Simple prompt – Sort a list of numbers

Figure 3: Sample screenshot from OpenAI Codex Beta


  1. More specific prompt along the same lines – Sort a list of numbers with o(n2) time complexity
  1. Application-specific prompt – Create a LSTM-based time series prediction model with a training window of 3 days and plot the errors of predictions

Overall, the results seem quite impressive. The first two prompts are handled with relative ease, and the model is even able to identify suitable algorithms based on complexity and use built-in Python functions when they are more appropriate. The final prompt also provides some interesting insights into the generation process. The general outline is clearly there, as well as the common pre-processing steps when working with time series data.

It is, however, clear to any Data Scientist / ML Engineer that the third output is not a generalized solution and would require significant reworking. There is no function to plots the errors, and it reads like a copy-paste implementation of a toy problem, including irrelevant comments and unused lines of code. To many, this is akin to a “Googled” solution in that it is not tailor-made to specifications but rather a vaguely relevant code snippet that needs to be largely altered.

Potential and limitations

The Codex model has gone a long way in illustrating what we can expect from future language models, which will be better able to understand us than ever before. With a simple instruction, Codex can find relevant information and structure it in a way that programmers understand, or even create unique content that helps to bridge the translation gap between programmers and non-programmers. This exciting development will continue to fuel interest and research in this area for years to come.

Although the Codex model can code with surprising coherence and speed, it is evidently limited by its exposure to code repositories and their inherit imperfections. The model is also prone to offering up the same solution to slightly varying prompts, and in some cases, presents a solution that is identical to a code excerpt from its training corpus. This means that the model does not always deliver an original and relevant solution to an unseen prompt, something that most trained programmers with exposure to only 1% of the Codex corpora would be able to do.


Codex demonstrates that by combining enormous unstructured corpora and sufficiently complex architectures, models can produce realistic and veritable programming output from simple natural language prompts. However, when digging a little deeper, it is not the panacea it first appears to be. It is still a work in progress, and though exciting, there is still much to be done. For this reason, automated programmers may still be a little way off, and instead the immediate relevance of Codex will be to augment the ability of current programmers, and hopefully clean up some of our dusty, syntactically littered repositories on GitHub.

Other interesting resources related to Codex:


Jurie Germishuys

Inspired? We can help you with your next step!

Whether you are beginning your AI journey or already have models in production, you can turn to Combine for expert help. Feel free to check out our blog posts on how we used Transformers to build a semantic search engine and other AI projects such as crowd-sourced data annotation and image classification using deep learning:

Want to learn more about how Combine can assist in AI development?

Contact Simon Yngve (

Read more

The pandemic caused by coronavirus disease (COVID -19) has led to a variety of challenges in terms of limiting the workforce. Humans cannot endlessly perform the tasks created by the pandemic, while cobots have been built to help in these circumstances. Some examples are disinfecting the environment, performing throat swabbing tests [1] as well as serological tests [2].

A UR10 manipulator is performing oral (throat) swabbing.
The figure is reprinted with permission from [1].

Among other things, cobots are employed within industrial sections such as factories, as a part of the fourth industrial revolution (Industry 4.0), to assist humans in a variety of ways, including reducing human effort in repetitive and heavy tasks. Automotive companies such as Volvo Group [3], Nissan motor company [4], Ford [5], MINI [6], Volkswagen [7], Audi [8], and BMW [9] are taking advantage of cobots in production lines for their ease of deployment and safety in close vicinity of human co-workers.

A UR10 manipulator in Nissan motor company.
The figure is reprinted with permission from [4].

The application of cobots requires advanced perception and control algorithms. The most common perception methods employed for cobots to perceive the surrounding environment are lidar, vision, and haptics, which are selected based on the type of the task and the proximity of the human operator to the robot manipulator. Apart from perception modalities, proper control of cobots requires the development of advance control algorithms. The control algorithms developed for cobots usually focus on human dynamics and behavior, impedance control, and safety-related aspects compared to traditional robotic systems.

A key difference between cobots and industrial robots is the convenience of creating new tasks. Cobots are designed to provide a simple interface for the operator to program the robot for new tasks. In this context, an interesting feature is learning by demonstration, where the operator can teach a trajectory to the robot by simply grabbing the robot and moving it along the desired path. This feature requires the use of advanced path planning methods such as Dynamic Motion Primitives (DMPs) and dynamical systems with Guassian Mixture Models (GMMs).

In conclusion, the development of cobots is one of the most important steps to integrate robots into daily life and make them an efficient collaborator, especially in situations such as pandemics. Cobots seem to be promising to increase productivity and efficiency especially in small and medium enterprises where rapid deployment, flexible automations and ease of use are crucial factors.

Interested to learn more about how we work with Control Systems at Combine?
Contact us


Ramin Jaberzadeh Ansari











Read more
Courtesy of Tesla, Inc.



Brains – Bold decisions in the modelling phase

A major redesign of their machine learning models includes a multi camera neural network making predictions directly in vector space. Previous models made predictions in image space for each camera, and the results were then transformed to vector space in post-processing.

This holistic approach allows the model to simultaneously make predictions on views from all cameras, similar to how the human brain uses vision from both eyes when making decisions.

Figur 1: It’s basically night and day, you can actually drive on this” says Andrej while also highlighting the huge engineering effort required to get this right.

Tesla also explains how a lack of memory has been a problem for their previous AI models, citing issues such as temporary occlusion. By redesigning their models to incorporate so called

hidden states capable of memorizing information from previous frames in the video the accuracy improved.

Figur 2: Using the context in video. Andrej Karpathy demonstrating how using the context in video reduces false detections due to occlusions.

Muscles - Huge investments in data collection, labeling infrastructure and digital twins

After working with third party labelers Tesla now favors hiring professional labelers who are co-located with machine learning engineers. This allows Tesla to further develop and improve annotation software, as showcased in their 3D annotation tool.

Figur 3: Tesla’s 3D annotation tool capable of simultaneously annotating multiple camera views by making use of data captured from different cars.

Data is collected from the huge participating fleet of cars in real world traffic. Data can be collected on demand based on queries specified by the engineers, allowing specific hard cases to be improved within weeks rather than months. Offline analytics allows Tesla to automatically label much of their data, while still allowing human intervention where necessary.

For traffic scenarios not easily captured from their fleet Tesla uses simulation software to create realistic scenarios. These simulations realistically model real sensor noise, motion blur and other optical distortions.

Figur 4 & 5: Realistic simulation allows Tesla to render scenarios with perfect labels – saving annotation efforts. In this simulated intersection the not yet released Tesla Cybertruck can be spotted.

Speed – Computing power on the edge and in the Dojo

Making use of these efforts require a huge amount of compute power, something Tesla with their Project Dojo has developed their own scalable, distributed, processing architecture for. The supercomputer Dojo will feature their in-house designed D1 chip. More info can be found here:

Inspired? We can help you with your next step!

Whether you are beginning your AI journey or already have models in production, you can turn to Combine for expert help. Feel free to check out our blog posts about how to use virtual modeling for AI:

Large scale annotation using crowd-sourced data annotation and image classification using deep learning:


Want to learn more about how Combine can assist in AI development? Contact Simon Yngve (

Read more

I have always been interested in technical gadgets, even before my commodore 64 I took things apart to see how they were built up. In the earlier years I rarely put the gadgets back together. The C64 survived though, just had to adjust the cassette deck every now and then. I guess that can give you a hint regarding how old I am.

My career has revolved around software, from user requirements to system verification. Always in or related to embedded devices. My time at Baxter taught me a thing or two about software for safety critical systems. In that case for medical devices but it seems similar to the standards for the automotive industry.

I took the job at Combine Control Systems because I think they have a unique setup with their competencies within control systems and data science. I also liked that I get to build my own team of embedded developers from scratch. The competencies in my team will hopefully complement Combine’s current strengths. This will prepare us to take on even more fun and challenging projects.

Transparency and empathy are important to me. Be direct but on the other person’s wavelength. Address problems but focus on the solution rather than lingering on the past.

I’m also striving for making the teams I’m involved in a little more fun and interesting.


Feel free to reach out to me regarding any prospects, whether you want to join my team, want us to take on a whole project or want to hire myself directly for a role.

Read more

What I like most about Combine is that they take care of their employees and listen to them to create a great workplace. They are also very clear about which competences they possess, so that both new employees and clients know what to expect. My job will focus on creating long lasting relationships with all parties. The employees shall know that their assignments will be chosen from an individual view, with their background and experiences. Clients shall know what Combine stands for and what we contribute, which is more of partnership than a customer/supplier relationship.

But then again, we are suffering from Covid-19, which is affecting all industries and companies, not least in the consulting sector. How I am supposed to develop a company under these circumstances? One should be humble when facing this pandemic, but my strategy will be to make the new become the normal. Combine as a company is used to digital meetings and projects performed from a distance, for example doing work for American and Asian companies. We have the potential to manage projects like these even on a local scale, which renders even better prerequisites for satisfied clients.

I will put Combine on the map, at least on a regional scale. I look forward to getting to know all the contacts I will make in my new position. Before the end of 2021 we shall double the amount of people tied to our office in Linköping and during the upcoming years we look forward to doubling the workforce again. I am excited that, together with Rikard Hagman, carry through our vision for Combine and I believe that there are people who feels just like me. Let us know so we can do this together instead of waiting for Combine to headhunt you.

The upcoming year will be one of my most thrilling years. I believe that many people will move between companies and we will work proactive to connect with the people we want to grow with. I want to represent good leadership and mediate a great feeling, a transparent way of working and supply possibilities to develop.

Read more

Large industrial plants consist of hundreds if not thousands of sensors, constantly collecting data from the numerous processes that make up the plant. These sensors then transmit this data not only to the control room, but also to controllers placed throughout the plant. In turn, these controllers use this information to calculate the appropriate control signals and send them to the numerous actuators of the plants. These actuators, consisting of pumps, heaters, valves, etc., then apply the control signals on the industrial processes. Hence, it can be said that there is a mass of communication happening during the running of an industrial plant, as signals are consistently sent from sensors to controllers and from controllers to actuators.

These communication requirements pose challenges when designing the plant. Traditionally the communication has been done using wires to connect the sensors, controllers, and actuators where appropriate. However, this is an expensive and space-intensive solution. Furthermore, wired communications are inflexible as if one wishes to move a single sensor to a different location, this may necessitate new wiring. Therefore, there are unquestionably considerable benefits to be gleaned from utilizing wireless communications for industrial plants.

However, wireless communications pose limitations on their own. The chief among them is the question of reliability. Wireless communications are generally considered less reliable than wired communication. This means that with wireless communication, the communication channels between the controller and actuator and between the sensor and controller may be subject to the possibility of packet losses and packet delays.

With wireless communication, there may be an unreliable channel between the sensors and the controllers and between the controllers and the actuators.

Control in the case of unreliable channels poses a problem in itself.  The unreliability of the channel forces us to consider how to adapt our control scheme to compensate for the fact that signals sent by the controller may arrive to the actuator delayed or may not arrive at all. Furthermore, the delays from unreliable communication channels tend to be stochastic, so conventional control strategies for handling constant delays cannot be used.

Is LQG control the solution?

LQG control is an attractive proposition as it is based on the expected outcome, and hence can be expanded to consider the stochastic nature of the communication channel. Furthermore, if one assumes that acknowledgments ensure that the controller knows which signals have reached the actuators, the separation principle can be proved to hold. This is a key principle of LQG control, which states that the control problem and the state estimation problem can be solved separately. What this means in effect is that we do not need to concern ourselves with the unreliability of the communication channel between the sensors and controllers when deriving our control input. Conversely, we do not need to concern ourselves with the unreliability of the channel between controller and actuator when deriving our state estimates.

For state estimation, only relatively minor modifications to the conventional Kalman filter is required to compensate for the possibility of packet delays and packet losses between the sensor and controller. However, when implementing LQG controllers, the required modifications are somewhat more extensive. In this case, the optimal control signal depends not only on the states (as in conventional LQG control) but also on past inputs sent by the controller but have not yet reached the actuator.

If we evaluate our optimal LQG control solution (modified to take delays and package losses into account) and compare it to the standard LQG solution on a model of an inverted pendulum, we get the result below. As can be seen from the figure below, compensating for the delays results in considerably less deviation from the reference while requiring far less control input. Thus, the importance of taking the unreliability of the channel into account can be shown.

Comparing the optimal LQG solution (adapted to take into account the unreliability of the channel) with the standard LQG control.

Read more


As the developers have published a version in PyPI, installing the Accelerator now is as simple as running pip! As we are mostly using Python3 and we are testing and developing most of our code locally before sending it to our processing server, we can simply install it like this:

pip3 install –user accelerator


Then, the accelerator tool becomes available with the `ax` command!

First steps

Once the accelerator is intalled, it’s time to configure it! The new version if fully documented in the manual, but as a starting point it should be enough to run `ax –help` and do the same for the small subset of commands provided. Then, to actually get started, we run `ax init` in the working directory where we wish to create our first project. Usually, we would configure the accelerator locally for every project, and therefore run all the comands from the corresponding directory. As that is not necessarily the case for every developer, one could also setup a global configuration file (e.g: /etc/accelerator.conf) and simply add `alias ax=ax –config /ect/accelerator.conf` to the .bashrc file (assuming bash as the default shell).

Running `ax init` will create a set workdirs and files in the directory where it is run. The most important there is `accelerator.conf`, which contains the basic configuration. There we can configure thinks like the amount of threads that we want to run or where we want to the results of our scripts to land. Luckily, the stardard one created by `ax init` contains sane defaults and comments that help understanding what the different options do.

Finally, to start the server process, it is enough to run `ax server` from the project directory. Now the server is listening and to send some work, run `ax run “PIPELINE”` from another terminal. Starting running the tests can be a good start: `ax run tests`.

Further improvements

The new changes to the accelerator do not only come from the installation side, but also from the User Interface part. Now, it is possible to get detailed information about the tasks that have been run, their options, datasets, or results from the browser. For that, it is as simple as running `ax board` in the corresponding working directory or setting the `board listen` parameter in accelerator.conf. The board will start a server process that is by default listening on localhost:8520, which is of course customizable. There, we can check the status of the accelerator server process and search the results that were returned by our jobs, the options that were passed or which dataset was used. In addition, it’s even also possible to see the source code of the script that was imported to run a specific tasks. All this together, allows for a much better user experience and greatly helps debugging, specially when getting started using the tool. 

Some additional extra improvements include adding a `grep-like` command to search for patterns in datasets and merging urd’s (the part that keeps track of tasks) functionality into a single tool, not requiring urd to be set up independently anymore or the ability to configure the python interpreter for every method.

Read more

    Contact us