Day: January 22, 2019

Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™

January 22, 2019 by 58 Comments

Let’s be honest, no one likes to see their program crash. It’s a clear sign that something is wrong with our code, and that’s a truth we don’t like to see. We try our best to avoid such a situation, and we’ve seen how compiler warnings and other static code analysis tools can help us to detect and prevent possible flaws in our code, which could otherwise lead to its demise. But what if I told you that crashing your program is actually a great way to improve its overall quality? Now, this obviously sounds a bit counterintuitive, after all we are talking about preventing our code from misbehaving, so why would we want to purposely break it?

Wandering around in an environment of ones and zeroes makes it easy to forget that reality is usually a lot less black and white. Yes, a program crash is bad — it hurts the ego, makes us look bad, and most of all, it is simply annoying. But is it really the worst that could happen? What if, say, some bad pointer handling doesn’t cause an instant segmentation fault, but instead happily introduces some garbage data to the system, widely opening the gates to virtually any outcome imaginable, from minor glitches to severe security vulnerabilities. Is this really a better option? And it doesn’t have to be pointers, or anything of C’s shortcomings in particular, we can end up with invalid data and unforeseen scenarios in virtually any language.

It doesn’t matter how often we hear that every piece of software is too complex to ever fully understand it, or how everything that can go wrong will go wrong. We are fully aware of all the wisdom and cliches, and completely ignore them or weasel our way out of it every time we put a /* this should never happen */ comment in our code.

So today, we are going to look into our options to deal with such unanticipated situations, how we can utilize a deliberate crash to improve our code in the future, and why the average error message is mostly useless.

Continue reading “Crash Your Code – Lessons Learned From Debugging Things That Should Never Happen™” →

New Part Day: Small, Cheap, And Good LIDAR Modules

January 22, 2019 by 40 Comments

Fully autonomous cars might never pan out, but in the meantime we’re getting some really cool hardware designed for robotic taxicab prototypes. This is the Livox Mid-40 Lidar, a LIDAR module you can put on your car or drone. The best part? It only costs $600 USD.

The Livox Mid-40 and Mid-100 are two modules released by Livox, and the specs are impressive: the Mid-40 is able to scan 100,000 points per second at a detection range of 90 m with objects of 10% reflectivity. The Mid-40 sensor weighs 710 grams and comes in a package that is only 88 mm x 69 mm x 76 mm. The Mid-100 is basically the guts of three Mid-40 sensors stuffed into a larger enclosure, capable of 300,000 points per second, with a FOV of 98.4° by 38.4°.

The use case for these sensors is autonomous cars, (large) drones, search and rescue, and high-precision mapping. These units are a bit too large for a skateboard-sized DIY Robot Car, but a single Livox Mid-40 sensor, pointed downward on a reasonably sized drone could perform aerial mapping

There is one downside to the Livox Mid sensors — while you can buy them direct from the DJI web site, they’re not in production. These sensors are only, ‘Mass-Production ready’. This might be just Livox testing the market before ramping up production, a thinly-veiled press release, or something else entirely. That said, you can now buy a relatively cheap LIDAR module that’s actually really good.

Screen Shake In VR, Minus The Throwing Up

January 22, 2019 by 5 Comments

In first-person games, an effective way to heighten immersion is to give the player a sense of impact and force by figuratively shaking the camera. That’s a tried and true practice for FPS games played on a monitor, but to [Zulubo]’s knowledge, no one has implemented traditional screen shake in a VR title because it would be a sure way to trigger motion sickness. Unsatisfied with that limitation, some clever experimentation led [Zulubo] to a method of doing screen shake in VR that doesn’t cause any of the usual problems.

Screen shake doesn’t translate well to VR because the traditional method is to shake the player’s entire view. This works fine when viewed on a monitor, but in VR the brain interprets the visual cue as evidence that one’s head and eyeballs are physically shaking while the vestibular system is reporting nothing of the sort. This kind of sensory mismatch leads to motion sickness in most people.

The key to getting the essence of a screen shake without any of the motion sickness baggage turned out to be a mix of two things. First, the shake is restricted to peripheral vision only. Second, it is restricted to an “in and out” motion, with no tilting or twisting. The result is a conveyance of concussion and impact that doesn’t rely on shaking the player’s view, at least not in a way that leads to motion sickness. It’s the product of some clever experimentation to solve a problem, and freely downloadable for use by anyone who may be interested.

Speaking of fooling one’s senses in VR environments, here is a fascinating method of simulating zero gravity: waterproof the VR headset and go underwater.

[via Reddit]