Telepresence is one of those futuristic buzzwords that’s popped up a few times over the decades; promising the ability to attend a meeting in New York City and another in Tokyo an hour later, all without having to leave the comfort of your home or office. This is the premise of Double Robotics’ Double 3, its most recent entry in this market segment, as the commercial counterpoint to more DIY offerings.
Looking like a tablet perched on top of a Segway, the built-in dual 13 megapixel cameras allow the controller to get a good look at their surroundings, while the 6 beamforming microphones should theoretically allow one to pick up any conversation in a meeting or on the work floor.
Battery life is limited to 4 hours, and it takes 2 hours to recharge the built-in battery. Fortunately one can just hop over to another, freshly charged Double 3 if the battery runs out. Assuming the $3,999 price tag doesn’t get in the way of building up a fleet of them, anyway.
Probably the most interesting aspect of the product is its self-driving feature, which has resulted in a whole range of sensors and cameras (Intel RealSense D430 stereo vision depth sensors) being installed. To handle the processing of this sensor data, the system is equipped with an NVidia Jetson TX2 ARM board, running Ubuntu Linux, which also renders the mixed-reality UI for the user with way points and other information.
Currently Double Robotics accepts sign-ups for the private beta of the Double 3 API, which would give developers access to the sensor data and various autonomous features of Double 3’s hardware. Co-founder of Double Robotics, [Marc DeVidts] stated to Hackaday that he is looking forward to seeing what people can build with it. Hopefully this time people will not simply take the thing for a joyride, like what happened with a predecessor of the Double 3.
Racing games have come a long way over the years. From basic 2D sprite-based titles, they’ve evolved to incorporate advanced engines with highly realistic simulated physics that can even be used to help develop real-world automobiles. For [Surrogate.tv], that still wasn’t quite good enough, so they decided to create something more rooted in reality.
Their project resulted in a racing game based on controlling real RC cars over the internet, in live races against other human opponents. Starting with a series of Siku 1:43 scale RC cars, the team had to overcome a series of engineering challenges to make this a reality. For one, the original electronics had to be gutted as the team had issues when running many cars at the same time.
Instead, the cars were fitted with ESP8266s running custom firmware. An overhead GoPro is used with special low-latency streaming software to allow players to guide their car to victory. A computer vision system is used for lap timing, and there’s even automatic charging stations to help keep the cars juiced up for hours of play.
In a recent article in Nature, you can find the details of a RISC-V CPU built using carbon nanotubes. Of course, Nature is a pricey proposition, but you can probably find the paper by its DOI number if you bother to look for it. The researchers point out that silicon transistors are rapidly reaching a point of diminishing returns. However, Carbon Nanotube Field Effect Transistors (CNFETs) overcome many of these disadvantages.
The disadvantage is that the fabrication of CNFETs has been somewhat elusive. The tubes tend to clump and yields are low. The paper describes a method that allowed the fabrication of a CPU with over 14,000 transistors. A wafer gets nanotubes grown all over it and then some of them are removed. In addition, some design rules mitigate other problems.
In particular, a small percentage of the CNFETs will become metallic and have little to no bandgap. However, the DREAM design rules can increase the tolerance of the design to metallic CNFETs with no process changes.
Before you get too excited, limitations in channel length and contact size keep the processor running at a blazing 10 kHz. To paraphrase Weird Al, your operating system boots in a day and a half. The density isn’t great either since working around stray and metallic CNFETs means each transistor has multiple nanotubes in use.
On the other hand, it works. New technology doesn’t always match old technology at first, but you have to crawl before you walk, and walk before you run.
We imagine you won’t be able to buy this for $8 any time soon even if you wanted to. At 10 kHz, it probably isn’t going to make much of a desktop PC anyway.
It’s a staple of our community’s work, to make electronic devices do things their manufacturers never intended for them. Analogue synthesisers using CMOS logic chips for example, or microcontrollers that bitbang Ethernet packets without MAC hardware. One of the most fascinating corners of this field comes in the form of software defined radios (SDRs), with few of us not owning an RTL2832-based digital TV receiver repurposed as an SDR receiver.
The RTL SDR is not the only such example though, for there is an entire class of cable modem chipsets that contain the essential SDR building blocks. The Hermes-Lite is an HF amateur radio transceiver project that uses an AD9866 cable modem chip as the signal end for its 12-bit SDR transceiver hardware with an FPGA between it and an Ethernet interface. It covers frequencies from 0 to 38.4 MHz, has 384 kHz of bandwidth, and can muster up 5W of output power.
It’s a project that’s been on our radar for the past few years, though somewhat surprisingly this is the first mention of it here on Hackaday. Creator [Steve Haynal] has reminded us that version 2 is now a mature project on its 9th iteration, and says that over 100 “Hermes-Lite 2.0” units have been assembled to date. If you’d like a Hermes-Lite of your own it’s entirely open-source, and they organise group buys of the required components.
Python is a versatile, powerful language but sometimes it’s not the best choice, especially if you’re doing work in embedded systems with limited memory. Sometimes you can get away with MicroPython for these cases, but the best language is likely C or assembly. If you’re really stubborn, like [amirgon], and really want C and Python to play well together, you can make use of his new tool which can bring any C library to MicroPython.
As an example of how this tool is used, a “Pure MicroPython” display driver for ILI9341 on the ESP32, which means that everything was implemented in MicroPython. [amirgon] wanted to see how the Python driver would compare to one that’s already been written in C, and use it to showcase MicroPython binding. This tool also automatically converts structs, unions, enums and arrays to Python objects, and provides a means to work with pointers which is something that Python doesn’t handle in the same way that C requires.
[amirgon] hopes that this tool will encourage the adoption of Micropython by removing the obstacle of missing APIs and libraries in MicroPython. Since most libraries for systems like these are written in C, a way to implement them in Python is certainly powerful. We featured one use case for this a while back, but this is a much more generic fix for this coding obstacle.
Olive oil at its finest quality is a product that brings alive the Mediterranean cuisine of which it is a staple. Unfortunately for many of us not fortunate enough to possess our own olive grove, commercial olive oils are frequently adulterated, diluted with cheaper oils such as canola. As consumers we have no way of knowing this, other than the taste being a bit less pronounced. Food standards agencies use spectrophotometers to check the purity of oils, and [Daniel James Evans] has created such a device using a Raspberry Pi.
A spectrophotometer shines white light through a sample to be tested, splits the light up into a spectrum with a prism or diffraction grating, and measures the light level at each point in the spectrum to gain a spectral profile of the sample. Different samples can then be compared by overlaying their profiles and looking at any differences. This build shines the light from an LED through a sample of oil, splits the result with a diffraction grating, and captures the spectrum with a Raspberry Pi camera. Commercial instruments are usually calibrated by co-incidentally sampling a pure sample of the same solvent the test subject is dissolved in, in this case the calibration is done against a sample of pure olive oil. The software requires the user to identify the spectrum in the resulting photograph, before generating a curve.
From a basis of having worked with and maintained spectrophotometers in the distant past we would have expected to see an incandescent bulb rather than an LED for a flatter response, but since this is an oil identifier rather than a finely calibrated laboratory instrument this is probably less of an issue.
Military headphones, at least the older ones, are like few other sound reproducers. They are an expression of function over form, with an emphasis on robustness over operator comfort. Electrically they most often have high-impedance drivers and annoyingly proprietary connectors for whichever obscure radio system they were a part of.
[John Floren] has a HS-16A headset, the type used by the US military during the Vietnam war. It’s an antiquated design with a dual spring steel headband and on-the-ear ‘phones with no muff for comfort, and a quick bit of research finds that they can be had brand new in their 1960s packaging for somewhere around $20. Their connector is a pair of odd metal pins, and rather than doing what most of us would do and snipping the wire to fit something more useful, he hunted high and low for a TE Connectivity receptacle that would fit them. A short extension and a jack plug allowed him to use these slightly unusual cans.
This isn’t a special hack, but it’s still an interesting read because it sheds a bit of light upon these old-style headphones and reveals that they’re still available for anyone who wants their radio operating to have a retro feel. If you buy a set, you’ll probably still have them decades after more modern pairs have bitten the dust.