Want to become an virtual millionaire overnight? Too lazy to keep up with online trading games like Market Watch? Dream of hacking the stock market with the perfect algo?

At least, that’s what Bronxville’s Programming Club dreamt of. Believe-it-or-not, we have lot of members who are also in Bronxville’s Investment Club. They wanted to write a program to simulate trading stocks based on some mathematical model. With the crisp scent of sandalwood and freshly minted 100-dollar bills suddenly wafting through the room, the rest of us didn’t need much convincing.

So after a vote (after all, we are a autonomous collective not a dictatorship), we decided to work on an algorithmic trading simulation. Our program would repeatedly get the current stock price, then make a decision to ‘buy’ or ‘sell’ some number of shares. The simulation would end after the program runs out of cash, shares, or completes a certain number of trades.

There are much better and easier ways of testing quantitative trading algorithms than hacking together a program in Python (Quantopian comes to mind), but we wanted to do it from scratch. We used MarketOnDemand’s web API as our data source. The program makes a request for a particular stock symbol and their servers return a JSON containing the price, volume, market capitalization, and other statistics on the stock. This is definitely not the most elegant way to get data. To prevent our program making too many requests (basically DOSing them) and causing MarketOnDemand’s servers to blacklist our IP address, we added a 2 second sleeping period between trades.

Since we are but humble programmers, we decided to hold a joint meeting with Bronxville’s Investment Club to generate ideas for which algorithms to try. Students were interested in a pivot algorithm which would compare the change in prices of 2 competing companies (say Target and Best Buy). If Target increased more than Best Buy, the program would buy Target and sell Best Buy. Otherwise, it would buy Best Buy and sell Target.

Students in the Investment Club were also interested in programs which could execute trades for them (for their MarketWatch trading game) when they were off-line. We wrote a threshold program which would buy or sell stocks when they reached a certain price or at a certain time. We also tried a program that made trades based on the change in a stock volume.

Finally, I wanted to run a program which traded based on the price’s exponential moving average. The ETA is a fun piece of math which calculates the average of a series, but weighs recent values exponentially more. So the most recent value might be weighted to make up half the ETA, then the second would be a fourth, the third an eighth, and so on. Thinking about this in terms of signal processing, the function is really just a kind of low-pass filter.

Since the algorithm makes trades based on an average of the most recent prices, it makes money when the stock price zig-zags over a relatively steady trend (technically, this is called volatility). Really, what we are doing is discarding high frequency component of the signal on the assumption this is just noise and doesn’t add much to the overall trend. This is very similar to what is done in many ‘lossy’ data compression algorithms such as JPEG.

This trading strategy is called means-marginalization. Quantitative finance funds’ attempts to use it to arbitrage small price fluctuations one of the reasons stock markets have recently seen dramatic decreases in volatility and increases in liquidity.

Anyway, below you can read about our results in the attached PowerPoint or look over the source of our project.

• Please do not interpret anything said here as ‘investment advice.’ Also remember every quantitative trading strategy we tried lost money.

I am leading a group at Bronxville building an autonomous flying drone. Our goal is to assemble a quadcopter (Helicopter with four props in an X-configuration) capable of self-navigation using GPS waypoint files. Although there are several excellent open-source autopilots, we decided to write our own for twice the fun.

Right now we are about half done, having built some thing that can more or less hover in-place, so I thought I would upload the code here and document the journey.

We got the group together last summer. It is a solid bunch including seniors, juniors, and sophomores. There is only one other programmer in the group – a fun guy if you like Linux pineapples – so we are a little light on coders.

The first step was to scare up some funding so we calculated a first order estimate of the cost. Then I had the privilege of running from the Student Faculty Legislature to the School Foundation to the Business Office back to Student Faculty Legislature and finally to the Principal. Fortunately, our school generously encourages independent research and funding was obtained.

We ordered a laundry list of parts from Hobby King, a Hong Kong discount RC distributer. Most items on the site cost at least 30% less compared to other vendors, so it is a good source for ESCs, motors, batteries, and other standard components. Of course, the shipping adds heavily to the price and takes nearly a month. DHL, a company I have learned to love and hate, performs it.

In the meantime, we decided to get a head start on the code. We borrowed an Arduino Mega from the school to be the brains of the copter. I had some experience with C and I had read Eliot Wilson’s excellent book on AVR programming so I was pretty confident. Looking back, I probably shouldn’t have been.

All of my C programming had been on desktops with forgiving memory protections and helpful tools like gdb. It was also exclusively procedural. The closest I came to an object was the odd struct.

You can probably imagine what our early looked like. It was strewn with pointer typos, malformed classes, and * gasp * parallel arrays. I never raised a single seg fault though.

Anyway, we finally figured out we should brush up on OOP programming in C++. The site cppreference.com was super helpful. Anyway we eventually figured out that Arduino was C++ library rather than a language.

Arduino code is written in C++, compiled by avr-gcc, and flashed on to a microcontroller by arvdude. This toolchain is mostly hidden by the Arduino IDE, but when something goes wrong it can difficult to troubleshoot.

The first parts to arrive were the GPS and Inertial Measurement Unit (IMU) from SparkFun. The IMU had nine degrees of freedom: a three axis compass, a three axis gyroscope, and a three axis accelerometer. Figuring out the drone’s orientation from these instruments is interesting problem.

Gravity is always pulling on the drone, so on average the accelerometer readings will produce a vector pointing down. The accelerometer is frequently jiggled however, so over the short term it can be highly inaccurate.

The gyroscope’s reading of the angular velocity, on the other hand, is very stable, but over time it can pick up angular momentum and ‘drift’ away from an accurate reading. So neither instrument can accurately predict the drone’s orientation.

The solution to the puzzle is use a the accelerometer readings over the long term and the gyroscope readings over the short term. This done by putting the accelerometer reading through low-pass filter, putting the integrated gyroscope reading through a high-pass filter, and combining the result.

I won’t go into the specifics here because it is well documented elsewhere on the web, but this technique is called a complementary filtering. It makes the small angle approximation (we pretend sin(&#1012) is linear) which is acceptable for our drone because it should never turn by more 15 degrees.

Once we had an accurate measurement of the drone’s orientation, we needed a way to change it. The motors alternate clockwise and counterclockwise spinning props in X configuration. This means that we can increase and decrease power to various sets of motors to change the yaw, roll, and pitch individually or in combination.

Unlike an airplane or helicopter, quadcopters are not aerodynamically stable. Without constant correction, little errors will rapidly grow until the drone spins out of control. This is good because it makes them highly maneuverable, but bad because it means the drone will naturally want to crash.

We used a PID controller to make those corrections. It calculates the difference between the desired angle, say 0 degrees, and the current angle, say 1 degree. That is the error. Then it produces a control signal based on the sum of a term proportional to the error, a term proportional to the integral of the error, and a term proportional to derivative of the error. The motors are adjusted based on that control signal to to correct the error.

The mathematics behind PID controllers is quite sophisticated, but intuitively it is same process you might use to adjust a faucet’s water temperature. You start by turning to its hottest setting, and then crank it back as the water becomes too warm.

Anyway, they were relatively simple to implement once we understood them. It was bonus points that I got to bug my math teachers about Laplace transforms though, so that was an upside.

Both the complementary filter and PID controller have several constants which we tuned by placing the drone on a fixed axis. A rod was passed through the frame so that the drone could only rotate around one arm. We had a lot of fun (and cut a few fingers) with that.

Now we are at the hovering stage. We are about to start testing the PID and complementary filter off the axis. After that we will implement GPS navigation using waypoint files and distance-direction vectors.

Stay tuned for part two. Also check out the 3D JavaScript Flight Planner we wrote to generate the waypoint files.