So far, humans have had the edge in the ability to identify objects by touch. but not for long. Using Google’s Project Soli, a miniature radar that detects the subtlest of gesture inputs, the [St. Andrews Computer Human Interaction group (SACHI)] at the University of St. Andrews have developed a new platform, named RadarCat, that uses the chip to identify materials, as if by touch.
Realizing that different materials return unique radar signals to the chip, the [SACHI] team combined it with their recognition software and machine learning processes that enables RadarCat to identify a range of materials with accuracy in real time! It can also display additional information about the object, such as nutritional information in the case of food, or product information for consumer electronics. The video displays how RadarCat has already learned an impressive range of materials, and even specific body parts. Can Skynet be far behind?
Weary of manually entering manufacturing parameters into PCBShopper’s web form, [Jeremy Ruhland] created an awesome shortcut: His ULP script lets you obtain quotes from 26 PCB manufacturers around the world directly from your EAGLE board layout.
The script extracts all relevant data from your layout, including board size, the layer count, minimum trace widths and hole diameters. It then let’s you specify a few more in a tidy dialogue before sending you to the PCB manufacturing price comparison site PCBShopper.com with a custom query for board quotes.
Have a board layout..
..run [Jeremy’s] ULP script..
It works like a charm, and [Jeremy] also plans to add a shortcut button to the EAGLE layout editor’s toolbar. Since the script implements the entire PCBShopper API, for which [Jeremy] cooperates with PCBShopper.com owner [Bob Alexander], it’s also a great starting point for the development of scripts that work with other board layout tools.
Thanks to [Matthew Venn] for the title photo (via Flickr)!
We’re quite used to multitasking computer systems today. Our desktops run email, a couple of browsers in different workspaces, a word processor, and a few other applications, apparently all at once. Looking behind the scenes using a system monitor or task manager program reveals a multitude of other programs running in support of our activities. Of course, any given CPU is running a maximum of one program at a time. Multitasking is simply the practice of switching between active processes fast enough to give the illusion of simultaneity.
The roots of multiasking go way back. In the early days, when computers cost tons of money, the thought of an idle system was anathema. Teletype IO was slow compared to the processor, and leaving the processor waiting idle for a card reader to slurp in the next card was outrageous. The gurus of the time worked to fill that idle time with productive work. That eventually led to systems that would run multiple programs at one time, and eventually to more finely grained multitasking within a program.
Modern multitasking depends on support from the underlying API of an operating system. Each OS uses its own techniques, making it difficult to write portable code. The C++ 2011 standard increased the portability of the language by adding concurrency routines to the Standard Template Library (STL). These routines use the API of the OS. For instance, the Linux version uses the POSIX threading library, pthread. The result is a minimal, but useful, capability for building upon in later standards. The C++ 2017 standard development activities include work on parallelism and concurrency.
In this article, I’ll work through some of the facilities for and pitfalls in writing threaded code in C++.
Your quad-copter is hovering nicely 100 feet north of you, its camera pointed exactly on target. The hover is doing so well all the RC transmitter controls are in the neutral position. The wind picks up a bit and now the ‘copter is 110 feet north. You adjust its position with your control stick but as you do the wind dies and you overshoot the correction. Another gust pushed it away from target in more than one direction as frustration passes your lips: ARGGGHH!! You promise yourself to get a new flight computer with position hold capability.
How do multicopters with smart controllers hold their position? They use a technique called Proportional – Integral – Derivative (PID) control. It’s a concept found in control systems of just about everything imaginable. To use PID your copter needs sensors that measure the current position and movement.
The typical sensors used for position control are a GPS receiver and an Inertial Management Measurement Unit (IMU) made up of an accelerometer, a gyroscope, and possibly a magnetometer (compass). Altitude control would require a barometer or some other means of measuring height above ground. Using sensor fusion techniques to combine the raw data, a computer can determine the position, movement, and altitude of the multicopter. But calculating corrections that will be just right, without over or undershooting the goal, is where PID comes into play. Continue reading “Flying with Proportional – Integral – Derivative Control”→
Programmatic CAD, in particular the OpenSCAD language and IDE, has accompanied the maker movement for a while now. After its introduction in 2009, it quickly found its way into the 3D printing toolbox of many makers and eventually became what could be called an Industry Standard among open hardware labs, makerspaces and tinkerers. The Prusa i3, one of the most popular DIY 3D printers, was designed in OpenSCAD, and even Makerbot, the company that sold 100.000 3D printers, uses the language for its “Customizer” – an online tool that allows users to customize 3D printable models with minimal effort.
OpenSCAD is indeed a wonderful tool, and we have been using it a lot. We have become used to its quirks and accepted working with polygon mesh approximations of the models we are trying to design. We have made our peace with excessive rendering times, scripting workarounds and the pain of creating fillets, and we have learned to keep our aesthetic expectations low. We are happy with the fact that there is a way to programmatically create and share virtually any object, but sometimes we wish there was a better way in the open source world. Hint: there is.
Our Hackaday Chief [Mike] sent me an e-mail the other day with a link to the Belgrade Hackaday Badge simulator. He clearly wanted me to enter something into the demo scene competition. The good news is that because of the simulator, you didn’t have to leave your desk to participate. The bad news is that I had very little time left at the end of the month, so I wanted to do something appealing but it had to be fairly easy to roll out. I wound up doing a very quick project but it had a few fine points that I thought I’d share. The end goal was to have an interesting display of Conway’s game of life on the badge.
By the way, there was a completely different project with the same goal by [Jeremias] on Hackaday.io. As far as I know, this was just the result of two people setting out to do the same thing. You’ll see the user interface is a good bit different, so you might see which you prefer.
If you haven’t seen it, the real badge is below. The emulator, of course, just runs as a window on your PC. For those that will be at the conference, or just want to program closer to the actual hardware, there is now a preconfigured MPLABX framework for the PIC18LF25K50 and the bootloader/kernel running on this badge.
Let’s face it: 3-dimensional odometry can be a computationally expensive problem often requiring expensive 3D cameras and optimized algorithms that can be difficult to wrap our head around. Nevertheless, researchers continue to push the bounds of visual odometry forward each year. This past year was no exception, as [Christian], [Matia], and [Davide] have tipped the scale in terms of speed with an algorithm that can track itself in 3D in real time.
In the video (after the break), the landmarks are sparse, the motion to track is relentlessly jagged, but SVO, or Semi-Fast Visual Odometry [PDF warning], keeps tracking its precision with remarkable consistency, making use of “high frequency texture” as a reference. Several other implementations require two cameras or a depth camera variant, but not SVO. It uses a single camera with a high frame rate between 55 and 300 frames per second. Best of all, the trio at the University of Zürich have made their codebase open source and available as a package for ROS.