Some design techniques and concepts from the injection molding world apply very nicely to 3D printing, despite them being fundamentally different processes. [Teaching Tech] demonstrates designing shadow lines into 3D printed parts whose surfaces are intended to mate up to one another.
This is a feature mainly seen in enclosures, and you’ve definitely seen it in all kinds of off-the-shelf products. Essentially, one half of the part has a slight “underbite” of a rim, and the other half has a slight “overbite”, with a bit of a standoff between the two. When placed together, the combination helps parts self-locate to one another, as well as providing a consistent appearance around the mating surfaces.
Why is this necessary? When a plastic part is made — such as an enclosure in two halves — the resulting surfaces are never truly flat. Without post-processing, the two not-quite-flat surfaces result in an inconsistent line with a varying gap between them.
By designing in a shadow line, the two parts will not only self-locate to each other for assembly, but will appear as a much more consistent fit. There will be a clear line between the two parts, but no actual visible gaps between them. Watch the whole thing explained in the video, embedded below.
This isn’t the only time design techniques from the world of injection molding have migrated to 3D printing. Crush ribs have been adapted to the world of 3D printed parts and are a tried-and-true solution to the problem of reliably obtaining a tight fit between plastic parts and hardware inserts.
Continue reading “Enhance Your Enclosures With A Shadow Line”
If you want to make containers under Linux, plenty of high-level options exist. [Lucavallin] wanted to learn more about how containers really work, so he decided to tackle the problem using the low-level kernel functions, and he shared the code with us on GitHub.
Containers are more isolated than processes but not quite full virtual machines. While a virtual machine creates a fake computer, a container is more like a fake operating system. Applications can run with their own idea of libraries, devices, and other resources, but it doesn’t try to abstract the underlying hardware.
Continue reading “Linux Containers The Hard Way”
During the late 1980s NASA’s Jet Propulsion Laboratory (JPL) was busy developing the first ever wheeled robot that would roam the surface of Mars. Due to the long round-trip times of any signals between Mars and Earth, development of the firmware that would control the rover was a major point, with the two teams occupied with the task each picking different levels of autonomy for the rover. In a retrospective, [Ron Garrett] who worked at JPL on the ‘more autonomy’ team describes his recollections.
Whereas [Ron]’s team focused on creating a rover that could be provided with high-level instructions which the sophisticated LISP-based firmware would use as guidelines to navigate and operate by, the other team pursued a more limited autonomy approach whereby a human driver would use explicitly plan out the route which the rover would follow before awaiting new instructions.
Perhaps unsurprisingly, the system requirements for running LISP and the additional uncertainties and complexities with the autonomous approach, as well as testing and validating the firmware, resulted in the Sojourner Mars rover featuring the latter approach, with straightforward C-based firmware. Most of Sojourner’s autonomy was limited to a home return function if communication with the lander was lost, which limited both its range and operations during its 85-day extended mission.
As [Ron] covers with examples from later missions, one advantage of LISP is that it allows you to send instructions which can be interpreted (e.g. to debug the system) without having to program in such functionality explicitly. With later Mars rover missions much more of this autonomy that [Ron]’s team pioneered was implemented, although C remained the language of choice for these later rovers.
Heading image: Ron Garrett standing in front of the Robbie prototype. Rocky III can be see in the lower left, and above him are Rajiv Desai and Robert Ivlev, two other members of the team. (Credit: Ron Garret)
[James Stanley] likes to spend time making puzzles and gadgets for escape rooms, and decided for a change to try their hand at a bit of magic. The idea was to construct a ‘magic box’, in which a coin can be placed in one of a number of slots, and then be able to remotely be able to determine the slot by means unseen. Obviously, this is an electronics hack, with a neat package of sensor and radio comms hidden inside a stack of CNC-milled wood. Coin locations are transmitted via Bluetooth to a Bangle.js smartwatch, which vibrates according to the slot occupied, allowing [James] to predict where the coin was placed. Continue reading “The Egyptian Coin Box ‘Trick’”
We’re always looking for interesting biohacks here on Hackaday, and this new research article describing a calibrated pulse oximeter for different skin tones really caught our attention.
Pulse oximeters are handy little instruments that measure your blood oxygen saturation using photoplethysmography (PPG) and are a topic we’re no strangers to here at Hackaday. Given PPG is an optical technique, it stands to reason that its accuracy could be significantly affected by skin tone and that has been a major topic of discussion recently in the medical field. Given the noted issues with pulse oximeter accuracy, these researchers endeavored to create a better pulse oximeter by quantifying skin pigmentation and using that data to offset errors in the pulse oximeter measurements. A slick idea, but we think their results leave a lot to be desired.
Their idea sounds pretty straightforward enough. They created their own hardware to measure blood oxygen saturation, a smartwatch that includes red and infrared (IR) light-emitting diodes (LED) to illuminate the tissue just below the surface of the skin, and a photosensor for measuring the amount of light that reflects off the skin. But in addition to the standard pulse oximeter hardware, they also include a TCS34725 color sensor to quantify the user’s skin tone.
So what’s the issue? Well, the researchers mentioned calibrating their color sensor to a standard commercially-available dermatology instrument just to make sure their skin pigmentation values match a gold standard, but we can’t find that data, making it a bit hard to evaluate how accurate their color sensor actually is. That’s pretty crucial to their entire premise. And ultimately, their corrected blood oxygen values don’t really seem terribly promising either. For one individual, they reduced their error from 5.44% to 0.82% which seems great! But for another user, their error actually increases from 0.99% to 6.41%. Not so great. Is the problem in their color sensor calibration? Could be.
We know from personal experience that pulse oximeters are hard, so we applaud their efforts in tackling a major problem. Maybe the Hackaday community could help them out?
In the six months that have passed after the last USB-C article has been released, I have thought up a bunch of ways that these articles could have been improved. It’s, of course, normal to have such a feeling — expected, even. I now believe that there’s a few gaps that I could bridge. For instance, I have not provided enough example circuits, and sometimes one schematic can convey things better than a thousand words.
Let’s fix that! I’ll give you schematics for the kinds of USB-C devices you’re actually likely to want to build. I’ll also share a bunch of IC part numbers in this article, but I don’t have an exhaustive collection, of course – if you find more cool ICs that work for USB-C purposes and aren’t mentioned here, please do let us all know in the comments!
Continue reading “All About USB-C: Example Circuits”
So we’ll admit from the start that we’re not entirely sure how the average Hackaday reader can put this content to use. Still, these simulated patient monitor videos on YouTube gotta be useful for something. Right?
Uploaded by [themonitorsolution], each fourteen-minute 1080p video depicts what a patient monitor would look like in various situations, ranging from an adult in stable condition to individuals suffering from ailments such as COPD and sepsis. There’s even one for a dead patient, which makes for rather morbid watching.
Now we assume these are intended for educational purposes — throw them up on a display and have trainees attempt to diagnose what’s wrong with the virtual patient. But we’re sure clever folks like yourselves could figure out alternate uses for these realistic graphics. They could make for an impressive Halloween prop, or maybe they are just what you need to get that low-budget medical drama off the ground, finally.
Honestly, it seemed too cool of a resource not to point out. Besides, it’s exceedingly rare that we get to post a YouTube video that we can be confident none of our readers have seen before…at the time of this writing, the channel only has a single subscriber. Though with our luck, that person will end up being one of you lot.
Continue reading “What Can We Do With These Patient Monitor Videos?”