So about that go-kart I was building...
Continuing where I left off, I needed to wire up the motor controllers with the motor, throttle, and mains (power). It was pretty simple; just read the wiring diagram in the motor controller manual and connect wires where appropriate.
My work layout on the EE bench is pretty simple. I have a 30V power supply powering the motor controller (the silver brick), which is connected to the three phases of the motor, hall sensor, and the throttle (not pictured here). The red multimeter is for testing the various voltages on the motor controller wires to make sure none of the wires are broken. One of my friends had this bug, and it took her a while to figure out!
I also have some helping hands, which are the silver arms holding wires over the table. The throttle is near the bottom right of the picture, below the blue strippers. The super awesome soldering station is a Weller industrial soldering station.
It took a while for me to figure out that both power inputs to the motor controller need to be 18+V, something the manual doesn't say. Thanks Charles!
There are two red LEDs (well one has a red housing and the other has a clear housing) amid the wires which indicate the motor controller status. Here, the clear LED should be solid red and the red LED off.
Here's a photo of hall sensor jiggling, with a great writeup by Charles. The goal is to figure out which permutation of phases I should connect the motor to the controller. If the motor and controller are not matched properly, then the motor will not spin. There are 3! = 6 permutations, but luckily I found the right pairing on my second try.
However, one motor has to spin CW and the other CCW since the motors are mounted opposing each other. To make the motor spin the other way, you have to cyclically shift the three phases. There are only two distinct shifts, and I was pretty happy that I got the motor spinning on my second try.
There's more to come! What remains is hooking up the motors to the chassis, installing the chains, and refurbishing the rest of the vehicle as necessary to get it running!
25 April 2014
15 April 2014
Math For America Poker Tournament
Saw this posted somewhere on the internet. Browsed the organizers list and previous winners. Many names were familiar, not only from books, but also from previous correspondence. It's a small world.
11 March 2014
Cryptocurrency Mining
This post is a walk down memory lane of the past two months of mining.
Smashing 4 GPUs together doesn't work well at all without hardcore ducting. Turns out that this setup actually mines slower than 3 GPUs and a fan on top.
It turns out that the limiting factor is power density. I wasn't going to buy faster GPUs because of a poorer hashrate per dollar, so I needed to get more PCIe slots. I bought some dumb nodes to get my other pile of GPUs up, but after this fan cutting my hand (and losing a blade in the process), I resigned.
Pile of unused GPUs. These sat unused for the duration of mining.
My two former miners:
tl;dr Making money is hard.
Smashing 4 GPUs together doesn't work well at all without hardcore ducting. Turns out that this setup actually mines slower than 3 GPUs and a fan on top.
It turns out that the limiting factor is power density. I wasn't going to buy faster GPUs because of a poorer hashrate per dollar, so I needed to get more PCIe slots. I bought some dumb nodes to get my other pile of GPUs up, but after this fan cutting my hand (and losing a blade in the process), I resigned.
Pile of unused GPUs. These sat unused for the duration of mining.
My two former miners:
tl;dr Making money is hard.
08 January 2014
Abusing the C Preprocessor
On a whim, I thought of this idea after reading Cory Li's article on bytecode hacking for Battlecode, MIT's premier Independent Activities Period competition, and after reading some code of his bot, which won Battlecode 2012. Optimized code gets real messy real fast, so wouldn't it be nice if it could be (just a little) easier to write?
The C and sibling languages have a wonderful feature called preprocessing. This feature allows one to insert snippets of text character for character into another file, so as to save time and space writing redundant code. The most prevalent use of the preprocessor is for including header files:
Another use of the preprocessor is to define macros. For example, in competitive programming, one iterates from 0 (inclusive) to N (exclusive) reasonably often, so why spend the time to type
when it can be compressed to
all with the simple macro
Now it's great that C offers this, but what about languages that don't, such as Java? Is there a way to make the C preprocessor do this for us?
The answer, unsurprisingly, is yes! We can use cpp (that's c preprocessor)
to find all the macros in our code, as defined by
So how do we put all of this together? We first write C-ified Java code
and preprocess it with cpp to generate the almost-legitimate Java code. We can strip the aforementioned lines that start with # by passing the output of cpp to sed with a regex that deletes any line that starts with # and redirect the sanitized output to our desired Java file
Finally, we compile Test.java and run it with
The C and sibling languages have a wonderful feature called preprocessing. This feature allows one to insert snippets of text character for character into another file, so as to save time and space writing redundant code. The most prevalent use of the preprocessor is for including header files:
#include <stdio.h>
int
main()
{
printf("%s\n", "Hello, world!");
return 0;
}
Another use of the preprocessor is to define macros. For example, in competitive programming, one iterates from 0 (inclusive) to N (exclusive) reasonably often, so why spend the time to type
for (int i = 0; i < N; ++i)
{
// ...
}
when it can be compressed to
F(i, N)
{
// ...
}
all with the simple macro
#define F(i, N) for (int i = 0; i < N; ++i)
Now it's great that C offers this, but what about languages that don't, such as Java? Is there a way to make the C preprocessor do this for us?
The answer, unsurprisingly, is yes! We can use cpp (that's c preprocessor)
cpp test.c
to find all the macros in our code, as defined by
#define, replaces them with the value with which they are defined, and removes the #define. However, it leaves some junk in the code, namely some lines at the beginning of the files starting with #, so we have to remove those before giving the preprocessed file to javac.So how do we put all of this together? We first write C-ified Java code
Test.cjava with our macroimport java.util.*;
#define F(i, N) for (int i = 0; i < N; ++i)
public class Test {
public static void main(String[] args) {
F(i, 5) {
System.out.println(i);
}
System.exit(0);
}
}
and preprocess it with cpp to generate the almost-legitimate Java code. We can strip the aforementioned lines that start with # by passing the output of cpp to sed with a regex that deletes any line that starts with # and redirect the sanitized output to our desired Java file
cpp Test.cjava | sed '/^#/d' > Test.java
Finally, we compile Test.java and run it with
java Test, which will produce the desired output
0 1 2 3 4
30 December 2013
Dream Come True
Can I help you?
Yeah. Do you have the new 911?
Yeah. It's right over here.
Do you want to get in?
Really?
Sure.
Exhales
Do you have a business card?
Sure
Thanks.
I'll see you in about 20 years.
It's a funny thing about a Porsche. There's the moment you know you want one. There's the moment you first own one. And for the truly afflicted, there's the decade or two that passes in between.
Only took about 11 years!
08 December 2013
Words of Wisdom
In the process of choosing which job to take next year, I have received the following pieces of advice:
"Go to the company with the smartest people."
"Go to the company at which you think you'll most likely be fired."
"Go to the company whose project most interests you."
"Go to where the Lamborghinis are."
"Go to where you want to go."
"Go to where you think you'll be happiest."
"Don't buy GPUs to mine coins."
"Go to the company with the smartest people."
"Go to the company at which you think you'll most likely be fired."
"Go to the company whose project most interests you."
"Go to where the Lamborghinis are."
"Go to where you want to go."
"Go to where you think you'll be happiest."
"Don't buy GPUs to mine coins."
Labels:
jobs
29 October 2013
Costly Signaling: The Quest for a 90.0%
I remember that during my senior year of high school, there was some unofficial competition among friends to get the lowest final grade possible without ``Asian-failing." That is, to do as poorly as possible on graded assignments without getting the dreaded B+. The GPA cutoffs was set such that an A [93%, 100%] was a 4.0/4.0, A- [90%, 93%) was a 3.8/4.0, and B+ [87%, 90%) was a 3.3/4.0, so dropping from an A- to B+ is a much bigger deal than dropping from an A to A-. This game was certainly fun to play, but at that time I didn't understand the reasons that we participated.
It turns out that costly signaling could explain this phenomenon. Costly signaling, or the handicap principle, is a behavior that is costly for all groups, but more costly for the ``worse'' group than it is for the ``better'' group. In this case, better and worse are in terms of ability to do well in class and cost is the expected grade, which is related to the probability of sinking below 90% and the probability of being able to rescue a failure. I assume that the less smart kids have less control over their performance on assessments since they probably (1) can correctly answer fewer questions and (2) are more prone to make trivial errors.
Riskier variations include playing the game below senior year, during which grades are more valuable (since colleges will see them), or at MIT. I wonder how the brave souls at the Institvte would do, since the cliff between an A- (5.0/5.0) and a B+ (4.0/5.0) is massive.
It turns out that costly signaling could explain this phenomenon. Costly signaling, or the handicap principle, is a behavior that is costly for all groups, but more costly for the ``worse'' group than it is for the ``better'' group. In this case, better and worse are in terms of ability to do well in class and cost is the expected grade, which is related to the probability of sinking below 90% and the probability of being able to rescue a failure. I assume that the less smart kids have less control over their performance on assessments since they probably (1) can correctly answer fewer questions and (2) are more prone to make trivial errors.
Riskier variations include playing the game below senior year, during which grades are more valuable (since colleges will see them), or at MIT. I wonder how the brave souls at the Institvte would do, since the cliff between an A- (5.0/5.0) and a B+ (4.0/5.0) is massive.
28 October 2013
All I Do These Days
- Problem sets
- Ride planes and trains
- Code over the phone or on whiteboards
- Obsessively hit refresh on Autotrader.com
Labels:
MIT
24 September 2013
Porsche 918 Configurator LIVE!
The most expensive car whose price is shown in an online configurator is...the Porsche 918 Spyder! And to add further insult, all 918 examples have been pre-ordered.
Here's to hoping I'll have a chance to drive one of these bad boys!
Here's to hoping I'll have a chance to drive one of these bad boys!
Labels:
carpe diem,
cars
15 September 2013
San Francisco
Immediately after my internship, I flew to San Francisco for a short one-week vacation to chillax while I still had the chance.
Jet lag produces excellent morning photos
I made a day trip to south bay to visit Apple. I had lunch with my mentor and then went for coffee with a few others on the iOS team.
The reason I chose to go to south bay on this day is that Apple organized a small auto show at one of the campuses. I got to see a number of supercars and classics.
AC Cobra
McLaren MP4-12C air vent
Wings of freedom
Lamborghini Gallardo LP570-4 Superleggera mirror cap
AC Cobra Coupe
Salute
McLaren MP4-12C mirror cap
McLaren MP4-12C engine
McLaren MP4-12C door opened
Mercedes-Benz SLS AMG front emblem
The most intriguing supercars were the McLaren MP4-12C and the Mercedes SLS. I may just have a thing for door mechanisms, but I gotta say, scissor doors are the coolest. I think they intrigue me because I don't have a clear picture of where the hinge mechanism is mounted -- there's no obvious flat edge on which the door pivots like in traditional doors (leftmost edge) or gullwings (topmost edge).
I'm not too versed on classic cars, but I did recognize the BMW 2002! Oh, the things I learn from playing Forza 4. There were also a bunch of Cobras and a Porsche 356 Speedster in British racing green.
Automobiles aside, staying in San Francisco, specifically SoMa (South of Market for non-natives), was quite pleasant. Compared to the Tenderloin, where I stayed for an on-site interview. The surrounding area was decently clean (I would say not as clean as the loop in Chicago) and had plenty of attractions. Namely, the Apple store was only five minutes away by foot. :) Plenty of restaurants were close by, including Chinatown. (Aside/funny story: we went to a dim sum place for lunch, and I was awed when our waiter computed our bill (including tax!) in his head. I joked that I would never be able to work there.) We also walked along the piers and went to Ghiradelli Park one afternoon.
That said, rent in San Francisco is laughably expensive, to say the least. It turns out that rent for a one bedroom corner unit in a relatively nice location is $4k/month. To put this in perspective, a two bedroom/two bathroom unit in the penthouse tower in Chicago is $3.2k/month. One would think that high rent and high income taxes would be sufficiently large deterrents.
But inexplicably, I think that I will be sucked into this vortex known as the Bay Area.
Labels:
carpe diem,
cars,
photography,
vacation
Subscribe to:
Posts (Atom)


























