3D printers now come in all shapes and sizes, and use a range of technologies to take a raw material and turn it into a solid object. We’re most familiar with Additive Manufacturing – where the object is created layer by layer. This approach is quite useful, but has a down side of being time consuming. Two professors at the University of Michigan have figured out a way to speed this process up, big time.
They start off with a VAT additive printing approach. These work by using an ultraviolet laser to harden or cure specific areas in a vat of resin, layer by layer, until the object is complete. The resin is then drained revealing your 3D printed object. Traditionally, VAT printing has been limited to small objects because the resin needs to have a relatively low viscosity.
The clever professors at U-M were able to get around this problem by adding a second laser that keeps the resin in a liquid state. By combining a curing laser with an ‘uncuring’ laser, they’re able to use resins that are more viscous, allowing them to print more durable parts. And do so about 100 times faster than traditional printers!
Thanks to [Baldpower] for the tip!
Anyone who’s ever written more than a dozen or so lines of code knows that debugging is a part of life in our world. Anyone who’s written code for microcontrollers knows that physical debugging is a part of our life as well. Atmel processors use a serial communications protocol called debugWire, which is a simpler version of JTAG and allows full read/write access to all registers and allows one to single step, break, etc. [Nerd Ralph], a prominent fixture here at Hackaday has dug into the AVR debugWire protocol and enlightened us with some valuable information.
While the protocol side of debugWire is a mostly-solved problem, the physical layer was giving him trouble. He started with a diode, and then went through a couple resistors and other components to interface with the debugWire pin on the AVR microcontroller, doing most of the troubleshooting work so now you don’t have to. He notes that interface components might need to be tailored to specific USB-TTL adapters, so keep that in mind if you care to delve into working with debugWire yourself.
We’re no strangers to debugging techniques here at Hackaday. As always, be sure to let us know if you run across any new techniques or try anything new yourself!
Designing a bi-pedal robot is a relatively straight forward task, given the array of tools that we now have at our disposal. There are many open source examples out there for anyone to get started. Designing one that doesn’t fall over a lot… well that’s not so simple. This is because when we walk our center of balance is constantly shifting, so during our adolescence we learn to shift our body weight around to maintain a stable center of balance. By the time we hit our mid-teens most of us have mastered the art of walking, and can maintain stability even through intense movements such as seen in many sports.
The question is of course, how does one convey this type of learning into a bi-pedal robot? It’s not easy to say the least. Take a look at what the robotics team over at Guangdong University of Technology’s School of Automation in China are doing. They’ve strapped a pair of ducted fan jet engines to the feet of a bi-pedal setup. What this does is allow the robot to maintain its center of balance over a large distance. Generally we see bi-pedal robots “tip toe over egg shells” because they need to keep the center of balance as stable as possible. By applying a thrusting force that comes out of the foot; they’re able to maintain center of gravity even though the robot is extended well beyond its normal range of motion.
Be sure to check out the video below for an excellent demonstration. Sometimes Hollywood does hackers a great service by giving us some inspiration!
Continue reading “Robot Uses Iron Man Tech to Walk”
How does one go about programming a drone to fly itself through the real world to a location without crashing into something? This is a tough problem, made even tougher if you’re pushing speeds higher and high. But any article with “MIT” implies the problems being engineered are not trivial.
The folks over at MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) have put their considerable skill set to work in tackling this problem. And what they’ve come up with is (not surprisingly) quite clever: they’re embracing uncertainty.
Why Is Autonomous Navigation So Hard?
Suppose we task ourselves with building a robot that can insert a key into the ignition switch of a motor vehicle and start the engine, and could do so in roughly the same time-frame that a human could do — let’s say 10 seconds. It may not be an easy robot to create, but we can all agree that it is very doable. With foreknowledge of the coordinate information of the vehicle’s ignition switch relative to our robotic arm, we can place the key in the switch with 100% accuracy. But what if we wanted our robot to succeed in any car with a standard ignition switch?
Now the location of the ignition switch will vary slightly (and not so slightly) for each model of car. That means we’re going to have to deal with this in real time and develop our coordinate system on the fly. This would not be too much of an issue if we could slow down a little. But keeping the process limited to 10 seconds is extremely difficult, perhaps impossible. At some point, the amount of environment information and computation becomes so large that the task becomes digitally unwieldy.
This problem is analogous to autonomous navigation. The environment is always changing, so we need sensors to constantly monitor the state of the drone and its immediate surroundings. If the obstacles become too great, it creates another problem that lies in computational abilities… there is just too much information to process. The only solution is to slow the drone down. NanoMap is a new modeling method that breaks the artificial speed limit normally imposed with on-the-fly environment mapping.
Continue reading “MIT Breaks Autonomous Drone Speed Limits By Not Sweating Obstacles”
“If I have seen further than others, it is by standing upon the shoulders of giants.” This famous quote by Isaac Newton points to an axiom that lies at the heart of The Sciences — knowledge precedes knowledge.
What we know today is entirely based upon what we learned in the past. This general pattern is echoed throughout recorded history by the revelation of one scientific mystery leading to other mysteries… other more compounding questions. In the vast majority of cases these mysteries and other questions are sprung from the source of an experiment with an unexpected outcome sparking the question: “why the hell did it do that?” This leads to more experiments which creates even more questions and next thing you know we go from moving around on horse-drawn carriages to landing drones on Mars in a few generations.
The observant of you will have noticed that I preceded a statement above with “the vast majority of cases.” Apart from particle physics, almost all scientific discovery throughout recorded history has been made via experiment and observation. There are a few, however, that have been discovered hidden within the confines of an equation, only later to be confirmed with observation. One such discovery is the Black Hole, and how it was stumbled upon on a dusty chalkboard in the early 1900s will be the focal point of today’s article.
Continue reading “Black Holes and the Elusive Mystery That Lies Within an Equation”
We’re not sure which is more fun – putting together a little RC truck with parts laying around on your workbench, or driving it around through a Linux terminal. We’ll take the easy road and say they’re both equally fun. [technodict] had some spare time on his hands and decided to build such a truck.
He started off with a great little chassis that can act as the base for many projects. Powering the four motors is a cheap little dual H bridge motor driver and a couple rechargeable batteries. But the neatest part of this build is that it’s controlled using a little bit of python and driven directly from a terminal, made possible by the Raspberry Pi Zero of course.
With Raspberry Pi Zero now having built in WiFi and Bluetooth – we should see a lot more projects popping up with one at its heart. Be sure to visit [technodict’s] blog for full source and details. And let us know how you could use that little chassis for your next mobile project!
The Raspberry Pi came upon us as an educational platform. A credit card sized computer capable of running Linux from a micro SD card, the Raspberry Pi has proven useful for far more than just education. It has made its way into every nook and cranny of the hacker world. There are some cases, however, where it might be a bit slow or seem a bit under powered. One way of speeding the Raspi up is to overclock it.
[Dmitry] has written up an excellent overclocking guide based upon Eltech’s write up on the subject. He takes it a bit further and applies the algorithm to both Raspi 2 and Raspi 3. You’ll need a beefier power supply, some heat sinks and fans – all stuff you probably have lying around on your workbench. Now there’s no excuse stopping you from ratcheting up the MHz and pushing your Pi to the limit!
We’ve seen several guides to overclocking the Raspi here on Hackaday, including the current record holder. Be sure to check out [dmitry’s] IO page for the overclocking details, and let us know of any new uses you’ve found by overclocking your Raspi in the comment below.