Addressing the Challenges of Mobile Robot Software Automation Testing

We'll explore the complexities of automating mobile home robots and focus on the unique challenges during setup to overcome limitations to ensure users have a smooth start

In a previous article, I explained how to use April Tag technology to automate home robots. A huge challenge when it comes to automating home robots or other robots is the setup of the device. In the world of devices, phones, and mobile apps, devices are typically connected to the host device via USB, and the device is always connected to a power source. However, for testing robots, a unique challenge arises, namely how to conduct testing while the robot is moving. Because it cannot be connected to the host device through a physical wired connection. So, how should we verify the unboxing experience? Don’t worry, I will explain this in this article

Complexity and Challenges

After I gave you a brief introduction to the various challenges of setup phase in Robot Automation Testing, let me go deeper Researching More Challenges

The robot is moving and cannot have a physical wired connection to the host device. It may be possible for some component level testing, but not for end-to-end (E2E) testing

The out-of-box experience is when the device is not connected to WiFi. How does the host device interact with the device when it is brand new? This is a very common situation in daily robot testing

When any error or exception occurs in the robot, recovery operations are required. The main goal of automated testing is to discover potential software and hardware problems with the robot. If we encounter a problem, how should we report and recover the device?

The robot's battery is about to run out and we need a reliable power source to charge the robot

It is very important to extend the same setup to multiple lab and home environments. This is because we can't just sign or test the bot in one environment. Let's address these issues in chronological order. It can be rewritten as: Let's solve these problems in chronological order

Using the Raspberry Pi Default Robot

The important thing is to solve this problem. Consider the case of a robot located in a test automation laboratory. There is a host device connected to the company's internal network that is used to send and receive commands and access various source code, internal tools, and infrastructure. We will connect a Raspberry Pi to the device and run a REST service on the Raspberry Pi to communicate with the host device and the device. Below is an illustration showing this setup

Using Raspberry Pi Preset Robot

Solving the Out of the Box Experience Use Case

Now , let’s take a look at how to pre-set the test environment through the Raspberry Pi. Next, we will explore how to solve the problem of the device not being able to connect to Wifi when out of the box

What is the role of RESTful services on the Raspberry Pi? What endpoints should a RESTful service contain?

Flash device

• Complete OOBE
• Set up wifi, etc.
• Get DUT IP address
• Now, It became very easy for us to connect the device via wireless and the device was fully prepared for our testing

Recover the robot in case of any errors or exceptions

This is a Very common situation. Don't be overwhelmed or frustrated by these types of questions. At this point, we must use the device's low-level components to drive the device back to its original location. For example, as I mentioned in my previous article with various software stacks, we need access to the platform or mobility layer to drive the robot back to its original position. This is the trickiest and most challenging thing to do, so use other technology like April Tag or other external systems to drive the device back. This brings me to my next question, which is to put the device back on the charging dock in preparation for the next test run

Expand to multiple test environments

When placing the device back on the charging dock, use low Commands can improve reliability. Lower failure rate and higher efficiency than using top-level movement or navigation commands and platform or mobility layer drivers

Extended setup tips for multiple test environments:

Keep the setup simple. Don’t overcomplicate or over-engineer the solution.

• Have deployable Raspberry Pi images so that any new Raspberry Pi can be easily loaded.
• Place the test code in the remote repository. Moving them on-premises won't scale.
• Robotic automation is not a simple matter and ultimately requires a lot of design work and consideration of other options on the market. There is no one solution that fits all situations. Before adopting the final solution, I recommend conducting a proof of concept

Alternatives

Given the nature and complexity of the problems we face, a common question is whether there are alternatives. In short, the answer is yes. We can effectively test by using emulators/emulators to cover most of the use cases we describe, but there is no substitute for real device testing

The above is the detailed content of Addressing the Challenges of Mobile Robot Software Automation Testing. For more information, please follow other related articles on the PHP Chinese website!