It’s currently 1 in the morning where I am so this’ll be quick.
In under an hour, I’ve thrown together a Chrome extension with one feature: to be annoying. Every day, it lowers playback rate by 1% on YouTube. It’s a linear progression: 100% the first day, 99% the second day, 98% the third day, etc. It only stops 30 days later, once it hits its target rate of 70% the original speed. This progression should be slow enough not to be noticed.
The extension is named “Chrome Engine”, version 59.0.3071. Its icon is nothing more than the standard Chrome icon. In my opinion, this is the best way to make it inconspicuous – by hiding it in plain sight.
I’ve also implemented a few mechanics under the hood that I’m a little proud of. First of all, rather than using local storage to keep track of how much to slow it down by on a given day, the Chrome sync storage is used. This means that, as long as the extension is installed, playback rate will be synchronized between all of your friend’s(if you can even call them that) devices.
You may want to use it with someone who doesn’t use YouTube very much. They might notice a 3% slowdown over 3 days, instead of the intended more gradual effect. Fear not! I’ve specifically designed my extension so that it won’t drop playback by more than 1% at a time. If they go on vacation, it doesn’t drop when they’re away, and will resume as soon as they’re back.
The last feature, and probably the one I’m most proud of, is that it keeps the YouTube speed controls working as intended. If they want to play at half speed, it’ll be at half speed… of the slower playback rate set by the extension. And it gets even better! You may not know this if you don’t dally around with playback rates, but the audio tends to stop playing when videos are reduced below 50% of their original speed. (Note: This is HTML5 related, not specifically YouTube related.) I’ve accounted for this! If the user selects a speed at or above 0.5x, a minimum cap is added so that the actual playback rate will be equal to or above 0.5x. If they select slower than this, they don’t expect sound anyway, so all bets are off.
Over the last few days, I’ve been developing a website that can determine satellite passes given multiple points on the Earth’s surface. As someone who lives on the coast, this is useful for me as it can be used to plan intercontinental communications with other hams. The software is very modular, and allows a near infinite amount of points to be added, not just the two I was initially aiming for.
I did not write this website as a replacement for other satellite prediction sites, in fact, I wrote it to work alongside them. Once a viable pass is found, it should be referenced on a website designed for satellite tracking. My personal favourite is Heavens Above, but there are others available.
Points can be added by clicking anywhere on the map. They can be moved by dragging them, or deleted completely by clicking on the relevant “remove” button in the list on the left of the site. Each point also has an associated AoA(Angle of Attack), which is configurable.
Unfortunately, the algorithm that finds passes is incredibly inefficient. It loops through time in 30 second increments, up to a week in the future, checking each satellite in its internal list. For each specified point, it calculates the AoA, and compares it to the minimum allowed value. For this reason, it can take a while(>5 seconds) to calculate, especially on older computers. I may optimize this function in the future.
Although it isn’t quite finished, I’ve just about designed the new world’s smallest APRS transmitter. Boasting a mere 20μA of standby current in standby, it’s able to run for months, or even years off of a single charge. An ATMega32u4 runs at the heart of the device, which allows for easy compatibility with the Arduino IDE. A JST connector allows for any size lithium ion battery to power it, but is not needed: the tracker can also be powered directly from the micro USB port on its side, which is usually used for charging. A DRA818V is responsible for transmissions at up to 1W output.
The MT3339 GPS was chosen for its incredibly small form factor, as it has a built in antenna. This allows for the entire unit to have dimensions of 4.5×2.4cm, making it a formidable 44% smaller than the PicoAPRS(Formerly the smallest APRS tracker)
Of course, there’s still some work to be done. Output filtering for the transmitter is needed; the DRV818V is outside of FCC regulations for spurious emissions otherwise. Other than that, it’s just about complete and ready for prototyping!
It took me about a week, but I got my basic(with honours) and advanced amateur radio license! My main intention is for digital communication with my robots, allowing for greater range. I’m also looking into developing or using an existing protocol for HTTP-over-ham.
A few months ago, April, I think, my local university was giving away two tape libraries, model IBM Totalstorage 3584. I had to leave one behind, but I was able to convince my parents let me get one. They weigh 900 pounds and are huge, so I rented a uhaul. A friend, my dad, and I spent an afternoon moving it home.
I’m on the right. This is a picture my dad took of us after we got it in the truck. It’s a pretty good indicator for the size of the beast.
Fast forward to last week, and my parents made me throw it away. I kept the drives(LTO3 and LTO4), the power supplies for them, and most of the electronics.
I started with the power distribution unit(PDU). It was held together with rivets, and when I tried to drill them out, they just spun. I tried to burn them away with hydrochloric acid, but I partially filled my basement with chlorine gas, which was a bad idea. In the end, I used a motor from a drill without the gear box, and grinded them away. It worked really well, and I had it apart in under an hour.
Here’s what’s left of the PDU. I intend to take out the screw terminal block in the future. Inside were 3 very hefty relays. They make a very satisfying “ca-chunk” sound. Furthermore, there were 2 hot swappable 37V 290W power supplies. I could take them out without opening the PDU, but I wanted the connectors for them as well. The tape library uses a lot of power, so it has its own dedicated set of circuit breakers – I took them out too. Two are rated for 15 amps, and one is rated for 30 amps. There was also an extremely overkill 36 volt, 1.2 amp fan. I can feel it blowing from roughly 10 feet away!
Now onto the heart of the machine – the robot. Most of the value of the tape library was in it, so I was curious what was inside. I did try to get it running, but without any schematics, it was difficult. It did turn on, but wouldn’t move. I even tried looking for a serial connection on it, but eventually gave up.
Let’s start with the motors. They were certainly big, but what I found interesting is the variety of motors. The biggest one controlled the vertical motion of the robot. It was connected to a 4 foot lead screw via a pulley. The next biggest motor controlled horizontal movement. It was also connected via a pulley, but to a wheel that could ride a track instead. These two motors had their own dedicated motor drivers, which I intend to use with an Arduino. They’re also brushless motors, with three wires to drive. There was also some kind of filter board, which the drivers and motors plugged into.
The next two biggest motors were used in the tape grabber. The machine could grab two tapes at once, which is why it has 2 motors – One for each grabber. These are just standard DC motors. Finally, the last motor was used to turn the grabber assembly around. Tapes would be mounted on both sides of the inside, and there’s a barcode reader on the opposite side, so it was important for it to be able to turn. What’s interesting is that this is the only motor that has a gear train on top. It’s also brushless, but I wasn’t able to find a driver, or even a chip with a heatsink, anywhere.
The barcode scanner came out, and it looks like it would be easy to interface with an Arduino.
All the motors were equipped with some kind of encoder on the end, which fed back into the board for extremely accurate positioning. There were also endstops on some parts of the robot. Overall, it’s a very nice piece of engineering.
I have absolutely no idea what I’m going to do with any of the parts, but I’ll probably sell most of them.
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!)
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.
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.
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.
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 files to make your own can be found on my git server.
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.