For my embedded systems capstone project, I worked in a four person group to create a quadrotor, modifying it to be able to fly around and get radioactivity levels. The idea came in light of the disaster in Japan early 2011, where earthquakes resulted in serious damage to several nuclear reactors. The nuclear reactors leaked radioactive waste and the area was evacuated. We worked with the Parrot AR.Drone last quarter for our embedded systems class, and going off that idea, we thought it would be great we could have a flying vehicle that could make a radiation map of the area that it scanned. Because of the sensors we need to use, we decided to get a new, more powerful quadrotor that could lift a bigger payload. The AR.Drone would have been great since we already had experience with it and know it quite well, but it could not carry the payload we need.
As a result of the AR.Drone not fitting our requirements, we basically created a new quadrotor. We selected the Gaui 330x, which is a powerful quadrotor than can lift 1100 grams. It is just a bare quadrocopter without controllers and sensors, so we needed to select the parts ourselves. We selected the ArduPilot as the controller instead of the stock IMU (inertial measurement unit) that the Gaui 330x came with. The ArduPilot is very stable because it uses both gyro and accelerometer. The standard Gaui IMU, as well as afterstock IMUs for that matter, do not have nor use both gyro and accelerometer and consequently are not as stable. Furthermore, the ArduPilot has open-source code that is customizable excellent support from the open-source community. During development, we provided status updates on www.jrzp.wordpress.com
Our original intent was to have the quadrotor navigate within confined spaces at disaster sites, such as buildings near a radioactive area. We intended to implement radiation measurment with obstacle avoidance and streaming real-time vision. This quadrotor would be controlled using a remote control to assess the area. The obstacle avoidance had been started, and one of our team members had created a prototype of the sensor circuit. Unfortunately, we went through a change of direction a few weeks into the quarter. Feasibility within our constrained time frame was a big issue, and this is what forced our change of direction. We ended up deciding to increase the scale of assessment to a large area from the previous small scale, i.e., the entire area of radioactive contamination versus inside a building in that radioactive area.
The goal then, was to build a quadrotor that can be controlled long range while collecting radiation measurements and sending them real-time to a computer. The computer would process that data into KML format, which would be plottable in Google Earth, resulting in a visually appealing map showing radiation levels of the surveyed area.
There are essentially four parts to this project: quadrotor control, radiation measurement, onboard radiation measurement processing, and data processing on the computer. Conveniently, our group divided it one part per person. Although we worked on separate parts of the project, I took time to be involved with each part and consequently have a solid understanding of every part. The system block diagram below is a good overview of implementation.
The DX6i is a remote control used to maneuver the quadrotor left, right, forward, back, up, right, and rotate right and left, and it communicates to the quadrotor’s controller through a small tranceiver using 2.4GHz radio signals. The dotted lines indicate wireless communication. The quadrotor’s controller is the ArduPilot Mega. This communicates to the computer using a pair of XBee modules. XBee allows for wireless serial communication. The laptop had an application we wrote called “KML Writer” that would parse the data coming in from the ArduPilot Mega. The ArduPilot Mega had a GPS module connected to it as well as a Cortex-M0. Obviously, the GPS module gives the current GPS coordinates, and the Cortex-M0 is a microcontroller dedicated to getting the radiation measurement from the Geiger counter, which is the tool that senses radiation.
An really cool part of the class was the access to resources. In addition to a dedicated laboratory filled with electronics parts, we had access to 3D printing and expensive PCB design software (Altium). We took advantage of the 3D printer by designing enclosures in SolidWorks, a CAD program. I had experience with parts design from the co-op I did sophomore year, so designing parts was a breeze. It’s the measuring and tolerance estimation that really sucks. Consequently, I became the parts design guy. We ended up creating an enclosure for the ArduPilot and a lower enclosure that housed our battery, Cortex-M0, and Geiger counter. Unfortunately, the awesome designs were omitted in the actual print because chiseling out the support material would have been too tedious. The lower enclosure is on the left, and the ArduPilot enclosure is on the right.
The portion of the project involves making the quadrotor fly. Sounds simple! The ArduPilot Mega is a platform that consists of the actual hardware along with code that is supposed to work out of the box. Note that this platform is open source, and we should not have been surprised that things didn’t work as it promised. In fact, we had to do some coding in order to make it work. We first tested the signals coming from the remote control. We discovered these are PPM (pulse position modulated) signals, basically inverted PWM signals. We made the ArduPilot read the inverted signals, so a low signal actually was read as a high in the ArduPilot. I won’t get into the details about the code, but I will talk about it from a higher level. Although the controls appeared to be there, signals were mixed and not in the right spots. Once we placed the signals in the correct spot, we got it to spin its motors correctly. But, just after an inch off the ground, the quadrotor would become unstable and immediately flip over. So, we embarked on the daunting task of figuring out the controls. Luckily, two weeks later while we were looking up information, we discovered the software had a new major release. We uploaded it, and after calibrating controls, the quadrotor was much more stable and could actually fly. In short, we fiddled around with the controls and controller code a lot, just to have a release that solved all our problems.
First, a bit of theory about radiation. A radioactive specimen releases alpha, beta particles and gamma rays. These particles shoot off from the specimen. Alpha particles are the heavy helium particles and will do severe damage to cells, but the range of emission is only inches from the specimen. Beta particles are much lighter and emit much farther. These are high energy electrons, and they will penetrate much more due to their size. Finally, gamma rays are radiation that penetrates the most but does much less damage than the alpha and beta particles. A Geiger Müller tube (GM tube) is something that detects beta particles and gamma rays. The GM tubes must operate at a high voltage. This voltage depends on how the tube was designed, but most are in the 700V range. A high voltage maintains an electrostatic field that makes it so that electrons are easily knocked off. When a beta or gamma enters the tube, it will knock off an electron, which corresponds to a small bit of current, and after all, current is just the movement of electrons. Connecting a large resistor to it, there will be a small pulse of voltage across the resistor by Ohm’s law.
The Geiger counter consists of a the JAN-7616 GM tube, a voltage conditioning section to maintain high voltage across the GM tube, and finally a signal conditioning section that converts the pulse into a lower voltage pulse to feed into a microcontroller. Below is the schematic of the Geiger counter.
The GM tube has a recommended voltage of 760VDC, so we needed something that could output that much. To do that, we decided to use a transformer to step up our battery voltage and then quadruple it. Passing the voltage through capacitors would result in an almost flat voltage. D1-D4 along with the 0.01uF capacitors are just two voltage doublers. The transformer operates by current changing, so the 2N2222 BJT along with the NTE2382 MOSFET were used to switch the current on and off. U1 on the left is a 555 timer. The resistor values were obtained using the 555 timer’s datasheet. We designed it to be as close to 50% duty cycle as possible (can’t get exactly 50%), and ended up with 55%. The MOSFET is a great switch, but it is voltage controlled. So, to operate the MOSFET, we use a BJT. The BJT is a current controlled voltage source. Drawing a bit of current from the 555 timer when it produces a pulse, it provides a voltage, which switches the MOSFET. Thus, the 555 timer creates pulses, and the MOSFET will switch on and off, drawing current through the coils of the transformer. The changing current creates a voltage that is 1350/10 = 135 times larger on the other side of the coils. This voltage is then quadrupled through two voltage doublers. Finally, we have the signal conditioning section. The bit of current through the 4.7 megaohm resistor shows up on the side with the 470K resistor. This of course creates a voltage by Ohm’s law. The 100nF capacitor is placed there for some filtering to clean up the pulse a little. Zener diodes are there to control voltage. The Zener diodes are oriented so that current goes into the diodes reverse to take advantage of the Zener breakdown phenomenon. Basically, the voltage across those diodes are maintained at the voltages they were rated at. These voltages are fed into an LM311 comparator, which has two inputs: 8VDC obtained from Z2 (positive input) and signal from the GM tube (negative input). When radiation is not sensed, the positive input is higher than the negative input, and the output is high. When radiation is sensed, the negative input is higher than the positive input, and the output is pulled low. The “high” voltage is set at 0V, while the “low” voltage is at -3.3V. This is due to the Zener diode Z3.
Radiation measurement is done in counts per minute. So even though we obtained the count with the Geiger counter circuit, we need to take counts over time to get a measurement. We could have used the ArduPilot Mega to get the measurements, but because it was doing so much already, we decided that we should have a dedicated microcontroller to get accurate measurement. The Cortex-M0 on an LPCXpresso development board is what we chose to use. There are basically three things set up on the microcontroller: a counter and two interrupt service routines (ISR) on the microcontroller. The timer ISR is in charge of timing and counting and calculates the radiation level measurement, and the data transmission ISR is in charge of converting the measurement into serial data and sending it out.
A 16-bit timer was set up as a counter. Every time it detects a falling level pin change on pin 5, which was connected to the Geiger counter, it increments. It was set up to detect falling-edge pin change because that was how the Geiger counter behaved. The counter also looks for a signal that make it reset itself to restart the count. Ok, counter is simple enough to understand.
Timing is managed by a 16-bit timer configured to generate an interrupt every 100ms. Every 100ms, the timer ISR takes the value in the counter and stores it into a buffer containing 60 elements, iterates through the buffer to get the counts stored in the 60 elements (which is the counts per 6 seconds), multiplies that by 10 to get the counts per minute, and the generates a signal to the counter. The counter then resets itself. This method will give a moving window of measurements. When the last element of the buffer is reached, a pointer is reset to the first element to store data. This way, there is a history of data, since the buffer doesn’t get cleared out when the end is reached.
Data Transmission ISR
This ISR looks for a pin change from the ArduPilot. When it detects this, the counts per minute is converted into a 16-bit binary number, and a series of 16 clock pulses are generated. These clock pulses are used to transmit the 16 bit number, which is data transmission in serial fashion. On the ArduPilot side, after the signal is sent to the microcontroller requesting data, it reads the incoming data and converts it back into an integer. Now that ArduPilot has the counts per minute in integer format, it can send that number along with GPS coordinates to the computer for further processing.
Below is a picture of the microcontroller mounted on one of the shelves of the enclosure, connected, and ready to be put in.
This final step is the dirty work, completely software, and I ended up this dirty work because none of my team mates were comfortable creating a software application. Neither was I, but I had to take one for the team. The goal was to parse the data sent from the quadrotor into KML format so that Google Earth can interpret the data and draw a pretty map. To do this, a Java application was created with the operator in mind. Usability was taken greatly into consideration because the end user should be able to easily use it to map out radiation levels. So, a GUI was made, shown below, which also displays the data stream from the quadrotor in the text pane.
First, a bit about KML. KML (Keyhole Markup Language) is a format that Google Earth reads. It is very much like HTML; they both use opening and closing tags. The required tags in KML are <Document>, <Folder>, and <Placemark>, which are arranged in the following hierarchy:
</Placemark> (can insert more placemarks)
To use the application, the user should select the port from the dropdown box and press the “Connect” button, initiating the data stream visible in the text pane. The user can then decide to start recording data by clicking the “Start Recording” button. Data will start being parsed into KML format. If the “Stop Recording” button is pressed, the data will stop being parsed into KML and not be included in the final KML file. Once the “Disconnect” button is hit, the KML file is finalized and saved and can be opened in Google Earth.
To begin, the dropdown box must be populated with the ports available on the computer. A port list was first created, and the list is stepped through, saving only serial ports into a hash map. The port names were stored as keys, and the ports were stored as the values. Storing these ports allows the program to access and refer to them later. When the “Connect” button is clicked, the port selected in the dropdown box will be opened, and an input stream will be opened from that port. A new thread is then started to read from that port.
The new thread reads one line of the input stream and sets that as a variable in the GUI thread. A method from the GUI thread was called to print that line. After reading and having the GUI thread print the data, that data is used to create a polygon. A polygon is a feature used in Google Earth. Basically, a shape can be extruded from the map and be colored. So, using the data from the quadrotor, a small block can be constructed with its color indicating radiation level. The data received from the quadrotor consists of four numbers separated by commas. The first three were longitude, latitude, and elevation, respectively, and these were used to make a polygon. A polygon is a type of placemark that fits under folder and document tags. The document and folder tags were created in the GUI thread upon initialization. So, in the read thread, polygon placemarks are added for each line of data.
To create a polygon, the aforementioned data that has been split into numbers that are GPS coordinates are used to locate the polygon. The color of the polygon was checked by if statements. When the radiation level was above 80 CPM, this was considered dangerous, and the color is chosen as red. A level between 40 and 80 CPM is considered moderate, shown as orange, and a level from 0 to 40 is considered safe, shown as green. A polygon is defined by a boundary, which is defined by a linear ring. The linear ring contains the GPS coordinates. In order to create these tags, the Java API for KML (JAK) was used. Polygon objects were created, and they were continuously added to the main KML document object. If the radiation level was dangerous, a new floating placemark was created displaying the radiation level.
The polygon creation is an if statement within the read thread. If the flag the if statement checks is true, a polygon will be created and put into the KML file. This is what the “Start Recording” and “Stop Recording” buttons use. They change the flag that the if statement checks. If the flag is true, the method that creates polygons will be run, and polygons will be added to the KML document. Otherwise, the method will not run, and polygons will not be created.
Finally, the “Disconnect” button closes the input stream and the port, and it finalizes the KML file that can be opened in Google Earth.
A very important part of projects like these is teamwork. Even one bad team mate could be detrimental to the project, but I was fortunate to have a good team. Although the work was mostly split up with each person being in charge of one part of the project, we came together and discussed on the big decisions. Everyone worked hard on the project, but there was one difficulty. We had a team mate that did not like working in the lab, and we ended up not seeing him much. Although this was not ideal, he did his work, and we gave him calls to keep him in the loop with us.
In the end, our project was successful, even with mishaps near the end. During testing the day before the final demonstration, the quadrotor randomly flipped upside down and crashed severely. It was flying perfectly fine before that. After repairing one of the cracked arms and securing it with an aluminum rod and hot glue, we discovered that the XBee modules did not communicate anymore. Research on the internet showed that XBee modules could be bricked by corrupt signals. What constitutes a “corrupt” signal is beyond us. After spending hours on this repair, a classmate from another team lent us his personal XBee modules and saved us.
We could control the quadrocopter with the remote control, and it carrying a rather heavy payload, it still flew pretty fast. It also detected radiation. To test the Geiger counter, we borrowed a specimen of uranium glass from a friend. This specimen was not very strong and had to be very close to the counter in order to be detected. In order to get a good radiation map while flying, hotter specimens would have been necessary because the quadrotor could only be controlled to come so close to the ground where the specimen would be placed. Consequently, to test that our project works, we demonstrated stable flight and radiation mapping separately. To demonstrate radiation mapping, we picked up the quadrotor and walked it around a field, putting the uranium glass close to the Geiger counter periodically. On the map, it should show the path that was walked and where the uranium glass was put close to the Geiger counter. Below is a map of a test run we did.
I don’t think I mentioned the difficulty of this project. It all seemed simple, but in execution, especially with the limited time we had, it was far from simple. We had many difficulties, all-nighters, as well as moments of sheer joy, and I am very happy with the outcome. After this project, I have demonstrated that I can work well in a team, endure long hours, solve problems on my own that I have never encountered before, just to name a few of the bigger things I learned. I could go on about the specific skill I learned or improved on.
How did we compare the other teams? Of course, other teams had projects that were very different. But, ours was one of the few that worked. One team aspired to do too much and did not have enough time to complete the project, another team had severe team work issues that resulted in half the members dropping the class, and some teams had bad luck with parts failing at the last minute, resulting in them not having a working project that could be demonstrated. The projects that worked, though, were very cool. The best part of the quarter was near the end when everyone’s projects were coming together, and things were starting to work. All of our hard work started to show, and sharing this sense of accomplishment with the whole class was very rewarding.