An unexpected load test

A few days ago, there was a post on /r/Minecraft. Someone put up a 1.4GB world file. It was a scale model of the Earth. It got more popular than they expected, and they hit bandwidth limits on free sites, so I offered to host it for them, with no limitations. It peaked somewhere around 85 downloads. Although my internet upload was saturated, I didn’t really mind. By the next morning, I was down to only 5 or 6 concurrent downloads(I keep a window open on one of my screens that checks every 2 seconds). I thought my 5 seconds of fame were over.

But then the concurrent connections count started rising again. Within a minute it was back up to 20, then 30, then 40. I was extremely baffled, so I thought to google the link to the file on my server. It led to the description of a youtube video, which had been posted 15 minutes ago by this point. I checked and he had just over a million subscribers! The download count kept rising, up to 118 concurrent downloads.

I didn’t mind, but there were a few problems. First of all, I didn’t want the file hotlinked, so I set up a rewrite rule(301) to redirect from the file(Which was hotlinked on a different domain, a website purely dedicated to silly things my math teacher says) to a page on my blog, with a link to the file in the post. It was a pretty short post, the youtuber was french so I didn’t want to hide the download link too much. I had that fixed in a few minutes, but I still had another problem.

The server was taking 4-5 seconds to load the math teacher site, which was purely static HTML and an image, and was timing out to reach my blog(WordPress + https). The CPU and RAM of the web server weren’t anywhere near maxed. It turns out the problem was in apache’s config: “MaxClients” was set to its default of 150. I increased it to 500, and immediately, load times went away, and everything was back to normal. Apache2 peaked around 180 processes, if I remember correctly.

This was all yesterday. It seems to have died down now. I made a dollar from adsense for all my hard work. c: (Kidding of course, it was a lot of fun for me, especially having my homelab being used by so many people, and I’d gladly do it again!)

A robot designed for control from anywhere in the world

I’ve spent the last week on-and-off building a robot so I could remotely watch my house when on vacation. What I’ve built is hugely overkill, but it works great and it’ll be easy to repurpose in the future. It has a massive LED on the front, way too much torque, a Linksys WRT54G for transmitting and receiving data, and an Arduino Mega 2560 as a brain.

IMG_0101 IMG_0102 IMG_0103 IMG_0104 IMG_0105

Let’s start with the motors. I am using two drill motors. I bought the drills at Value Village, a local thrift store, for roughly $5 a piece. They weren’t the same voltage, so I have to use software so the robot doesn’t drift. They are extremely powerful; The robot was able to pull around a cart with a very heavy marine battery on it. I could probably pull more, but the limitation was that there wasn’t enough weight above the wheels, so the wheels would spin. I have the motors software limited to roughly 40% of their maximum power, because at 100% they’re incredibly fast.

For the motor drivers, I’m using a pair of BTS7960’s. With a maximum current of 43A, they are massively overkill for the drill motors. Both motors together, when stalled, draw around 10 amps. I imagine if the put the throttle at 100% I might get closer to that 43 amp limit. When driving the robot, the heat sinks don’t even get hot. Because of my frugality, I previously tried to use relays, in an H-Bridge, to drive around. It would have worked, if it wasn’t for the motors being way too fast at 100% power.

On previous robots, I’ve always had a problem with traction. This was due to using wheels from things that were designed to be pushed, for example, the wheels off a stroller. I’ve solved that problem – About a year ago, I saw a very hefty R/C car at the side of the road. I’ve kept the wheels, the motor, and the servo, but threw out the chassis. The wheels are also very hefty, and have no problem getting a grip. One slight problem I have is there isn’t enough weight above them, so they have a tendency to spin.

To mount the wheels to the motor shaft, I had to use a 3D printed part. At first, I just had the shaft screw into the part, but they kept shattering, so I found locknuts to go on the end of the motors, and I designed a part that could fit the lockut. The other end of the part has a few mounting holes – extras, even – and the wheels mount with two screws(which is a lot more secure than it sounds)

The robot also has a flashlight. I used a 30W LED and driver, which is way overkill, but it’s just what I had lying around. (I used it on my bike at night once, with a lead acid battery strapped to the side, and I lit up the entire width of the street and then some!) The driver is just an adjustable step-up converter, rated at 150W. It’s controlled by a 2 channel relay, giving me an extra channel for later.

Oh, and this robot actually has a proper fuse box, which is better than what I used to do, which was to just not mess up. Each motor has its own fuse, the LED has its own fuse, and the final fuse is for all electronics. I probably should have added another fuse between the battery and the power distribution screws, which provide power to the fuses.

For power, I have chosen to use a modest 12V 7AH lead acid battery. I put it right above one of the motors, which helps greatly with traction. I might upgrade to 2x 18AH 12V batteries, one above each motor, but for now, I still get about 2 hours of battery life. I also have a trailer with a marine battery, which should give me a lot more battery life once I add some weight above the wheels.

Power management is interesting. There are two very thick wires between the battery and two screw terminals – One negative, and one positive. There are 4 wires coming off the positive screw. Each goes to a different fuse. There are 6 wires coming off the negative screw, since some fuses have more than one device attached to them. There’s also a USB battery on top of the robot. This is to power the IP camera. While there’s no reason not to get a 12V to 5V converter and connect it to the same source, there’s also no reason to change. The battery is basically weightless, since it’s lithium based, and it runs longer than the lead acid. I had a 12V to 9V switching regulator laying around, so I used it to power the Arduino, to raise its efficiency slightly higher than it would be if I just fed it 12V.

What I’m sure you’ve noticed is that there are two layers. I actually physically ran out of space on the first layer, so I had to add a second layer. They are separated by 4 3D printed parts. I could have used wood, and it would have been stronger, but I have to cut all wood with a handsaw and it was a lot easier just to design and print instead.

I wrote all software myself, from scratch. Actually, that’s a lie, I borrowed some code from previous robots, but I improved upon it a lot for this version. First of all, the software was originally designed to run on a much smaller robot, which meant there were no safeguards. For example, if the robot was going forward and the connection dropped, it would keep going forever. I was able to fix that in this revision, so if no command is received for 250ms it cuts the motors and the light. It’s also able to gracefully recover from an unclean disconnect, instead of requiring a reset, which wouldn’t have been good if I was 1000 miles away. If no command is received for 2500ms, it terminates the client, allowing for it to start looking for another. Oh – and if one person is driving the robot, it doesn’t allow any other connections.

The software is up on git: here

In conclusion, this robot will easily serve its purpose, and then some. I spent around $100 CAD on it in total, which is a very modest price for such a powerful machine. If I had a chance to redo it, I would have given it some slightly bigger batteries, and I would have positioned them above the motors to give me more torque. After attaching a blade to its bottom, it should make a very good autonomous lawnmower.

Here’s a video of it in operation:

WIP: A Betavoltaic Cell to Power All the Things

While browsing Thingiverse, a 3D model hosting site, I stumbled upon this. It’s a betavoltaic cell, meaning it generates electricity from a source of beta waves. In this case, beta waves are generated from a small vial of tritium gas. The beta waves excite phosphorous, coated on the vial, which powers a small array of solar cells. Tritium-fueled betavolatic cells can provide power without intervention for up to 20 years! I found some flaws in his design, though, so I’m designing my own.

The main problem with the design I found is that it uses extremely inefficient solar cells. The cells only have about 45% of their surface area as photovoltaic material, meaning the rest is wasted. The tritium vial puts out minimal light, so every photon counts. Furthermore, I wasn’t able to find a panel of the same size that would still fit, while using the full surface area. My design uses these. They aren’t much bigger, but have 5 times the power output, which is a colossal difference.

There is still research to do before maximum efficiency can be achieved.For example, at what light level do the solar cells perform most efficiently? The more panels are put in a betavoltaic cell, the less light each one gets. If their efficiency was perfectly linear, it would even out, and the betavoltaic cell would generate the same amount of power no matter the number of solar cells, so less solar cells would be better due to the reduced cost. However, this is the real world, and nothing is ever that perfect. Solar cells will have a peak efficiency at a certain light level. That peak efficiency determines the ideal number of cells.

The betavolatic cell. Unpainted.
The betavolatic cell. Unpainted.
The render of the cell. This is what it will look like when painted.

The files to make your own can be found on my git server.


Kinect as a Greenscreen

While looking for an old project on my hard drive, I happened to stumble upon a different project – A Kinect-enabled green-screen that I wrote months ago. The idea is it uses a user-defined threshold to determine what pixels to replace. The default is 2000mm, or 2m. Any pixel closer than that is counted as ‘foreground’, and the corresponding background-image-pixel will be replaced with the pixel from the Kinect camera. This method has a massive advantage: No special lighting, background, or equipment is needed. Not even a flat wall is needed!

Of course, I wrote the program as a proof of concept more than anything. As such, there is no option to record – It just presents the modified image in real time. In fact, many variables that are now customizable through the GUI could only be changed within the code before I rediscovered the project and decided to improve it slightly.

The code can be found here.

Of course, feel free to contribute. I’ve included a TODO list of features that I’ve neglected to add.