Project X-Ray

Two of our Hybris Labs prototypes need a tag-to-YaaS mapping. Infinite Cart  uses NFC (Near field communication) where the Tag ID is mapped as product code (SKU number). For the Changing Room prototype we are using RFID (Radio-frequency identification) tags. When we started with this prototype you had to hold a RFID tag near an RFID scanner and then had to check the log files to find its ID.

With the RFID Action Reader, which we’re also using for our Expose prototype, you can read the RFID ID on a Raspberry Pi. But I also built a custom made Arduino Shield with an Indy RS500 chip (from Impinj), which sends the the RFID value via USB port. This made life much easier and gave me the idea for Project X-Ray.

X-Ray Vision

The idea of the X-Ray Project: you can use any scanner (Barcode, NFC or RFID) to automatically add the scanned product code. The name of the Project: Tom Brady can scan the defense of an American Football team, but Superman has X-Ray Vision.

YaaS Builder Module

The X-Ray YaaS Builder Module lists all products (or variants, if you use them) with its image, product name and an editable product code.

X-Ray Demo Screenshot

X-Ray Demo Screenshot

The selected product will be saved when the user hits Return or a scanner sends a Return ‘\n’. This allows you to use a simple barcode scanner, or a NFC/RFID scanner with an Arduino Leonardo which uses the HID protocol. The HID (Human Interface Device) protocol simulates a keyboard. In this case my RFID or NFC scanner works like a keyboard and I could use it here (RFID: E28011606000020507B259A0).

An alternative is WebUSB. In this case the scan result will be only available in the browser. Another effect is that it is independent of the keyboard layout (HID shows other characters, if you’re using Dvorak as keyboard layout).

Subscribe Module

If you’re interested in this Builder Module you can subscribe it as Private Package with the Version ID 58a310e5b11af50013e341af.

Some technical stuff

The YaaS Builder Module is a static web module using RESTangular. The module runs on Cloud Foundry. For the X-Ray demo I’ve been using some images from the RetroPie project. You may have heard about our Arcade Machine here at Hybris? We are all ‘retro‘ now 🙂

And because I’m lazy, I’ve built a tool which adds products via YAML file into YaaS. The name of this tool: Megablast … yes, from the retro game Xenon 2 Megablast.

General Update & Final Architecture Diagram for Expose

It’s been a while since I wrote about expose, but finally I am sitting at the Munich airport again, which is my favorite time to write blog posts. From a technical point of view, expose is in the final phase of being polished. We’ve worked with the designers at SNK to create great user interfaces, ironed out a few bugs here and there and are currently thinking of two showrooms (Munich and New York) to install this prototype. While these discussions and the details will need a few more weeks, I think technically this prototype is locked-down and done. So it’s time to take a final look at it and wrap it all up.

So again, what is it all about? 

There’s two perspectives that we can take. The technical and the business perspective.

From a technical point of view, expose is a Hybris Labs Experiment that combines RFID and IoT technology together YaaS. The location subsystem constantly scans for registered RFID labels and tries to determine the best possible location. The data is analyzed and yields an individual journey per user of the system as well as overall location analyticsThe action subsystem allows individual participants of this experiment to interact on a 1:1 basis with the system. Current action stations include the signup station, the bar station, the journey station and the party booth – all four offer personalized interactions based on the customer’s previous behavior.

Business-wise, such a system can for example be used at events and showrooms. Via the technical means described above, we can track the location of RFID labels, which could be attached to a visitor’s event badge. From an event-coordinator’s perspective, real-time analytics where people are, where people are likely to go and what they do (action subsystem) can be offered. While the backend-users of such a system gain insights into their event and the flow of users, there’s something in for the visitors that carry the RFID labels, too. They can interact at various action points on a one-to-one basis. This means the barkeeper will remember your name and favorite drink, the event host might be able recommend people to meet based on your interests or location history, etc.

As I am a technical guy, let’s concentrate on the technical a architecture diagram first- have a look:

expose :: technical architecture

expose :: technical architecture

From bottom to top, you can see these layers of the expose system:

  • The very basis of the system are micro-services powered by YaaS – Hybris as a Service. This prototype uses quite a lot, so after registering a user, we’ve got a new customer account via the customer service, the products at the bar of course are maintained via the product service. A purchase / order results in a cart being checked out for the customer.
  • Once again, we’ve extended YaaS with custom micro-services for expose. Our RFID readers send HTTP Post requests in regular 3s intervals and the endpoint for those are part of the expose service – part of the expose package. To be brutally honest with you, at this point the configuration is rather static within this service, but at a later stage we could manage it on a tenant-by-tenant basis via a builder module. Totally accurate though in the above diagram are the user interfaces which are rendered by the expose service.
  • We’re now touching the physical world, with RFID readers installed at various locations of a showroom and at the action stations where users can interact on a 1:1 basis. Our default setup will use 5 locations (Impinj Speedway Connect readers) and 4 action points. The latter are Raspberry Pis which my colleague Lars Gregori extended with a custom shield. We attach a small antenna to them so users can put their RFID label on top to have it read. The location readers are constantly sending the scanned RFID labels to our service, where we process the location information with some self-made algorithm and store the data in the YaaS document storage.

 

The map and dashboard

 

 

 

The 4 action point UIs – signup, bar, journey and party booth.

Signup

   

Bar

 

Journey

 

 

An extra paragraph on the party booth

The party booth will be an awesome action point of the expose system and it’s a bit crazy, I agree. I have to think of a nice way of showing you the UI’s, so give me a few days after my current trip to get that done. It shows how we can interact with visitors on a 1:1 basis with the help of YaaS. It will load the data that a visitor left at signup and create a personalized party experience. At the moment, we’ve specified how the party booth will roughly look like and a local artist, Andreas Kraeftner from Munich is working on the physical fabrication. We use metal, glass, wood and it all will be combined with the electronics like Raspberry PIs, LEDs, loudspeakers, a disco ball and a fog machine. The booth will take pictures via a camera connected to the raspberry pi within the booth and it will create an animated GIF in the end that users can post on twitter.

So yes, it’s crazy. And different to many showcases you’ve seen before. It’s okay to be different!

 

An update on expose: now adding a party booth

Finally an update on the latest developments around expose, our location / action tracking prototype that we develop on top of YaaS. You might remember that we track the location of RFID labels via the location readers. Besides locating the labels, we also have developed an “action reader” subsystem that is used to engage with the user of the RFID label on a 1:1 basis. For the action readers, the user has to actively place his RFID label close to a small matchbox antenna to be scanned. Below is the updated system architecture: Expose Technical Architecture (1)

While the architecture / framework for all action readers is the same (they send their scanned labels to a common backend API), we reference the correct screen that is intended to be shown in the tablet screens based on the specific MQTT topics that are used. The action readers post to the backend including the tenant/reader Id information which will forward the data to the appropriate screen, connected via Socket.IO.

Right now we have completed these action reader setups:

  • signup: a kiosk where new users with fresh RFID labels are onboarded or may change their data
  • bar: a kiosk where either an employee or a barkeeper can log some drink that he takes out of the fridge.
  • party: a party booth that allows you to have a personalized party based on the data that we know about the user.

For this post, I wanted to specifically pick the party action reader system. It consists of:

  • an action reader that is tied to the
  • tablet screen for the party booth and
  • the party booth itself

The action reader system looks like this:

Expose Action Reader - Technical (1)

The real fun comes in when you look at the party booth. It’s a pretty nice system with a raspberry PI at its core.

Expose Action Station - Party Booth Technical (1)

 

Right now, the booth looks rough 🙂 But we’re in discussions with a local artist to create some booth building/boxing around this. It’s already a lot of fun to use, believe me!

IMG_20161125_134002 IMG_20161125_134000

The software of this system is running on node.js, starting automatically upon booth and so far quite stable. The sequence for using the booth is this:

  • a new user comes into  the booth and holds his RFID label close to the action scanner
  • the tablet screen (here: our TV screen) is showing a welcome message and the color and music choice of the customer. These data are left by the user during the onboarding/signup process
  • the party booth raspberry pi will start playing back the music according to the profile.
  • the dotstar LEDs are colored according to the profile – in combination with the rotating disco ball, this creates a nice atmosphere in the booth later
  • the fog machine turns on for a few seconds, so the bottom of the box will be filled with fog
  • while the user is in the booth and the music is playing, pictures are taken via the raspberry pi camera. These pics appear in real-time on the tablet screen.
  • once the party is over, all pics are aggregated into an animated gif and again shared to the tablet screen.
  • the user can now select one image an it will be shared to the ylabsparty twitter account. have a look it’s already pretty cool!

All right – good for now, ready for the weekend. I hope to update you soon again, till then follow us via the ylabsparty twitter account!

Expose: RFID-based location tracking

Internally code-named “expose”, we’re working on a new Hybris Labs experiment that is finally big and good enough to be blogged about. While it has been maturing for a few weeks now, it’s still in it’s infancy and many parts will prosper over time. What is it about? It’s all about using RFID readers to track the physical location of RFID tags (associated to opt-in colleagues) at our office in Munich. The proximity to the YaaS (hYbris As A Service) teams allowed us to create the complete architecture based on this platform and I am really thrilled to give you an idea about it with this blog post.

The system is currently still small, but also big enough to make technical sense. We have a setup of up to 5 RFID readers which are mapped against 5 locations (POIs, point of interest). These are two meeting rooms and 3 “areas” in the Hybris Munich office.

rfid

Before I go into detail, I’d love to cover the topic of privacy/security/etc. Are we saying that we would like to equip future customers with RFID labels to track them? No, we are not. This is an experiment, yielding a general-purpose location tracking API and means to process these events. RFID is a technology that we’ll likely use at events to generate these location-events in a very quick fashion. It brings the demos to life, as we’ll be able to consume many, many events over a short time. So keep that in mind.

The big picture

Just for the purpose of this post, I created the first architecture diagram. Let me step through the architecture, so you get a good understanding.

Expose Technical Architecture

At the very top, we have the RFID tags (sometimes called RFID labels) that have tiny micro-controllers and larger antennas around them. Those are the items we track. Each of these have unique IDs in their memory. They are passive, meaning that they don’t have a power supply of their own – they are powered by the energy that the RFID antennas in the next layer supply to them.  Up to 4 antennas can connect to a RFID reader, which is the “edge computing” element if you like. The RFID reader constantly scans for tags via the antennas and sends HTTPS POST requests to our back end services every 3 seconds. The data that these requests include is pretty basic: the reader’s MAC address and essentially a list of tags and the antenna (the port of the reader) that scanned the tag. Our RFID readers are from Impinj, a partner of SAP Hybris that we have used in the past for prototypes such as the Changing Room. Our main REST endpoint, the expose service,  is a node.js based cloudfoundry web app which is “YaaS-ified” by registering it as a YaaS service. This will later allow us on to setup security via OAuth2, metering, billing, etc… Another part that is currently purely fictional (as it does not yet exist) is the expose builder. The builder component will later allow a business user to administrate the setup. We’ve designed the whole system to be tenant-aware, which makes it easier to reuse for other events and purposes. Below the custom components (the expose service and builder module) you’ll find many core YaaS services that we are currently using: OAuth2 for getting access tokens to tenant-specific services such as documents (location history), customers (each RFID tag is associated to a customer object) and so on.

In a nutshell, we created a RFID-based location tracking system, which tries to be as technology-independent as possible. We’ve worked hard on the algorithms that try to determine the location of the RFID tags even though multiple readers scan the tags and send these requests with a few seconds offset to the back end service.  Our system is based on the rules of simplicity and honesty. We acknowledge that RFID has its shortcomings when it comes to tracking locations, for example we simply cannot scan tags that are “hidden” behind bodies. Therefore, the location that we emit will have an quality indication such as being

  • “fresh, insecure, just one-time scanned”
  • “safe, constantly scanned for several seconds” and
  • “stale, no more updates for this tag for some time”

Some Screenshots

Here are some early screenshots before beautification by our artists in residence (SNK).

zones

The zones UI (above) is a real-time view into the location tracking system. Updated via a socket.io connection, every second it shows all tags with associated customer accounts and their location state. Looks like I’ve been at Labs some time (therefore “safe” location), Agnieszka was “freshly scanned” at the cafe in the 4th floor and Ulf also just walked into the kleve meeting room.

map

Another view option is the map view. Terribly ugly right now, but technically already showing the data. We’ll change the UI soon and the concept behind the map – probably it will have the character of a heat map.

analytics_locations

Our first analytics UI will show the safe locations over the last 24 hours. It gives you an idea which areas are most frequented.

journey

Probably the roughest of the UIs (but hey, we have nothing to hide, have we?) is the journey UI. Per user, you can see the safe locations in a journey view (and again just the last 24h).

 What’s next?

While we already have a few UIs, the main focus at this point has to be on the technical aspects and to make the core RFID system run really well. We need to properly test the system with our colleagues and continue to find and fix bugs. But when it comes to big features that are currently in our heads, these are:

  • support for so-called “action readers” that will be tied to a location, but also to a specific action. In terms of an event, this might mean actions performed at the reception (new user signup) or the bar (2 cappuccinos). These actions are part of the journey elements and will probably be visualized in such a UI. This will also bring up interesting integrations with other YaaS core services such as the cart. As we already have customer accounts, this should be easy.
  • integration with SAP Hybris Profile to be able to do things like: “customer’s similar to you also visited these locations”, etc.
  •  once we’re stable enough: optimized UI’s – kiosk-style location maps etc. for the events. Also: a builder module for easy configuration of the system per tenant.

Please help us! Carry the RFID tags, check the UI’s provided to see if it makes sense, talk to us if you have questions!

Andreas, no Lego this time?

The last time I asked Andreas what on earth he was doing, his desk was full of Lego. Quite a valid question in that case. The result of this work is called Augmented Commerce.

This time things look a little more ‘conservative’…

IMG_2629 1

…but still: “Andreas, what technology are you just working on?”

“I’m working with some old friends of hybris labs: a Raspberry Pi and an Arduino. And of course we have the usual suspects like Neopixel rings and so on…  But this time we’re also trying to connect to YaaS.”

“Ok, now what connects to what? What does what and why?”

“The Raspberry Pi does the talking to the YaaS platform, taking control of the whole process. And the Arduino is responsible for the hardware stuff, like LED’s and proximity sensor. This time we’re also using a coin slot which is kind of new. Basically, we’re trying to enable the customer to pay on the YaaS platform with coins.”

“So, we’re building a smart vending machine…”

“I wouldn’t call it that, because it can be more. The idea is that you can connect anything to what we’re building here. We’re not providing a complete vending machine, but only the YaaS-connection. You have your front end through which you can pay and interact with this device, but it’s only the interface of YaaS. What you connect it to in the end is up to you.”

“Apart from lights flashing when I throw in a coin, what else happens? There’s something going on with NFC or RFID, right?”

“At the moment it’s RFID (developer language for: ‘I’ve got no idea if this is going to work. It could be anything at the end. RFID, NFC, telepathy…’). The idea was that somehow you have to authenticate yourself to access your YaaS account. We wanted to do this with RFID, at least that’s the plan for the moment (for translation see above). So, you go up to the machine and through the proximity sensor it notices you’re approaching. It greets you and says ‘Hello, please swipe your card, NFC tag, RFID token, whatever… (Ok, now I’m being a bit mean. To be fair, the things Andreas builds usually work really well. There is a reason his second name is Brain.) Once it knows who you are, you can order the product of your choice. Then you are asked to please pay. You can either throw in coins, or you use the credit you already have on your YaaS account, or you pay by Bitcoin.”

“So, you can either pay physically or digitally via your account. But when you overpay with coins you don’t get any change back, right?”

“That’s the idea, because it simplifies our device. We only take money and don’t return any…”

“Makes sense, sounds good.”

“…yes. What you overpay goes directly to your YaaS account and you can use it the next time.”

Thanks Andreas, we’re curious to see the finished prototype.

They grow up so fast…

…prototypes…one day you’re permanently checking the wiring and connections, and the next day they send you a postcard from the other side of the Atlantic.

IMG_0723[1]

(Adrian Missemer & Bahaa Badran)

No, not Adrian and Bahaa! Our Changing Room! But of course, to know that our colleagues in Canada would take good care of our baby was very comforting for us. Thanks guys!

If you’ve been following our work, you might have heard that we often were confronted with the ‘problem’ of being requested to attend at more events than we could possibly cover with our small team. (Boo-hoo-hoo! Everybody thinks our stuff is cool and worth showing, how annoying!…) Okay, our team has grown lately, but it still is difficult to make everybody happy (Not quite in line with our slogan there…). Just to clarify, it’s not always the lack manpower that is the problem. Sometimes the logistics can become a little complicated too. But without a question, receiving good support from local offices near the event location will vastly increase the likelihood of showing hybris labs prototypes at those events.

With some prototypes this will be easier than with others. But please take a look at the photo below. You can show the changing room without having to build an actual cabin! It works perfectly like that!

IMG_0724[8]

BIG Show

New York was just the right surrounding for two big premiers. First of all we presented our brand new prototype, The Changing Room. And secondly Bert gave live demos of a prototype at an event. The only thing missing was a red carpet and screaming teenagers.

Screen Shot 2015-01-23 at 10.12.02 AM

The reason why Bert had the pleasure of trading his comfortable coding environment for the Jacob K. Javits Convention Center in New York City, was that The Changing Room is basically “his” prototype. “Let him sort that one out”, we thought. And so he did. Everything worked, nothing broke down…neither machine, nor human. We can proudly state that the hybris labs Changing Room was a great success at NRF’s BIG Show 2015. If you don’t believe us, read what others say.

Apart from The Changing Room we also brought an old friend along, The Smart Wine Shelf! Haven’t mentioned it here for quite some time now… good old boy… always reliable, always doing its job, flashing nicely, attracting people, making them happy… awww……… Oh, and with it there on the photo is Sven, doing something…

Screen Shot 2015-01-23 at 10.50.18 AM

Time for a change

Imagine a lady shopping for clothes… no, actually don’t imagine a lady, picture yourself! Because the odds are pretty good you’ve already been in the following situation, or at least in one similar to it. So, let’s start again. You’re shopping for clothes. You’ve already been round town for a while and have had a fairly successful tour so far, with the result that you’re now carrying at a minimum of three bags around with you. Oh, and it’s winter which means you’ll also be wearing a thick jacket. All that’s left on your list is a pair of trousers. You find a pair you quite like, pick your size, walk to the changing room, put down your bags, take off your jacket, take off your shoes, take off your trousers, try on the pair you’ve chosen and… bugger! Wrong size… You now have a few options:

a)    You put back on your trousers and your shoes, take your jacket and your four bags,         look for the right size, and… you know the rest.

b)    You stay as you are, leaving your shoes, your trousers, your jacket and your five                bags in the cabin (hoping that nobody steels your phone and your wallet), and                    then walk through the shop half naked, searching for the right size. Then from the             top…

c)    You’re lucky enough to have a partner who accompanies you on your odyssey. So,          depending on your personality and relationship, you now either stick your head                 out of the cabin, communicate through the closed curtain, or your partner joins                 you in the cabin. In any case your belongings and your six bags are safe.

Does any of that sound remotely familiar? Oh by the way, this is how our new prototype works:

A changing room is equipped with an RFID scanner and a tablet computer. When an item (labelled with an RFID tag) is brought into the changing room, it will almost immediately appear on the tablet. By using the application on the tablet, the customer can choose a different size or colour, and have the selected item ‘delivered’ to the cabin. The customer can also select items to create a wish list which is sent to him via email.

A big thank you to the hybris UI/UX team for taking care of the design and Impinj for assisting us with the hardware!

Screen Shot 2015-01-20 at 4.10.16 PM

Changing Room live on stage at SAP d-kom! See more here!