"Industrial Internet" entries

Drone on

UAVs will rule the skies (unless the FAA says otherwise).

Jeff Bezos’ recent demonstration of a drone aircraft simulating delivery of an Amazon parcel was more stunt than technological breakthrough. We aren’t there yet. Yes, such things may well come to pass, but there are obstacles aplenty to overcome — not so much engineering snags, but cultural and regulatory issues.

The first widely publicized application of modern drone aircraft — dropping Hellfire missiles on suspected terrorists — greatly skewed perceptions of the technology. On the one hand, the sophistication of such unmanned systems generated admiration from technophiles (and also average citizens who saw them as valuable adjuncts in the war against terrorism). On the other, the significant civilian casualties that were collateral to some strikes have engendered outrage. Further, the fear that drones could be used for domestic spying has ratcheted up our paranoia, particularly in the wake of Edward Snowden’s revelations of National Security Agency overreach. Read more…


The new bot on the block

How robotics are changing everything

Fukushima changed robotics. More precisely, it changed the way the Japanese view robotics. And given the historic preeminence of the Japanese in robotic technology, that shift is resonating through the entire sector.

Before the catastrophic earthquake and tsunami of 2011, the Japanese were focused on “companion” robots, says Rodney Brooks, a former Panasonic Professor of Robotics at MIT, the founder and former technical officer of IRobot, and the founder, chairman and CTO of Rethink Robotics. The goal, says Brooks, was making robots that were analogues of human beings — constructs that could engage with people on a meaningful, emotional level. Cuteness was emphasized: a cybernetic, if much smarter, equivalent of Hello Kitty, seemed the paradigm.

But the multiple core meltdown at the Fukushima Daiichi nuclear complex following the 2011 tsunami changed that focus abruptly.

Read more…

Comments: 5

Software, hardware, everywhere

Software and hardware are moving together, and the combined result is a new medium.

An updated version of this essay was published in December 2014.

Real and virtual are crashing together. On one side is hardware that acts like software: IP-addressable, controllable with JavaScript APIs, able to be stitched into loosely-coupled systems—the mashups of a new era. On the other is software that’s newly capable of dealing with the complex subtleties of the physical world—ingesting huge amounts of data, learning from it, and making decisions in real time.

The result is an entirely new medium that’s just beginning to emerge. We can see it in Ars Electronica Futurelab’s Spaxels, which use drones to render a three-dimensional pixel field; in Baxter, which layers emotive software onto an industrial robot so that anyone can operate it safely and efficiently; in OpenXC, which gives even hobbyist-level programmers access to the software in their cars; in SmartThings, which ties Web services to light switches.

The new medium is something broader than terms like “Internet of Things,” “Industrial Internet,” or “connected devices” suggest. It’s an entirely new discipline that’s being built by software developers, roboticists, manufacturers, hardware engineers, artists, and designers. Read more…

Comment: 1

The Myth of the Private API

The Fundamental Interconnectedness of Things

A little over a week ago, I wrote about how the authentication model for an unpublished Tesla REST API was architecturally flawed because it failed to take basic precautions against the sharing of credentials with third-parties common to most REST-based services these days. Since its publication, the main criticism of the article centered around the fact that the API is neither a published API nor has it been advertised as being meant for third-party consumption.

The adding of value to devices and services with or without the knowledge/permission of their creators is an integral part of the Internet of Things. These days, people expect an API around their devices. They will discover any APIs and add value to the device/service—even if the task requires a little reverse engineering work. A responsible creator of a device or service in today’s world defined by the Internet of Things must therefore do the following things—always:

  1. Give it a public API
  2. Protect any internal communications so they can’t be reverse engineered
  3. Protect any public communications so that they don’t put end users at risk when they leverage third-party devices and services

Read more…

Comments: 5

If This/Then That (IFTTT) and the Belkin WeMo

How I used an Internet service to automate home lighting without installing any software.

Like most good technologists, I am lazy.  In practice, this sometimes means that I will work quite hard with a computer to automate a task that, for all intents and purposes, just isn’t that hard.  In fits and starts for the past 10 years, I have been automating my house in various ways.  It makes my life easier when I am at home, though it does mean that friends who watch my house when I’m gone need to be briefed on how to use it.  If you are expecting to come into my house and use light switches and the TV as you do every place else, well, that’s why you need a personalized orientation to the house.

In this post, I’ll talk briefly about one of the most basic automation tasks I’ve carried out, which is about how the lights in my house are controlled.

The humble light switch was invented in the late 19th century, with the “modern” toggle switch following in the early 20th century.  The toggle switch has not changed in about 100 years because it does exactly what is needed and is well understood.  The only disadvantage to the toggle switch is that you have to touch it to operate it, and that means getting off the couch. Read more…

Comment: 1

Hot Swap Devices and Increase Arduino Interface Options with I2C

Don't be afraid of the bus

After a short period of time, beginners working with the Arduino development boards often find themselves wanting to work with a greater range of input or sensor devices—such as real-time clocks, temperature sensors, or digital potentiometers.

However each of these can often require connection by one of the two digital data buses, known as SPI and I2C. After searching around the Internet, inexperienced users may become confused about the bus type and how to send and receive data with them, then give up.

This is a shame as such interfaces are quite simple to use and can be easily understood with the right explanation. For example let’s consider the I2C bus. It’s a simple serial data link that allows a master device (such as the Arduino) to communicate with one or more slave devices (such as port expanders, temperature sensors, EEPROMs, real-time clocks, and more).
Read more…


The end of integrated systems

The programmable world will increasingly rely on machine-learning techniques that can interact with human interfaces

I always travel with a pair of binoculars and, to the puzzlement of my fellow airline passengers, spend part of every flight gazing through them at whatever happens to be below us: Midwestern towns, Pennsylvania strip mines, rural railroads that stretch across the Nevada desert. Over the last 175 years or so, industrialized America has been molded into a collection of human patterns–not just organic New England villages in haphazard layouts, but also the Colorado farm settlements surveyed in strict grids. A close look at the rectangular shapes below reveals minor variations, though. Every jog that a street takes is a testament to some compromise between mankind and our environment that results in a deviation from mathematical perfection. The world, and our interaction with it, can’t conform strictly to top-down ideals.

We’re about to enter a new era in which computers will interact aggressively with our physical environment. Part of the challenge in building the programmable world will be finding ways to make it interact gracefully with the world as it exists today. In what you might call the virtual Internet, human information has been squeezed into the formulations of computer scientists: rigid relational databases, glyphs drawn from UTF-8, information addressed through the Domain Name System. To participate in it, we converse in the language and structures of computers. The physical Internet will need to understand much more flexibly the vagaries of human behavior and the conventions of the built environment.
Read more…

Comments: 5

Interactive map: bike movements in New York City and Washington, D.C.

The cities appear to breathe as bicycles move into office districts in the morning and out in the evening.

From midnight to 7:30 A.M., New York is uncharacteristically quiet, its Citi Bikes — the city’s new shared bicycles — largely stationary and clustered in residential neighborhoods. Then things begin to move: commuters check out the bikes en masse in residential areas across Manhattan and, over the next two hours, relocate them to Midtown, the Flatiron district, SoHo, and Wall Street. There they remain concentrated, mostly used for local trips, until they start to move back outward around 5 P.M.

Washington, D.C.’s bike-share program exhibits a similar pattern, though, as you’d expect, the movement starts a little earlier in the morning. On my animated map, both cities look like they’re breathing — inhaling and then exhaling once over the course of 12 hours or so.

The map below shows availability at bike stations in New York City and the Washington, D.C. area across the course of the day. Read more…


Radar podcast: the Internet of Things, PRISM, and defense technology that goes civilian

A strange ad from a defense contractor leads us to talk about technology transfer, and Edward Snowden chooses an unnecessarily inflammatory refuge.

On this week’s podcast, Jim Stogdill, Roger Magoulas and I talk about things that have been on our minds lately: the NSA’s surveillance programs, what defense contractors will do with their technology as defense budgets dry up, and a Californian who isn’t doing what you think he’s doing with hydroponics.

The odd ad in The Economist that caught Jon's attention, from Dassault Systemes.

The odd ad in The Economist that caught Jon’s attention, from Dassault Systemes. Does this suggest that contractors, contemplating years of American and European austerity, are looking for ways to market defense technologies to the civilian world?

Because we’re friendly Web stewards, we provide links to the more obscure things that we talk about in our podcasts. Here they are.

If you enjoyed this podcast, be sure to subscribe on iTunes, on SoundCloud, or directly through our podcast RSS feed.

.powerpress_links {display:none;} .powerpress_player {display:none;}

Comments: 5

Burning the silos

The boundaries created by traditional management are just getting in the way of reducing product cycle times.

If I’ve seen any theme come up repeatedly over the past year, it’s getting product cycle times down. It’s not the sexiest or most interesting theme, but it’s everywhere: if it’s not on the front burner, it’s always simmering in the background.

Cutting product cycles to the bare minimum is one of the main themes of the Velocity Conference and the DevOps movement, where integration between developers and operations, along with practices like continuous deployment, allows web-native companies like Yahoo! to release upgrades to their web products many times a day. It’s no secret that many traditional enterprises are looking at this model, trying to determine what they can use or implement. Indeed, this is central to their long-term survival; companies as different from Facebook as GE and Ford are learning that they will need to become as agile and nimble as their web-native counterparts.

Integrating development and operations isn’t the only way to shorten product cycles. In his talk at Google IO, Braden Kowitz talked about shortening the design cycle: rather than build big, complete products that take a lot of time and money, start with something very simple and test it, then iterate quickly. This approach lets you generate and test lots of ideas, but be quick to throw away the ones that aren’t working. Rather than designing an Edsel, just to fail when the product is released, the shorter cycles that come from integrating product design with product development let you build iteratively, getting immediate feedback on what works and what doesn’t. To work like this, you need to break down the silos that separate engineers and designers; you need to integrate designers into the product team as early as possible, rather than at the last minute. Read more…

Comment: 1