Intel RealSense D435 Depth Camera

RealSense No Longer Makes Sense For Intel

We love depth-sensing cameras and every neat hack they enabled, but this technological novelty has yet to break through to high volume commercial success. So it was sad but not surprising when CRN reported that Intel has decided to wind down their RealSense product line.

As of this writing, one of the better confirmations for this report can be found on the RealSense SDK GitHub repository README. The good news is that core depth-sensing RealSense products will continue business as usual for the foreseeable future, balanced by the bad news that some interesting offshoots (facial authentication, motion tracking) will be declared “End of Life” immediately and phased out over the next six months.

This information tells us while those living out on the bleeding edge will have to scramble, there is no immediate crisis for everyone else, whether they be researchers, hobbyists, or product planners. But this also means there will be no future RealSense cameras, kicking off many “What’s Next?” discussions in various communities. Like this thread on ROS (Robot Operating System) Discourse.

Three popular alternatives offer distinctly different tradeoffs. The “Been Around The Block” name is Occipital, with their more expensive Structure Pro sensor. The “Old Name, New Face” option is Microsoft Azure Kinect, the latest non-gaming-focused successor to the gaming peripheral that started it all. And let’s not forget OAK-D as the “New Kid On The Block” that started with a crowdfunding campaign and building an user community by doing things like holding contests. Each of these will appeal to a different niche, and we’ll keep our eye open in the future. Let’s see if any of them find the success that eluded the original Kinect, Google’s Tango, and now Intel’s RealSense.

[via Engadget]

flow IO module options

Get Your Flex On With The FlowIO Platform

Hackaday Prize 2021 entry FlowIO Platform promises to be to pneumatics what Arduino is to Electronics. The modular platform comprises a common controller/valve block, a selection of differently sized pumps, and a few optional connectivity and sensing blocks. With Arduino software support as well as as Javascript and web-GUI, there’s a way to program this no matter what the level of experience the user has.

flowIO exploded view
flowIO exploded view from http://www.softrobotics.io/flowio

This last point is a critical one for the mission [Ali Shtarbanov] from the MIT Media Lab is setting out for this project. He reminds us that in decades gone by, there was a significant barrier to entry for anyone building electronics prototypes. Information about how to get started was also much harder to by before the internet really got into gear.

It’s a similar story for software, with tools like Scratch and Python lowering the barrier to entry and allowing more people to get their toes wet and build some confidence.

But despite some earlier work by projects like the Soft Robotics Toolkit and Programmable-Air, making a start on lowering the bar for pneumatics support for soft robotics, and related applications, the project author still finds areas for further improvement. FlowIO was designed from the ground-up to be wearable. It appears to be much smaller, more portable and supports more air ports and a greater array of sensing and connectivity than previous Open Source work to date.

Creative Commons Hardware

Whilst you can take all the plans (free account signup required) and build yourself a FlowIO rig of your very own, the project author offers another solution. Following on from the Wikipedia model of free sharing and distribution of information, FlowIO offers its hardware for free, for the common good. Supported by donations to the project, more hardware is produced and distributed to those who need it. The only ask is that redundant kits are passed on or returned to base for upgrade, rather than landfill.

Continue reading “Get Your Flex On With The FlowIO Platform”

This Week In Security: Breaking Apple ID, Political Hacktivism, And Airtag Tracking

Have you ever thought about all the complexities of a Single Sign On (SSO) implementation? A lot of engineering effort has gone into hardened against cross-site attacks — you wouldn’t want every site you visit to be able to hijack your Google or Facebook account. At the same time, SSO is the useful ability to use your authentication on one service to authenticate with an unrelated site. Does SSO ever compromise that hardening? If mistakes are made, absolutely, as [Zemnmez] discovered while looking at the Apple ID SSO system.

Continue reading “This Week In Security: Breaking Apple ID, Political Hacktivism, And Airtag Tracking”

Thor does battle with a man shooting lasers from his hands

Of Lasers And Lightning: Thwarting Thor With Technology

Most of us don’t spend that much time thinking about lightning. Every now and then we hear some miraculous news story about the man who just survived his fourth lightning strike, but aside from that lightning probably doesn’t play that large a role in your day-to-day life. Unless, that is, you work in aerospace, radio, or a surprisingly long list of other industries that have to deal with its devastating effects.

Humans have been trying to protect things from lightning since the mid-1700s, when Ben Franklin conducted his fabled kite experiment. He created the first lightning rod, an iron pole with a brass tip. He had speculated that the conductor would draw the charge out of thunderclouds, and he was correct. Since then, there haven’t exactly been leaps and bounds in the field of lightning rod design. They are still, essentially, a metal rods that attract lightning strikes and shunt the energy safely into the earth. Just as Ben Franklin first did in the 1700s, they are still installed on buildings today to protect from lightning and do a fine job of it. While this works great for most structures, like your house for example, there are certain situations where a tall metal pole just won’t cut it.

Continue reading “Of Lasers And Lightning: Thwarting Thor With Technology”

Tesla Automatic Driving Under Scrutiny By US Regulators

The US National Highway Traffic Safety Administration (NHTSA) has opened a formal investigation about Tesla’s automatic driving features (PDF), claiming to have identified 11 accidents that are of concern. In particular, they are looking at the feature Tesla calls “Autopilot” or traffic-aware cruise control” while approaching stopped responder vehicles like fire trucks or ambulances. According to the statement from NHTSA, most of the cases were at night and also involved warning devices such as cones, flashing lights, or a sign with an arrow that, you would presume, would have made a human driver cautious.

Qote from Tesla support page: "The currently enabled Autopilot and Full Self-Driving features require active driver supervision and do not make the vehicle autonomous."There are no details about the severity of those accidents. In the events being studied, the NHTSA reports that vehicles using the traffic-aware cruise control “encountered first responder scenes and subsequently struck one or more vehicles involved with those scenes.”

Despite how they have marketed the features, Tesla will tell you that none of their vehicles are truly self-driving and that the driver must maintain control. That’s assuming a lot, even if you ignore the fact that some Tesla owners have gone to great lengths to bypass the need to have a driver in control. Tesla has promised full automation for driving and is testing that feature, but as of the time of writing the company still indicates active driver supervision is necessary when using existing “Full Self-Driving” features.

We’ve talked a lot about self-driving car safety in the past. We’ve also covered some of the more public accidents we’ve heard about. What do you think? Are self-driving cars as close to reality as they’d like you to believe? Let us know what you think in the comments.

This Week In Security: John Deere, ProxyLogin Detailed, And Pneumatic Tubes

We’ve covered the right-to-repair saga, and one of the companies that have become rather notorious is John Deere. The other side to the poorly managed interconnected mess is security issues. There’s a certain irony to how this story started: Somebody noticed that John Deere equipment didn’t have any CVEs at all. A normal person might think that this must mean their products are super secure, but a security researcher knows that something more interesting is afoot. Our old friends [Sick Codes], [John Jackson], and a host of others saw this as a sure sign that there were plenty of vulnerabilities to be found, and it seems they were correct.

Remote Access and Code from 2014…

Vulnerabilities included a handful of cross-site scripting attacks, an authentication bypass via request smuggling, misconfigured security, SQL injections, RCEs and more. Put together, these vulnerabilities allowed for full control of the John Deere system, including the ability to manipulate all the equipment connected to the system.

During the Defcon presentation, linked below, [Sick Codes] recalled the moment when they realized they were working on an important problem. Rather than complain about not getting paid for the vulnerabilities found, a contributor simply noted that he valued having food to eat. A coordinated attack on JD equipment could cause big problems for a bunch of farms across a country.

They ended up contacting CISA, due to a lack of serious response from the vendors. CISA took the threat seriously, and the problems starting getting fixed. This isn’t a problem limited to one company. Case had similar issues that have also been fixed, and it was implied that other vendors have similar problems that are still in the process of being addressed. Continue reading “This Week In Security: John Deere, ProxyLogin Detailed, And Pneumatic Tubes”

No Hole In One: Perseverance Strikes Out On First Mars Core Attempt

There’s a military adage that no plan survives first contact with the enemy. While we haven’t gone to war with Mars, at least not yet, it does seem to be a place where the best-laid scientific plans are tested in the extreme. And the apparent failure of Perseverance to retrieve its first Martian core sample is yet another example of just how hard it is to perform geotechnical operations on another planet.

To be sure, a lot about the first sampling operation went right, an especially notable feat in that the entire process is autonomous. And as we’ve previously detailed, the process is not simple, involving three separate robotic elements that have to coordinate their operations perfectly. Telemetry indicates that the percussive drill on the end of the 2.1 m robotic arm was able to use its hollow coring bit to drill into the rock of Jezero crater, and that the sample tube inside the coring bit was successfully twisted to break off the core sample.

But what was supposed to happen next — jamming of the small core sample inside the sample tube — appears not to have happened. This was assessed by handing the sample tube off to the Sample Handling Arm in the belly of Perseverance, where a small probe is used to see how much material was recovered — none, in this case. NASA/JPL engineers then began a search for the problem. Engineering cameras didn’t reveal the core sample on the Martian surface, meaning the sample handling robots didn’t drop it. The core sample wasn’t in the borehole either, which would have meant the camming mechanism designed to retain the core didn’t work. The borehole, though, looked suspicious — it appears not to be deep enough, as if the core sample crumbled to dust and packed into the bottom of the hole.

If this proves to be the cause of the failure, it will be yet another example of Martian regolith not behaving as expected. For InSight, this discovery was a death knell to a large part of its science program. Thankfully, Perseverance can pick up and move to better rock, which is exactly what it will be doing in September. They still have 42 unused sample tubes to go, so here’s to better luck next time.

[Featured images: NASA/JPL-Caltech]