Testing for a Robot’s Collision Detection System with Varying Impact Resistance

We’ll use real collision data to refine the detection algorithm, and even better, we’ll confirm that the system actually works.

Supporting Information

• Design a Control Board for a Romi Robot Chassis
• Gathering and Analyzing a Robot’s Accelerometer Data
• How to Protect Your Robot with Automatic Collision Detection

We started this project on a robot collision detection system by gathering acceleration data for simulated collision events and non-collision impact events (i.e., finger taps). We then used this data to formulate an algorithm that would recognize real collisions and ignore the various bumps and knocks that a robot might experience as part of normal operation. In this article, we will adjust that algorithm based on real collision data.

Vibration, Acceleration

First, though, I want to explain something that I mentioned in the previous article. It became apparent that the motors are a significant source of high-frequency, low-amplitude acceleration, which means that an algorithm that works well without the motors might work not so well with the motors active. The following plots illustrate my point. Here is a simulated acceleration profile that was generated with the motors stopped.

The noise is minimal—maybe a few millivolts peak to peak. The next waveform was recorded with the motors running:

Now the noise is more like 30 to 50 mV peak to peak. An acceleration event looks very different with all this extra noise:

As shown in the last video included in the previous article, my initial algorithm (somewhat to my surprise) remained functional despite this motor noise. It also turns out that (as you’ll see in a minute) real-life collision events result in higher-amplitude acceleration profiles, so the motor noise is easily ignored by the updated algorithm. Nonetheless, motor vibration is something you need to keep in mind if you’re developing sensitive acceleration-based robot functionality.

Different Collision, Different Acceleration

My real-life collision tests made one thing clear: it might be a bit difficult to develop one algorithm that is effective for most events that could be described as a collision. I gathered data by driving the robot into four types of surfaces:

• solid wood covered by a blanket;
• solid wood (without a blanket);
• cardboard forming part of a cardboard box without much weight to hold it in place;
• and cardboard forming part of a heavier box.

As the following plots demonstrate, the acceleration differences are significant enough to complicate the process of designing a universally effective algorithm. Each plot is preceded by a video of the collision that generated the data.

The sizes and timescales for all these plots are equivalent, so you can visually compare the widths of the different waveforms. The real question here is the following: Are all these profiles sufficiently distinct from those of non-collision events to allow for a universal algorithm? Maybe so, but I can’t say with any certainty because the only non-collision events that I have considered are taps. And of course, there are other types of collisions that might be more difficult to identify without making the algorithm oversensitive.

One thing to note from the above data is the generous amplitudes: three of the four profiles actually saturate at the ADC’s 2.4 V reference voltage, and the fourth (for the lighter cardboard box) reaches 1.917 V. These maximum amplitudes are significantly higher than those of the simulated collisions (around 1.685 V) and that of the tap event (about 1.81 V). So it’s possible that the temporal details of the collision profiles might not create too much difficulty because the algorithm could be developed primarily around the amplitude characteristics.

Fine-Tuning

For the purposes of this article, I decided to focus on the wood-covered-by-blanket collisions. Here are profiles from three collisions, including the one shown above.

You can see that they all pass 2 V fairly quickly and maintain a high slope up toward the saturation point (2.4 V). So compared to the simulated collisions, the maximum amplitude is much higher. They are also of much shorter duration than the simulated profiles; the width of the main pulse is generally around 12 ms, whereas the simulated pulses (just the positive section) were at least ~100 ms wide. This initially caused me a bit of concern because I was using the pulse width to differentiate simulated collisions from tap events, but it really isn’t a problem because of the amplitude advantage mentioned above.

I saw no reason to abandon the general structure of the original algorithm; all I did was adjust the constants based on the new data. Here are the updated values:

• First threshold: 12971 counts (1900 mV)
• Second threshold: 15019 counts (2200 mV)
• Maximum number of samples from first threshold crossing to second threshold crossing: 7
• Minimum width (i.e., minimum number of samples from rising-edge second threshold crossing to falling-edge first threshold crossing): 4

I also had to convert the firmware from the data-gathering version used previously to an operational version. Here is a description of the overall program flow:

• I manually set the ADC window-compare greater-than value to the first threshold, so that I don’t have to remember to change the configuration file every time I adjust the threshold.
• The firmware delays for three seconds to give the operator time to prepare.
• Collision detection is enabled (previously this statement was commented out).
• The motors are enabled and set to full-speed forward motion.
• At this point, you can call StartAccelerometerDataCollection() if you want to collect data, but currently, this statement is commented out because data gathering and collision detection cannot occur simultaneously. You uncomment either Enable_CollisionDetection() or StartAccelerometerDataCollection(), not both.
• A delay statement is used to disable the motors after three seconds; this prevents the robot from running amok if it misses the target, or if the collision detection system doesn’t work as expected. It’s easy to distinguish a detected collision from the three-second-delayed disabling of the motors because the motors brake (i.e., stop rapidly) in response to a collision.

You can use the following link to download the source and project files:

   Collision Detection Source and Project Files  

The algorithm works consistently. The following video is a montage of successful collision detections.

And this next video confirms that the algorithm is robust against tap events. These taps are pretty rough, which makes me think that the algorithm would successfully ignore many non-collision bumps and knocks.

Conclusion

We’ve successfully developed and tested an automatic collision detection system built around an accelerometer, a microcontroller, and some carefully designed firmware. The current algorithm is optimized for collisions involving a surface that has a small amount of cushion, as opposed to a very solid surface composed of wood or concrete. However, the algorithm is flexible and can be easily adjusted by modifying the constants.