I think it's unrealistic to build a cost-competitive open-source 2D printer. But it's relatively easy to just build your own printer. The parts that have the most R&D tied up in them (and so are unlikely to be replicated from scratch easily) are the inkjet heads and the ink's composition. If you can get those off the shelf then you can easily DIY everything else. There is a large existing industrial market for inkjet heads and ink. Many industrial inkjet heads are very easy to drive and have freely available data sheets. But they cost >$500 to a few $1k each and you probably want 4 for CMYK. I just built a custom printer in a few weeks for an art project with some of these (specifically, one called the Xaar128) driven by an RP2040. The experience definitely gave me a sense of awe and resigned respect for my humble desktop printer.
That's why I'm talking about a replacement motherboard for an existing consumer-grade printer (though not necessarily an inkjet one, I don't get it why people keep buying inkjet printers when they don't intend to print photos). Custom PCBs are very easy and cheap to get manufactured. All the maliciousness of these printers is in the firmware, and replacing the motherboard with an open-source one feels like the easiest way to get rid of that. The other possibility would be to write a custom firmware for the stock motherboard, but I'd imagine that printers these days would have some form of secure boot.
Also of interest is the paper, “A leaky integrate-and-fire computational model based on the connectome of the entire adult Drosophila brain reveals insights into sensorimotor processing”, which discusses the results of simulations of this dataset with the Brian2 spiking neural net simulator. They activate the same input neurons in the simulator and real flies and show that there is similar downstream behavior in the sim and real neural circuits.
It's very interesting to see an in-the-wild example of a security flaw in the wireless pairing of a class C medical device (i.e. a device that can severely injure or kill). Would love to see technical details about the specific flaw here.
It looks like it's implementing 802.15.4 (the basis for ZigBee among other protocols).
The user manual for the Contour Next Link 2.4 device (https://www.medtronicdiabetes.com/sites/default/files/librar...) shows that pairing can be initiated by the USB dongle and succeeds if the user confirms the request on the device. A serial number is displayed but that appears to be under the control of the hypothetical attacker. So the user must know to reject an unexpected request even if it has the right serial number, or the attacker will gain control of their pump and can issue a remote bolus command.
This example doesn't have to do with Bluetooth but there's an interesting connection there because most BLE pairing methods have been shown to be insecure to sniffing attacks. That imposes constraints on how medical devices that need Bluetooth connectivity are designed, because it may force a device to have a screen for showing a pairing code when it otherwise would not need one.
The FDA released a Draft of the new Cybersecurity Guidance document back in April and there was speculation that this draft was going to become active (an actual regulation) by the end of the year. I wonder if this news is going to speed that up in any way.
The new draft literally doesn't change anything. It just defines some of the things that FDA has been already asking for in the past 7 years for every device submission.
Just my opinion as someone who has worked on many infusion pumps; that FDA review division is the best at FDA. They probably ask more cybersecurity questions than any other group I've encountered.
> They probably ask more cybersecurity questions than any other group
And therein lies the problem. Ask lots of questions on paper, and you get something that is very secure on paper.
But if you want something actually secure, you need to do pentests, have a substantial bounty program, have the design+code inspected by security reviewers, etc.
That FDA review division does require that information and testing to be supplied with infusion pump testing. In fact, they are one of the few that routinely asks for substantial testing in repeated deficiency requests.
I would recommend starting with simulators! Industrial robot arms are expensive and the cheap arms designed for hobbyists aren't very useful because they lack payload capacity, reach, and degrees of freedom. But there are good simulators out there which let you build software or test applications with robot arms without having any real hardware. You can even have real-time physics-based interactions with the simulated world. It can feel like a video game.
My favorite for messing around is CoppeliaSim. It is relatively easy for beginners (you can just drag robots from the library into your sim scene and they will start doing things) but also powerful. It has a free education version but unfortunately it's commercial software. There's also Webots which "feels" similar but is open source. I found it a little harder to get going in but still very capable.
On the harder but more rewarding end of the scale there's the Robot Operating System (ROS) + Gazebo. ROS is used for many real robots both in academia (see the ETH Zurich work on ANYmal) and in industry (see Ghost Robotics). Gazebo is a simulator that is designed to work in ROS. You can build a control system on top of ROS and watch your virtual robot solve problems in Gazebo, and then you can flip the switch and run it with a real robot.
If you do decide to buy a robot arm I would recommend myCobot from Elephant Robotics. It's cheap (~$600), made of plastic, weak, etc. but has 6 degrees of freedom and enough capability to do real projects. If you play with something like that and get obsessed then I recommend taking a look at robots on eBay. Kind of counter-intuitively used giant heavy metal industrial robot arms are often cheaper (~$20k or less) than the "cobots" that are small and safe ($50k or more). That's because so many of the giant ones are out there in the world and are reaching the end of their normal lives. Sometimes owners are willing to pay to have them removed because it's such a hassle to deal with them. The big ones have to be bolted to the floor (after a structural engineer gives the ok on the dynamic loading on the building they're being put in) and you need industrial power. Also they often have archaic control systems running Windows (e.g. Kuka KRC) that have to be coaxed back to life with sparse information. If you go that route then the robot-forum site will be your lifeline.
On the development tool side I highly recommend finding a robot that already has ROS support. E.g. the ROS Industrial Kuka Experimental package for Kuka arms. The actual underlying interfaces/APIs (e.g. RSI or the fast research interface for Kuka arms) can be a massive pain to deal with. Newer robots are much nicer to deal with. There are a lot of cheap arms coming out of China that come with real-time ROS compatibility out of the box. Like the Z1 from Unitree, which I'm very excited about. Universal Robots bots are also well-supported in ROS and the underlying controller programming is relatively sane. You can find UR bots in many schools. Take a look at AATB for examples of that avenue.
Robots are hard and fun! I highly recommend giving the field a try. It's a great time for it.
Cut the data into the surface of a chunk of highly reflective and stable metal. Lob that into a high orbit. It will blink out your data from on high with nothing more than the incident light of the sun to anyone with a basic telescope, or even their naked eyes if it's big enough.
Obviously the details would be rather complicated. How is the data encoded? Morse code? Maybe ok for 500 years assuming the language it decodes to stays around. You could treat it like the messages we send to deep space and make it only pictograms. But that might take some effort if you are trying to bemoan the complexity of k8s for generations to come. That brings up the question of what are you trying to say? Do you already have something you think is worth saying across deep time? A person could spend their life solving that problem before they even get to the engineering challenges...
Well, any contemporary and well-understood encoding would work very well.
Perhaps the presence of such an object in the sky, visible to anyone, would automatically preserve knowledge of the encoding (people have always been interested in the stars). So if the encoding was US-ASCII in Cockney English, knowledge of cockney rhyming slang might well be conserved (at least among some "priesthoods") for hundreds or thousands of years.
$DEITY, I hope people don't start engraving their tweets on huge rolls of tinfoil, and having them unfurled by Bezos in upper orbit.
If someone were able to find a reliable source for the same band this work could turn into the nucleus of many wearable projects. It's hard for beginners to build electronics that are 1. small 2. comfortable 3. power efficient. These bands already take care of all of that.
There are many applications for this sort of platform. One could easily build a discreet pen testing tool which records information it sees about Bluetooth devices nearby. Or create an embedded engineering Swiss Army knife which exposes IO on your wrist to an app on your phone so you can jack into gadgets you find and poke around on the spot. Fun social applications to try too, like buying one of these for every attendee at your conference and building peer-to-peer applications on top.
Mapping out the programming interface is essential to enabling all that fun, but so is finding a reliable source for these devices.
One simple hack I can imagine is a text-to-morse transmitter. He's figured out how to vibrate the motor, if one can have an app that reads the phone's notification and talks over Bluetooth, one could convert it to morse so the user can receive his messages through vibrations in his wrist.
Although I suppose it would remain as a hack, if my I programmed this and bracelet starts vibrating the first thing I would do is pick up my phone to use my eyes instead of the morse code...
Power efficiency is mostly down to firmware, not the hardware itself. For example, using the synthesized low-frequency clock (like the article does) will increase current consumption tenfold.
The Pocketbone project by the same guy is also worth checking out. It's a small Beaglebone based on the Octavo 3358, which is a huge SoC that integrates all of the hard parts of a minimal Beaglebone-like system. That project (also in KiCAD) can serve as a jumping off point for any embedded project where you need a tiny Linux system with hard real time performance and easy integration with high speed peripherals (thanks to the weird and wonderful PRUs in the AM3358 Sitara processor). These sorts of projects are really valuable in the embedded world because they demo a minimal implementation and in doing so reduce the magic that bogs down newcomers who just want to do something cool.
I'd love to see something 3358-based with the Ethernet connected to a male RJ-45 - Just plug it into the switch and have an instant cluster.
Extra credit if you can have it with power over Ethernet. Double extra credit if the Ethernet, power and one USB are available on an edge connector so a backplane with a simple switch like the Microchip KSZ8997 could easily be built.
The octavo chip is a part of a much larger change going in the chip world: the rise of SIP integration, which greatly reduced The barriers and costs of integrating chip sized systems , thus opening the field for new innovations and actors.
One interesting result from this is the pic32mz-da chip , a mcu with Rich peripherals , 2D gpu and 32MB Of Dram, all for $7.5/10k , and I believe this is just the beginning.
So basically, a full computer, inc. possibility of Linux and high level languages and libraries, at a price of an mcu.
Working on a Bluetooth-enabled, 8 button, one-hand chording keyboard. It appears as a keyboard for typing and a wireless serial port for updating the mappings between chords and keys. Apps for Android and Windows make it easier to update the settings. I'm just planning to use it with my tablet (stuck onto the back) to make typing easier. I also love using it for EagleCAD shortcuts when making PCBs on my Surface (the pen input is nice enough when making pcbs to not opt for a laptop). Here's a picture of it: http://i.imgur.com/91nsGba.jpg
That's very cool. I think I would love to have something like that to go on to the back of a gamepad sort of deal. Working in VR is difficult when you have to change input devices. The gamepad is best for navigation, the keyboard is best for text input, the mouse is overall bad.
Thanks. I agree that handling multiple types of input in VR is difficult. That's actually the problem I wanted to solve with this project when I started it (details: https://hackaday.io/project/1321-keychange). But life intervened and the project scope shrunk.
I do some hardware hacking myself sometimes. Been meaning to sew this xbox controller joystick module onto a glove I've built that provides haptic feedback when sensed with the Leap Motion. Hit me up on my profile.
