Counting Laps And Testing Products With OpenCV

It’s been about a year and a half since the Batteroo, formally known as Batteriser, was announced as a crowdfunding project. The premise is a small sleeve that goes around AA and AAA batteries, boosting the voltage to extract more life out of them. [Dave Jones] at EEVblog was one of many people to question the product, which claimed to boost battery life by 800%.

Batteroo did manage to do something many crowdfunding projects can’t: deliver a product. Now that the sleeves are arriving to backers, people are starting to test them in the wild. In fact, there’s an entire thread of tests happening over on EEVblog.

One test being run is a battery powered train, running around a track until the battery dies completely. [Frank Buss] wanted to run this test, but didn’t want to manually count the laps the train made. He whipped up a script in Python and OpenCV to automate the counting.

The script measures laps by setting two zones on the track. When the train enters the first zone, the counter is armed. When it passes through the second zone, the lap is recorded. Each lap time is kept, ensuring good data for comparing the Batteroo against a normal battery.

The script gives a good example for people wanting to play with computer vision. The source is available on Github. As for the Batteroo, we’ll await further test results before passing judgement, but we’re not holding our breath. After all, the train ran half as long when using a Batteroo.

Jenkins Lights The Christmas Tree

Jenkins is open-source automation software that tries to automate parts of the software development process. When you submit code, for example, Jenkins will grab it, build the project with it and run any tests on it. If you have a large number of people submitting new code or data, Jenkins will wait and grab a bunch of the submissions to build. Depending on the size of the project, this can take a while, and if there’s a problem, you need to know quickly so that people aren’t waiting on a broken build. Email’s fine for this, but [dkt01] saw one of the desktop LED Christmas tree projects on Hackaday, and integrated it into his Jenkins system.

Like the other projects, WS2812b LED rings are used as the tree, and an Arduino Pro Mini runs the show, with an Ethernet LAN Module to communicate with the Python script that monitors the Jenkins build job. The Python script sends commands to the Arduino, which in turn lights up the LEDs. They light up green on a successful build and red if something fails, but during the build process, the LEDs show the current state of the build, tracking Jenkins’ progress as it builds.

Our previous Jenkins post used a big, red LED light that would light up if the build failed. [dkt01]’s build lets you know if the build is successful or has failed, but the build progress is a great addition.

Continue reading “Jenkins Lights The Christmas Tree”

The First Bug On Mars

Interplanetary probes were a constant in the tech news bulletins of the 1960s and 1970s. The Space Race was at its height, and alongside their manned flights the two superpowers sent unmanned missions throughout the Solar System. By the 1980s and early 1990s the Space Race had cooled down, the bean counters moved in, and aside from the spectacular images of the planets periodically arriving from the Voyager series of craft there were scant pickings for the deep space enthusiast.

The launch in late 1996 of the Mars Pathfinder mission with its Sojourner rover then was exciting news indeed. Before Spirit, the exceptionally long-lived Opportunity, and the relatively huge Curiosity rover (get a sense of scale from our recent tour of JPL), the little Sojourner operated on the surface of the planet for 85 days, and proved the technology for the rovers that followed.

In these days of constant online information we’d see every nuance of the operation as it happened, but those of us watching with interest in 1997 missed one of the mission’s dramas. Pathfinder’s lander suffered what is being written up today as the first bug on Mars. When the lander collected Martian weather data, its computer would crash.

Like many other spacecraft, the lander’s computer system ran the real-time OS VxWorks. Of the threads running on the craft, the weather thread was a low priority, while the more important task of servicing its information bus was a high priority one. The weather task would hog the resources, causing the operating system equivalent of an unholy row in our Martian outpost. A priority inversion bug, and one that had been spotted before launch but assigned a low priority.

You can’t walk up to a computer on another planet and swap out a few disks, so the Pathfinder team had to investigate the problem on their Earthbound replica of the lander. The fix involved executing some C code on an interpreter prompt on the spacecraft itself, something that would give most engineers an extremely anxious moment.

The write-up is an interesting read, it’s a translation from a Russian original that is linked within it. If the work of the JPL scientists and engineers interests you, this talk from the recent Hackaday superconference might be of interest.

[via Hacker News]

Disassembly Required

If you really want to hack software, you are going to face a time when you have to take apart someone’s machine code. If you aren’t very organized, it might even be your own — source code does get lost. If you want to impress everyone, you’ll just read through the hex code (well, the really tough old birds will read it in binary). That was hard to do even when CPUs only had a handful of instructions.

A more practical approach is to use a tool called a disassembler. This is nothing more than a program that converts numeric machine code into symbolic instructions. The devil, of course, is in the details. Real programs are messy. The disassembler can’t always figure out the difference between code and data, for example. The transition points between data and code can also be tricky.

When Not to Use

If you are coding your own program in assembly,  a disassembler isn’t usually necessary. The disassembly can’t recover things like variable names, some function names, and — of course — comments. If you use a high-level language and you want to check your compiler output, you can easily have the compiler provide assembly language output (see below).

The real value of a disassembler is when you don’t have the source code. But it isn’t easy, especially for anything nontrivial. Be prepared to do a lot of detective work in most cases.

Continue reading “Disassembly Required”

Practical Deep Learning

Deep Learning — the use of neural networks with modern techniques to tackle problems ranging from computer vision to speech recognition and synthesis — is certainly a current buzzword. However, at the core is a set of powerful methods for organizing self-learning systems. Multi-layer neural networks aren’t new, but there is a resurgence of interest primarily due to the availability of massively parallel computation platforms disguised as video cards.

The problem is getting started in something like this. There are plenty of scholarly papers that can be hard to wade through. Or you can grab some code from GitHub and try to puzzle it out.

A better idea would be to take a free class entitled: Practical Deep Learning for Coders, Part 1. The course is free unless you count your investment in time. They warn you to expect to commit about ten hours a week for seven weeks to complete the course. You can see the first installment in the video, below. Continue reading “Practical Deep Learning”

Real-Time Planet Tracker With Laser-Point Accuracy

Space. The final frontier. Unfortunately, the vast majority of us are planet-locked until further notice. If you are dedicated hobbyist astronomer, you probably already have the rough positions of the planets memorized. But what if you want to know them exactly from the comfort of your room and educate yourself at the same time? [Shubham Paul] has gone the extra parsec to build a Real-Time Planet Tracker that calculates their locations using Kepler’s Laws with exacting precision.

An Arduino Mega provides the brains, while 3.5-turn-pan and 180-degree-tilt servos are the brawn. A potentiometer and switch allow for for planet and mode selection, while a GPS module and an optional MPU9250 gyroscope/magnetometer let it know where you are. Finally a laser pointer shows the planet’s location in a closed room. And then there’s code: a lot of code.

The hardware side of things — as [Shubham Paul] clarifies — looks a little unfinished because the focus of the project is the software with the intent to instruct. They have included all the code they wrote for the RTPT, providing a breakdown in each section for those who are looking to build their own.

Continue reading “Real-Time Planet Tracker With Laser-Point Accuracy”

Hacking A Device That Lives Inside The Matrix

[Gerardo Iglesias Galván] decided he wanted to try his hand at bug-bounty hunting — where companies offer to pay hackers for finding vulnerabilities. Usually, this involves getting a device or accessing a device on the network, attacking it as a black box, and finding a way in. [Gerrado] realized that some vendors now supply virtual images of their appliances for testing, so instead of attacking a device on the network, he put the software in a virtual machine and attempted to gain access to the device. Understanding the steps he took can help you shore up your defenses against criminals, who might be after more than just a manufacturer’s debugging bounty.

Continue reading “Hacking A Device That Lives Inside The Matrix”