Raspberry Pi

1327 Articles

Had too much self-quarantine? [Sharathnaik] had, so he decided to build a robot companion named Ewon. Using a Raspberry Pi, Ewon isn’t a robot that moves around, but rather an expressive Google assistant. Using some servo-driven ears and a display, Ewon reacts to you based on keywords you use in your queries. For example, it might perk up and smile at the mention of ice cream. Or look unhappy if you mention sadness.

The project is simple because of the Google Assistant API. However, we liked the 3D printed body and some of the additional features the robot adds.

Historically, booting a Raspberry Pi required an SD card. However, if you follow [tynick’s] instructions, you can get a Pi 4 to boot from the USB port. Combine it with a small solid state disk drive, and you’ll get great performance, according to his post.

The caveat is this depends on a beta bootloader and, of course, you’ll still have to boot from an SD card at least once to load that bootloader. If you were deploying something serious, you’d probably want to make sure the bootloader is suitable for your needs.

Linux is a two-edged sword. On the one hand, there’s so much you can configure. On the other hand, there’s so much you can configure. It is sometimes hard to know just what you should do to get the best performance, especially on a small platform like the Raspberry Pi. [Hayden James] has a suggestion: enable ZRAM and tweak the kernel to match.

Although the post focuses on the Raspberry Pi 4, it applies to any Linux system that has limited memory including older Pi boards. The idea is to use a portion of main memory as a swap file. At first, that might seem like a waste since you could use that memory to, you know, actually run programs. However, the swap devices are compressed, so you get more swap space and transfers from these compressed swap devices and main memory are lightning-fast compared to a hard drive or solid state disk drive.

[Harrison] has been busy finding the sweeter side of quarantine by building a voice-controlled, face-tracking M&M launcher. Not only does this carefully-designed candy launcher have control over the angle, direction, and velocity of its ammunition, it also locates and locks on to targets by itself.

Here comes the science: [Harrison] tricked Alexa into thinking the Raspberry Pi inside the machine is a smart TV named [Chocolate]. He just tells an Echo to increase the volume by however many candy-colored projectiles he wants launched at his face. Simply knowing the secret language isn’t enough, though. Thanks to a little face-based security, you pretty much have to be [Harrison] or his doppelgänger to get any candy.

The Pi takes a picture, looks for faces, and rotates the turret base in that direction using three servos driven by Arduino Nanos. Then the Pi does facial landmark detection to find the target’s mouth hole before calculating the perfect parabola and firing. As [Harrison] notes in the excellent build video below, this machine uses a flywheel driven by a DC motor instead of being spring-loaded. M&Ms travel a short distance from the chute and hit a flexible, spinning disc that flings them like a pitching machine.

As open as the Raspberry Pi Foundation has been about their beloved products, they would be the first to admit there’s always more work to be done: Getting a Pi up and running still requires many closed proprietary components. But the foundation works to chip away at it bit by bit, and one of the latest steps is the release of a camera stack built on libcamera.

Most Linux applications interact with the camera via V4L2 or a similar API. These established interfaces were designed back when camera control was limited and consisted of a few simple hardware settings. Today we have far more sophisticated computational techniques for digital photography and video. Algorithms have outgrown dedicated hardware, transforming into software modules that take advantage of CPU and/or GPU processing. In practice, this trend meant bigger and bigger opaque monolithic pieces of proprietary code. Every one a mix of “secret sauce” algorithms commingling with common overhead code wastefully duplicated for each new blob.

We expect camera makers will continue to devise proprietary specialties as they seek a competitive advantage. Fortunately, some of them see benefit in an open-source framework to help break up those monoliths into more manageable pieces, letting them focus on just their own specialized parts. Leveraging something like libcamera for the remainder can reduce their software development workload, leading to faster time to market, lower support cost, and associated benefits to the bottom line that motivates adoption by corporations.

But like every new interface design borne of a grandiose vision, there’s a chicken-and-egg problem. Application developers won’t consume it if there’s no hardware, and hardware manufacturers won’t implement it if no applications use it. For the consumer side, libcamera has modules to interop with V4L2 and other popular interfaces. For the hardware side, it would be useful to have a company with wide reach who believes it is useful to open what they can and isolate the pieces they can’t. This is where the Raspberry Pi foundation found a fit.

The initial release doesn’t support their new High-Quality Camera Module though that is promised soon. In the short term, there is still a lot of work to be done, but we are excited about the long term possibilities. If libcamera can indeed lower the barrier to entry, it would encourage innovation and expanding the set of cameras beyond the officially supported list. We certainly have no shortage of offbeat camera sensor ideas around here, from a 1-kilopixel camera sensor to a decapped DRAM chip.

We know a lot of you are sitting on an unused Raspberry Pi Zero W, maybe even several of them. The things are just too small and cheap not to buy in bulk when the opportunity presents itself. Unfortunately, the Zero isn’t exactly a powerhouse, and it can sometimes be tricky to find an application that really fits the hardware.

Which is why this tip from [Tejas Lotlikar] is worth taking a look at. Using the Pi Zero W, a cheap USB WiFi adapter, and some software trickery, you can put together a cheap extender for your wireless network. The Pi should even have a few cycles left over to run ad-blocking software like Pi-hole while it shuffles your packets around the tubes.

[Tejas] explains every step of the process, from putting the Raspbian image onto an SD card to convincing wpa_supplicant to put the Pi’s WiFi radio into Access Point mode. Incidentally, this means that you don’t need to be very selective about the make and model of the USB wireless adapter. Something with an external antenna is preferable since it will be able to pull in the weak source signal, but you don’t have to worry about it supporting Soft AP.

With the software configured, all you need to finish this project off is an enclosure. A custom 3D printed case large enough to hold both the Pi and the external WiFi adapter would be a nice touch.

We’ve seen a lot of practical machines built using Lego. Why not? The bricks are cheap and plentiful, so if they can get the job done, who cares if they look like a child’s toy? Apparently, not [Yuksel Temiz]. He’s an engineer for IBM whose job involves taking pictures of microscopic fluidic circuits. When he wasn’t satisfied with the high-power $10,000 microscopes he had, he built his own. Using Lego. How are the pictures? Good enough to appear in many scientific journals.

Clearly, the microscope doesn’t just contain Lego, but it still came in at under $300. According to an interview from Futurism, the target devices are reflective which makes photographing them straight-on difficult. After experimenting with cameras on tripods, [Yuksel] decided he could build his own specialized device. You can see a video of the devices in question and some of the photographs below.