This week I got the opportunity to revisit MCity and see the Robocar, an autonomous vehicle capable of driving at up to 200 kph. It was very interesting to talk to the team working on it, shedding insight into how the Robocar was put together, what design challenges they faced, and of course, what sensors they use to gather information about the Robocar and its surroundings. For example, the car uses multiple LIDAR sensors strategically placed so that it can detect objects all around it. It also uses other sensors like RADAR and a 360°camera. I was also very interested in the engineering problems they faced. For example, I was surprised to learn that the car, with everything on it, weighed a metric ton, but without the motors and battery, weighed only 400 kg. It was also interesting that they opted to use 4 individual motors - 1 for each wheel. As it stands, the more they are able to show that the car has good decision making and can drive autonomously at speeds at or exceeding 200 kp…

Quadrature Amplitude Modulation

In an effort to better understand other methods of signal modulation, I decided to read up on Quadrature Amplitude Modulation. QAM is a method of transmitting a signal in a more efficient way. While Amplitude Modulation varies the amplitude of a signal to encode data, Frequency Modulation changes the frequency of the signal, and Phase Modulation modifies the phase, Quadrature Amplitude Modulation uses a mix of two of the three. It uses two carrier waves, a sine and cosine (in other words, one wave phase shifted by 90 degrees), and modulates using both amplitude and phase variations. A scheme like this is more efficient than simply Amplitude Modulating a signal. By having two phase shifted carrier waves, there is another channel to transmit information. It can also allow multiple bits to be encoded per symbol, which allows for schemes like 16QAM. It's not without drawbacks, though - things can get pretty confused if there is too much noise. Still, a scheme like this is pretty cool …


This week we applied for student grants to attend USENIX's Security Conference in Vancouver. Although the results of our applications remain to be seen, I myself am very interested in the papers at the conference. At least two papers seem to involve sensor security, which relates to part of our lab's research -- I myself has used RF EMI to attack a webcam, as detailed in the Ghost Talk paper, so now I have experience with at least one sensor attack. In addition to the Embedded Security papers, I have not been to any Security Conferences before, so I look forward to seeing the other types of attacks, like Side Channel attacks or the papers associated with Applied Cryptography. Let's hope we get something good out of our grant applications!
Seen above: a real life reenactment of the application writing


This week, I took a bit of a break from research to attend a competition in Daytona Beach, Florida for autonomous boats, RoboBoat. The best part about the trip for me wasn't hanging out with team, travelling to a new location, or eating good food. While those aspects of the trip were pretty great, the best part was how much I, along with the team, learned. Although things were a bit rough for the week following a mishap on the first day of testing, through the debugging process I learned a lot about the boat - both technical knowledge, and things regarding team organization. As a team we also managed to show off our technical knowledge in our presentation of our boat during static judging, which awarded us second place of all the teams competing. All in all, it's been a good time so far, and I'm excited for the upcoming school year for when we start all over again and eventually compete next summer. Hopefully, things go well tomorrow, the last day of competition!
Shown abo…

Paper Writing

This week marks the end of the Startup Projects. To finish them up, we've written papers about the experiments we've done. What was cool about writing the paper is that that marked the first time I used Latex. Despite my lack of knowledge, however, I just dove right in and started writing. While it did require quite a bit of referencing documentation, ultimately I found it an easier method of formatting the paper in order to present it in a clear, consistent, and official manner. It even allowed me to easily import MATLAB plots into the paper.
In addition to a new tool with which to write with the minimal amount of mouse input possible, the paper writing itself was a wonderful way to go back and reflect on my methods of research. For example, data collection. Recreating the attack was a fairly simple to repeat, but in retrospect I could have collected data in a smarter way, by using a wider range for the variable I did vary, and by taking multiple readings for each value of th…


This week, with the rest of the lab, I got to visit MCity ( MCity is a newly built testing ground on campus, with the main goal of facilitating the development of autonomous vehicles. As someone involved with a student team that makes an autonomous boat, I found it all to be very interesting. In the tour I got to see the test roads, with mock signs, road paintings, buildings, and more. Just seeing what they've included gives valuable insight into what kinds of challenges autonomous cars need to overcome, and what kinds of things they can detect using sensors like LIDAR, GPS, and even cameras. I sat in one car with a screen that showed the camera detecting people walking in front of it in real time. One benefit of autonomous cars is their potential to be safer than humans behind the wheel, which is something to be excited about. Let's just hope the sensors won't be taken advantage of.


Last week, I read the Ghost Talk paper, and learned a lot conceptually about RF waves and modulation. This week, what I learned was mainly technical. In fact, lots of it was fiddling around with GNU Radio Companion and the USRP and troubleshooting the problems that arose. Like figuring out why the USRP wasn't detected as a device despite being connected. Or learning that there are certain limitations for the USRP and adapting the GRC flowcharts to match those constraints. Or, perhaps the most...enlightening experience: figuring out that the transmitter board connected to the USRP did not support the frequency of the antenna.

(The frequency of the board supports up to 30MHz, while the antenna and the frequency attempted to be transmitted is over 400MHz)

Still, every problem that arises is only a learning experience. Through debugging, I learned more about how the equipment works and interacts with the computer. And mistakes like the one of the wrong board is a memorable oversight tha…