A list of the major problems we faced in developing the sensor package.

To be expected with any engineering project, we encountered a number of problems in designing our solution. The purpose of this page is to explain some of the major hurdles we overcame, and the solutions we chose to do so. For more information about any of these topics, please see the final report which can be downloaded from the downloads page.

Operating system latency

One issue we had to deal with was getting real-time system performance out of the microcontroller. For time-critical problems like sensing obstacles, it is important to get as close to real-time results as possible. Although modern computers seem to perform simple tasks and multitasking nearly instantly to the user, each core in a computer’s CPU can only execute one task at a time. To achieve the illusion of multitasking, the operating system performs what is called process scheduling. The base layer of the OS, the kernel, performs this task to switch back and forth between processes very quickly. This switching looks instantaneous to the user, but in reality, not every process is executed as fast as it possibly can be. Often, the tasks performed by the operating system’s kernel also take precedence over user operations. The delay that exists due to these issues is called latency.

Because both the BeagleBone Black and Raspberry Pi have single-core processors and run Linux operating systems, this idea of latency exists as the process scheduler decides what processes get priority to run. In our case, the use of the Raspberry Pi or BeagleBone Black meant we would need to use of a real-time kernel to decrease latency and give more processing time and priority to our sensor code. The process for compiling and installing a real-time kernel is included on the software page.

Noisy results

Figure 1: Noise Situation

View full size

Using ultrasonic sensors can pose some problems due to the properties of sound waves. Sound waves do not immediately die out, but rather they lose energy over time. Hard objects reflect most of this energy and soft objects can absorb this energy. This means that once an ultrasonic burst is produced, it will continue to be in the environment for some amount of time. This is problematic. At any point, an ultrasonic echo can hit a sensor and cause the sensor to believe that the burst it is currently timing has just come back. On the occurrence that the sensor that it hit was not the sensor that sent the signal, it will lead to a reading that is too short. The sensor expects a return echo coming from a rough angle of 30 degrees off the center line. Echoes can come in from any angle, so we needed to provide some sort of shielding to limit the angle of reception for the echo. Providing shielding prevents echoes from strange angles from affecting the sensor. The second need for shielding is when multiple sensors are active. Pretend you have two ultrasonic angled away from each other at 90 degrees. Let’s say ultrasonic sensor 1 is pointing at an object that is four meters away and ultrasonic sensor 2 is pointed at an object one meter away. Both sensor send out an ultrasonic wave at the same time. When the sensors are triggered, the burst from sensor 2 will hit its object, bounce back, and be received by sensor 2 and sensor 1 before the burst from sensor 1 even hits its object. The reported distance from both sensors will be roughly 1 meter. We were able to mitigate this problem by adding sensor shielding. You can download the SolidWorks models for this shielding on the downloads page.

Despite the use of sensor shielding, ambient noise can still affect the sensor operation. Due to the noisy nature of our data, especially while we were using the wiringPi library, we decided that it would be important to apply a software filter on the raw distance calculations we determined from the sensors. During some of our tests, we received timeouts from the sensors with objects as close as 20 cm away. This kind of noise could be fatal in an operating environment. If the drone is only 20cm away from a wall and a false 400cm reading comes in, the drone could crash into the wall.

Realizing the importance of the need for the software filter led us to look at several different methods to reduce noise:

For more information concerning these filters including their advantages, disadvantages, and our implementation, please see the report that can be downloaded from the downloads page.

Wire connections

In addition to the wires coming off of the PCB, we used a vast number of jumper wires to connect the PCB to the sensors, and the sensors to the Raspberry Pi. The number of wires we used caused some problems when designing a platform that could hold the sensor package securely. Also, due to the rather insecure method of connecting jumper wires, the wires often came loose when we were testing the sensor package. One loose wire could cause the software to return timeout readings for all of the sensors. We did not address this problem this semester, but it is strongly encouraged that you investigate other ways to keep the wiring both compact and connected in the sensor package.