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.
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.
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...
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.
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.
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.
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
