Autonomous Delivery: Your Impulse Buys Will Still Be Safe

I heard a “Year in Review” program the other day on NPR with a BBC World Service panel discussion of what’s ahead for 2017. One prediction was that UAV delivery of packages would be commonplace this year, and as proof the commentator reported that Amazon had already had a successful test in the UK. But he expressed skepticism that it would ever be possible in the USA, where he said that “the first drone that goes over somebody’s property will be shot down and the goods will be taken.”

He seemed quite sincere about his comment, but we’ll give him the benefit of the doubt that he was only joking to make a point, not actually grotesquely ignorant about the limitations of firearms or being snarky about gun owners in the US. Either way, he brings up a good point: when autonomous parcel delivery is commonplace, who will make sure goods get to the intended recipient?

Based on the Beeb’s quip and the tone of discussion in the comments of my earlier post on autonomous deliveries, it seems like the main concern is that without humans in the delivery chain, packages will be subject to pilferage. The thought apparently is that fleets of robo-trucks laden with goods or a drone with packages on board are easier pickings for criminals when there’s no human in the loop.

automatedfreightReally? With humans doing the driving, an estimated $30 billion is lost in the US alone to cargo theft every year. Can robots be much worse?

If you dive into the statistics on cargo freight, the first thing you notice is wildly differing tallies for the losses. This appears somewhat due to reporting methodologies — when a driver has a gun stuck in his face, it’s a strong-arm robbery; when a dock worker takes an envelope of cash to take a long break while a shipment gets loaded into the wrong truck, that’s more of a fraud case. And with multiple billions of dollars in “sales” every year, cargo theft is more of an organized enterprise than an entrepreneurial one – think MS-13, the Triad, and La Cosa Nostra. That results in a strong tendency for shipping companies to under-report cargo theft, perhaps reflecting the peculiar human desire to not end up very dead for squealing. Robots don’t care so much about getting kneecapped.

As more and more of the supply chain is automated, fewer humans will be in proximity to all that potential booty, which can only be a good thing. Humans are far more corruptible than robots, which will not be tempted to bolster a low-wage paycheck or settle a score with a manager by nicking a package off the conveyor. True, a robotic package handling system could be programmed to divert a shipment into a suspiciously plain white truck, but that would still be a human crime, at least until we have AI in the supply chain.

But all this theft from the early part of the supply chain is probably less what the BBC commentator or the Hackaday community is concerned with. It’s a little too far up the chain, and impacts us only insofar as it drives up prices as manufacturers seek to recoup their losses. For us, what really matters is the final handful of miles between the shipper’s depot and our front door. How will autonomous delivery impact that?

Again, I have to think that the robots will do better. And this is coming from someone whose usual UPS guy is a rock star — dude literally sprints from the truck to my door, puts the package down gently, knocks and rings the doorbell, and is one of the friendliest people you’ll ever meet. Still, if someone stuck a gun in his face and told him to get out of the truck, he’d go. He’s not about to lay down his life to protect a bunch of packages that UPS is insured for anyway. “Here’s the keys. Have a nice day!”

It’s an extreme example to make a point: humans do little to protect your package during that “out for delivery” phase, and with human fallibility are more likely to increase the risk of theft. A human UPS or FedEx driver might forget to lock the truck while heading up your walk with a package, for example. A robot won’t. And if someone did try to hold up or hijack an autonomous delivery vehicle, I’d think it would be far more likely that the robotic driver would follow an effective emergency procedure — lock the doors, call into dispatch, notify law enforcement — than the poor guy or gal that is suddenly thrown into a high-stress situation and can’t remember the number for 911.

And what about that very last phase of delivery, where your package is on the doorstep waiting for you to come home from work? Again, I think automated delivery offers a lot of advantages here. We already have smart parcel boxes (there are a few in the market like Pelipod shown below) that work with carbon-based delivery drivers, and having them talk to the delivery vehicle wouldn’t be much of a trick.

Bottom line: nothing will stop someone from getting your stuff if they want it and they have an opportunity to take it, or can create an opportunity through the use of force. But it seems clear to me that when fleets of autonomous FedEx trucks are plying our neighborhoods, or Amazon drones darken the sky with same-day delivery of our goodies, we’ll probably have less to worry about. It won’t stop the thieves from trying, but it will give them fewer openings with the humans out of the loop.


Filed under: Featured, Interest, Original Art, rants

Raspberry Pi Launches Compute Module 3

The forgotten child of the Raspberry Pi family finally has an update. The Raspberry Pi Compute Module 3 has been launched.

The Pi 3 Compute Module was teased all the way back in July, and what we knew then is just about what we know now. The new Compute Module is based on the BCM2837 processor – the same as found in the Raspberry Pi 3 – running at 1.2 GHz with 1 gigabyte of RAM. The basic form factor SODIMM form factor remains the same between the old and new Compute Modules, although the new version is 1 mm taller.

The Compute Module 3 comes with four gigabytes of eMMC Flash and sells for $30 on element14 and RS Components. There’s also a cost-reduced version called the Compute Module 3 Light that forgoes the eMMC Flash and instead breaks out those pins to the connector, allowing platform integrators to put an SD card or Flash chip on a daughter (mother?) board. The CM3 Lite version sells for $25.

The Compute Module was always the black sheep of the Raspberry Pi family, although it did find a few applications in its desired use case. The Raspberry Pi Foundation heralded NEC’s announcement of a line of large-format displays using the Compute Module recently. The OTTO, from Next Thing Co., makers of the C.H.I.P. single board computer, also had a Pi Compute Module shoved in its brain. Whether or not companies will choose the Compute Module 3 as a platform remains up in the air, but the value proposition is there; the Pi 3 is a vastly superior computational platform compared to the Pi 1. Putting this power on an easy-to-use module will make for some very interesting products.

If you’re looking for a really cool project for the Compute Module 3, I would suggest a cluster of Pis. The problem with a cluster of Compute Modules is that nearly all SODIMM sockets are horizontal, and for maximum efficiency, you’ll want a vertical header. The good news is vertical SODIMM headers do exist, and you can buy 20% of the world’s supply of these headers for about $500. I know because I did.


Filed under: news, Raspberry Pi

A Simple Route To A Plug Top Pi

There are a host of tiny plug-top computers available for the experimenter who requires an all-in-one mains-powered computing platform without the annoyance of a full-sized PC or similar. But among the various models there has always been something missing, a plug-top Raspberry Pi. To address that gap in the market, [N-O-D-E] has created a fusion of Pi and plug using the official Raspberry Pi PSU accessory and a Raspberry Pi Zero, with a UUGear Zero4U USB hub sandwiched between the two.

It’s a pretty straightforward and simple build, the back of the PSU is formed into a flat surface with a bit of Sugru, then the power cable is stripped back to its wires which are then connected to the power pins on the USB hub. The hub is then attached to the Sugru — he doesn’t say how, but we suspect double-sided tape — and the Pi is mounted on top of the hub. Pogo pins make the required connections to the pads on the underside of the computer, so it can be removed and replaced at will.

The result is a useful addition to your Pi arsenal, one that could be used for a host of little stand-alone devices. It could use a cover, however we suspect a 3D printer owner could create themselves one with relative ease. The full description is shown in the video below the break.

Fitting Raspberry Pis into small spaces is a favorite theme, we’ve had a Zero in a projector and another in a USB stick. Perhaps it’s the miniature Pi 2 laptop that takes the prize though.


Filed under: Raspberry Pi

ESP32 (6) – How to connect to a wifi network

In this post I’m going to show you how to connect to a wifi network.

The esp-idf framework includes a wifi driver that manages the wifi interface of the esp32 chip. The driver exposes API calls the programmer can use to interact with it; you’ve already used some of those APIs in my previous tutorial:

ESP_ERROR_CHECK(esp_wifi_init(&wifi_config));
ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA));
ESP_ERROR_CHECK(esp_wifi_start());

The driver is executed in parallel with the main program and communicates with it using events:

esp32-wifi02

In the main program you have to define a function that will be the event handler, i.e. a function called by the wifi driver every time it has to notify a new event:

static esp_err_t event_handler(void *ctx, system_event_t *event)
{...}

then you have to tell the framework the name of your function:

ESP_ERROR_CHECK(esp_event_loop_init(event_handler, NULL));

The list of the events the framework may generate is included in the esp_event.h file. The events related to the wifi driver when working in station mode have SYSTEM_EVENT_STA as name prefix:

esp32-wifi03

The connection to a wifi network follows this flow diagram:

esp32-wifi04

  • the main program configures and starts the driver via API calls
  • after having completed its internal tasks, the driver notifies that it has successfully started triggering the event SYSTEM_EVENT_STA_START
  • the event handler, once received that event, can call the esp_wifi_connect() API to ask the driver to connect to the network specified during the configuration phase
  • when the connection is completed and after having obtained a valid IP address (if the DHCP service is used), the driver triggers the event SYSTEM_EVENT_STA_GOT_IP
  • now the event handler can inform the main program that the connection has been completed

Tasks synchronization

In the process described above, the main program waits for the connection to be completed before executing its own instructions. It’s therefore important to understand how to synchronize the different elements: the main program, the event handler and the wifi driver. FreeRTOS offers different ways to make the tasks communicate: one of the simplest is via events. Events, in FreeRTOS, are managed using event groups and event bits.

Event bits are similar to flags,  visible to the different tasks:

  • the programmer can create as many event bits as he needs
  • tasks can activate (set) o deactivate (clear) the different bits
  • a task can pause its execution waiting for one of more bits to be set

Event bits are grouped into event groups, each of them usually contains 8 event bits. Event bits in an event group are numbered depending on their “position” (BIT0, BIT1…):

esp32-wifi05

The program

The complete program is available in my Github repository. Let’s review the main sections:

static EventGroupHandle_t wifi_event_group;
const int CONNECTED_BIT = BIT0;
[...]
wifi_event_group = xEventGroupCreate();

The program defines an event group (wifi_event_group) and an event bit (CONNECTED_BIT). In the app_main() the event group is created using the FreeRTOS xEventGroupCreate() method.

#define WIFI_SSID "MYSSID"
#define WIFI_PASS "MYPASSWORD"
[...]
wifi_config_t wifi_config = {
  .sta = {
    .ssid = WIFI_SSID,
    .password = WIFI_PASS,
  },
};
ESP_ERROR_CHECK(esp_wifi_set_config(ESP_IF_WIFI_STA, &wifi_config));

The configuration of the wifi network starts with the definition of two constants: the SSID name and the password (WIFI_SSID e WIFI_PASS). The constants are then used to initialize the wifi_config struct; struct which is then passed as parameter to the esp_wifi_set_config method.

static esp_err_t event_handler(void *ctx, system_event_t *event)
{
switch(event->event_id) {
 
  case SYSTEM_EVENT_STA_START:
    esp_wifi_connect();
    break;
  case SYSTEM_EVENT_STA_GOT_IP:
    xEventGroupSetBits(wifi_event_group, CONNECTED_BIT);
    break;  
  case SYSTEM_EVENT_STA_DISCONNECTED:
    xEventGroupClearBits(wifi_event_group, CONNECTED_BIT);
    break;

The event handler manages the different events triggered by the wifi driver as explained above. In particular, once the connection is established (STA_GOT_IP event), sets the CONNECTED_BIT event bit. On the contrary, in case of disconnection it clears the same event bit.

xEventGroupWaitBits(wifi_event_group, CONNECTED_BIT, false, true, portMAX_DELAY);

The main task pauses its execution until the connection to the wifi network is perfomed, waiting for the CONNECTED_BIT bit to be set. The portMAX_DELAY constant will cause the task to block indefinitely (without a timeout).

tcpip_adapter_ip_info_t ip_info;
ESP_ERROR_CHECK(tcpip_adapter_get_ip_info(TCPIP_ADAPTER_IF_STA, &ip_info));
printf("IP Address:  %s\n", ip4addr_ntoa(&ip_info.ip));
printf("Subnet mask: %s\n", ip4addr_ntoa(&ip_info.netmask));
printf("Gateway:     %s\n", ip4addr_ntoa(&ip_info.gw));

When the connection is established, the main task prints out the network parameters (IP address, netmask and gateway). The TCPIP_ADAPTER_IF_STA constant represents (see tcpip_adapter.h) the network interface of the esp32 chip when working in station mode.

Here’s a screenshot of the program in execution:

esp32-wifi06

To make its output clearer, I turned off the default logging of the wifi driver with the instruction:

esp_log_level_set("wifi", ESP_LOG_NONE);

and disabled the buffering for the standard output:

setvbuf(stdout, NULL, _IONBF, 0);

An Intel 8085 Microprocessor Trainer

The Intel 8085 microprocessor was introduced 40 years back, and along with its contemporaries — the Z80 and the 6502 — is pretty much a dinosaur in terms of microprocessor history. But that doesn’t stop it from still being included in the syllabus for computer engineering students in many parts of the world. The reason why a 40 year old microprocessor is still covered in computer architecture text books instead of computer history is a bit convoluted. But there’s a whole industry that thrives on the requirements of college laboratories and students requiring “8085 Microprocessor Training Kits”. [TisteAndii] just finished college in Nigeria, where these kits are not locally built and need to be imported, usually costing well over a 100 dollars.

Which is why his final year project was a low cost Intel 8085 Microprocessor Trainer. It’s a minimalist design with some basic read/write memory, program execution and register inspection, with no provision for single stepping or interrupts yet. The monitor program isn’t loaded in an EEPROM. Instead, a PIC18 is used and connected to the 8085 address, data and control pins. This makes it easier to write a monitor program in C instead of assembly. And allows use of a 1.8″ LCD with SPI interface instead of the more usual 7-segment displays used for these kind of kits. [TisteAndii] built a 6×4 keyboard for input, but couldn’t solve debounce issues and finally settled on a 5×4 membrane keypad.

Being a rookie, he ended up with a major flaw in his board layout — he missed connecting the SRAM and the PPI devices to the data bus. A bunch of jumper links seemed to solve the issue, but it wasn’t perfect. This, and a few other problems gave him a lot of grief, but towards the end, it all worked, almost. Most importantly, his BoM cost of about $35 makes it significantly cheaper compared to the commercial units available in Nigeria.

While some hackers may consider this a trivial project, it solves a local problem and we hope the next iteration of the design improves the kit and makes it more accessible.


Filed under: computer hacks

Alexa Keeps Pet Snake Thermoregulated

[Chris Grill] got his hands on a pet boa constrictor, which requires a fairly strict temperature controlled environment. Its enclosure needs to have a consistent temperature throughout, or the snake could have trouble regulating its body temperature. [Chris] wanted to keep tabs on the temp and grabbed a few TTF-103 thermistors and an Arduino Yun, which allowed him to log the temperature on each side of the enclosure. He used some code to get the temp reading to the linux side of an Arduino Yun, and then used jpgraph, a PHP graphing library, to display the results.

snakemainBut that wasn’t good enough. Why not get a little fancy and have Amazon’s Echo read the temps back when you ask! Getting it setup was not so bad thanks to Amazon’s well documented steps to get custom commands set up.

He eventually lost the battle to get the Echo to talk to the web server on the Yun due to SSL issues, but he found an existing workaround by using a proxy.


Filed under: Arduino Hacks

Hackaday Links: January 15, 2017

What’s more expensive than a car and a less useful means of transportation? A 747 flight simulator built in a basement. There’s a project page where a few more details are revealed. There’s a 180 degree wrap-around screen for the main display, a glass cockpit, and the controls and gauges are ‘good enough’ to feel like the real thing. The simulator is running a highly customized version of FS9 (Microsoft’s flight sim from the year 2004).

For the last few years, Google has been experimenting with high altitude balloons delivering Internet to remote populations. This is Project Loon, and simply by the fact that Google hasn’t shuttered this Alpha-bit, we can assume the project is a success. A Project Loon balloon recently crashed in Panama, which means we can get an up-close look at the hardware. These balloon base stations are a lot bigger than you would think.

We’ve seen beautiful PCBs before, but [Blake] is taking this to another level entirely. He’s developed a process to convert bitmaps into files suitable to send to a PCB manufacturer. The results are… strange, and very cool. Check out a video of the process here.

If you want to dial out from behind the great firewall of China, you’re probably going to use a VPN. Here’s an idea that doesn’t work as well as a VPN. Use an acoustic coupler with your iPhone. Will it work? Of course it will – modems have been standardized for fifty years. Will it work well? No, I can speak faster than 300 baud.

Do you sell on Tindie? We have a dog park. Tindie sellers around the world will be meeting up on Hackaday.io next Friday to discuss Tindie and Tindie-related activities. Join in!

A quick aside relating to Hackaday and Tindie swag. 1) The Tindie dog as a stuffed animal. 2) A Hackaday logo t-shirt where the skull is decorated like a Día de Muertos sugar skull. Pick one, leave your response in the comments.


Filed under: Hackaday Columns, Hackaday links

Shmoocon 2017: A Simple Tool For Reverse Engineering RF

Anyone can hack a radio, but that doesn’t mean it’s easy: there’s a lot of mechanics that go into formatting a signal before you can decode the ones and zeros.

At his Shmoocon talk, [Paul Clark] introduced a great new tool for RF Reverse Engineering. It’s called WaveConverter, and it is possibly the single most interesting tool we’ve seen in radio in a long time.

If you wanted to hack an RF system — read the data from a tire pressure monitor, a car’s key fob, a garage door opener, or a signal from a home security system’s sensor — you’ll be doing the same thing for each attack. The first is to capture the signal, probably with a software defined radio. Take this data into GNU Radio, and you’ll have to figure out the modulation, the framing, the encoding, extract the data, and finally figure out what the ones and zeros mean. Only that last part, figuring out what the ones and zeros actually do, is the real hack. Everything before that is just a highly advanced form of data entry and manipulation.

[Paul]’s WaveConverter is the tool built for this data manipulation. Take WaveConverter, input an IQ file of the relevant radio sample you’d like to reverse engineer, and you have all the tools to turn a radio signal into ones and zeros at your disposal. Everything from determining the preamble of a signal, figuring out the encoding, to determining CRC checksums is right there.

All of this is great for reverse engineering a single radio protocol, but it gets even better. Once you’re able to decode a signal in WaveConverter, it’s set up to decode every other signal from that device. You can save your settings, too, which means this might be the beginnings of an open source library of protocol analyzers. If someone on the Internet has already decoded the signals from the keyfob of a 1995 Ford Taurus, they could share those settings to allow you to decode the same keyfob. This is the very beginnings of something very, very cool.

The Github repo for WaveConverter includes a few sample IQ files, and you can try it out for yourself right now. [Paul] admits there are a few problems with the app, but most of those are UI changes he has in mind. If you know your way around programming GUIs, [Paul] would appreciate your input.


Filed under: cons, radio hacks

Garage Door Opener Logs to Google Drive

A garage door opener is a pretty classic hack around these parts. IR, Bluetooth, WiFi, smartphone controlled, web interfaces — we’ve seen it all.  But if you want to keep track of people going in and out, you need some way of logging what’s happening. You could go ahead and roll up your own SQL based solution, tied into a custom web page. But there’s an easier way; you can build a garage door opener that logs events to Google Drive.

[WhiskeyTangoHotel] was looking for an ESP8266 project, and a garage door opener seemed just the ticket. It’s simple enough to code up, and control over WiFi comes in handy. Interfacing with the garage door was simple enough — the existing opener uses a simple push button, which is easily controlled by wiring up a relay to do the job. Logging is as simple as having the ESP8266 send requests to IFTTT which is set up to make posts to a Google Sheet with status updates.

The project is fairly basic, but there’s room for expansion. By using separate Maker Channel triggers on IFTTT, different users of the garage door could be tracked. It would also be easy to add some limit switches or other sensors to detect the door’s position, so it can be determined whether the door was opened or closed.

There’s always another take on the garage door opener — check out this hack that opens the garage door in response to flashing headlights.


Filed under: home hacks

App note: Operation evaluation of ultra low ON resistance MOSFET supporting quick charge for 1 cell Lithium ion battery protection

an_on_AND9428-D

ON semiconductor’s application note on faster charging of Lithium Ion batteries with consideration on heat suppression. Link here (PDF)

Currently, because LiB (Lithium Ion Battery) is superior in current density and electromotive force, it becomes mainstream of batteries for mobiles such as smart phone. However, because LiB is weak at over-charge and over-discharge, a control circuit is necessary to be used in combination with LiB. For the purpose of LiB current control, MOSFET is used.

This time, we would like to consider the operation and heat transfer of the CSP (Chip Scale Package) product, which is used for current control, with very small size and ultra-low ON resistance.