Last week my kids’ school went on a field trip to the University of Santa Cruz to observe a black hole multimedia exhibition. We were invited there by Enrico Ramirez-Ruiz, the astrophysicist and the fellow parent at the school. When Enrico is not busy pushing the frontiers of science (he is partial to violent explosions), he teaches astrophysics to children age 4 to 12.
The exhibition combined the visualized data from recent Extreme Mass Ratio Inspiral (look it up) event, projected to the round screen on the floor, with the sound mapped to the acceleration of the star matter spiraling into the black hole, and an auxiliary animation of Einstein’s scribbles projected to the walls. It was an immersive experience.
The reality of being INSIDE of the installation, together with friends and the teacher, stimulated thinking and collaboration. Kids started asking questions, and there were no stopping of them. Enrico is awesome at understanding underlying questions children ask no matter how well or poorly they express the questions with their words.
There were certain abstractions in the visualization – it was rendered in a logarithmic scale, the perpendicular rays had to be “flatten” to the projection plane, the meaning of color was reversed to red for hot and blue for cold. Interestingly, these abstractions provoked more thinking and more discussions.
Enrico explained it is a balancing act to find a happy middle between scientific accuracy and intuitiveness of visualization.
Where the visual props come short, Enrico switches to explaining with his hands, he is as good at it as Richard Feynman was, creating a kind of single-actor science visualization theatre.
I was fascinated to hear from Enrico that, as a scientist, not only he uses imagery for explanations, but he also thinks in images.
I’ll use this as a good excuse to break into quoting my favorite parallel quotes.
When tech media started proclaiming 2016 as the year of the bots, they seem to have nailed it. At Oracle we have at least three groups working on bots, OAUX included.
One of the latest forays into bots was a Personal Assistant Technologies (PAT) hackathon, organized by Laurie Pattison’s (@lsptahoe) Apps UX Innovation Events team, open to people across Oracle. The goal? Create a great use case for bots with a great user experience.
Because I’ve done a fair amount of research on bots recently, I was selected as a mentor, though the MVM (most valuable mentor) prizes definitely went to Anthony Lai (@anthonyslai) and Noel Portugal (@noelportugal), who provided all the technical assistance for the teams.
The most interesting part of a hackathon is, of course, at the end. Each team has three short minutes to show what they built and why it’s awesome. There were a lot of teams, covering use cases from sales, service, supply chain, finance, developer tools, and project management. It was a pleasure just to see all the creativity across groups that came from distant parts of Oracle—including a few who traveled all the way from India and Armenia just to participate.
The teams had to use an NLP system and a bot framework to interact with Oracle systems to actually do something—some were more transactional, others more about querying information. The most important thing (to me, at least) about a bot use case is that it needs to be better than the existing way you’d do something. Why would a user want to use a bot—something new they have to learn, even if it is easy—instead of doing it the old fashioned way?
A big part of the potential value of bots is that it’s easy to use them from a variety of devices—if all you need to do is type or speak, you can easily use a mobile device to send a text message, Amazon Echo, your IM on your desktop, or maybe even a smartwatch. The teams used a variety of input methods, pointing out the real value someone can unlock with the ability to be productive while on the go or in contexts we don’t normally associate with work.
Also represented in the mentor and judge crowd were Oracle Virtual Assistant (part of the RightNow team), and the Chatbot Cloud Service, which Larry Ellison introduced at OpenWorld this year. Some teams leveraged the Oracle Virtual Assistant for their submissions, but it wasn’t required.
It’s an exciting time, now that natural language technology is finally enabling some wonderful user experiences. I, for one, am looking forward to seeing all the upcoming cycles of design-build-test-repeat in the quest for a useful and productive bot experience.
I have been always intrigued by the fact that people get deeply attached to the characters in the game (e.g. Second Life), or virtual pets. And with sufficient advancement in technology, the virtual characters may eventually cross the boundary and get attached to real-life people (e.g. Sci-Fi movie such as “Her”). While that is still a little far away from now, I’ve been looking to explore the 2-way communication and interaction between virtual and real world.
At AppsLab, we have enough skills to build some physical toys that we can communicate and control, but we miss a game or virtual environment that is appealing and communicative. I tried interact with Minecraft environment but stopped when it was sold. So Jake’s casual mention of MindWurld from Ed Jones (@edhjones) sparked a great interest!
MindWurld is a fantastic game. You can choose a virtual character (Avatar) to walk around Hawaii island to free and rescue pigs, also collect treasure, and play trick of spawning pigs and catching them with Pokeball. And yes, we have full access to the source code. (see Ed’s post for details)
So we came up with a game plot quickly, as manifested in the final build:
- Player in Real world communicates to a virtual character in MindWurld;
- Virtual game character and object has a mirrored object in the real world;
- Events or actions happening in sync between real and virtual objects.
This is how we put things together:
Step 1 – Toy guitar as controller
We thought of using player’s own cellphone to call a number to reach the Avatar (the virtual character in game), and just talk over the phone to tell Avatar what to do. But voice service provider was not responsive enough and we were approaching OpenWorld soon, so we ditched that approach and went for a customized controller.
Ed is a guitar player, and the virtual Avatar would be attending OpenWorld on behalf of Ed, so it is fitting that we use a toy guitar to represent him.
The toy guitar essentially provides many buttons that I can use to convey various commands and intentions, but the mod itself is a little bit more complex, as each button produce a set of signals feeding into a chip for playing music, it is not a clear simple one push to one line reading.
I used one Arduino mini pro to read signal patterns for each button push and did some noise filtering and process, and then translated them into “a player command,” which is feed into a Bluefruit EZ-key HID chip. The HID chip can connect to a computer as HID device, so each “play command” is a simple key stoke input to control the game.
Step 2 – MiP robot as mirrored avatar
MiP robot from WowWee is an inexpensive but very capable little robot. It can balance itself on two wheels, and can move back-forth, and spin on the spot, and that makes it having accurate travel along any path.
Oh, and it is quite a character. It makes happy, grumpy and lots of other noises, and shows many light patterns, to express full range of emotions!
The best part for our developers – it has an API in many languages that we can program and control the movement, sound and lights.
So for whatever events happening in the MindWurld game, such as the avatar walking around, opening treasure boxes, spawning pigs, freeing pigs and rescuing them, they are sent over a socket to a my Robot controller program, which in turn asks the Robot to perform corresponding movement and act in certain cheerful ways.
Originally, I made the MiP robot to be the mirror of virtual character in the game, in a sense that it walks the same way as his virtual part in game. It requires a large area for it to roam around. For the OAUX Exchange at OpenWorld, due to space limitation, I reprogrammed it to be a buddy of the virtual character, so it does not move too much, but makes noise and blinks light to cheer for his virtual friend.
By now, we can test out the full cast of game!
Step 3 – Juiced it up with a Pokeball
Meanwhile, Mark (@mvilrokx) had been busy printing Pokeballs: 3D printed shells, polished and painted, outfitted with unbalance motor for vibration, LED for light color effect, and NodeMCU for network connectivity, and hooked up to a MQTT broker ready for action.
Ed quickly outfitted the virtual character with a ball in hand, throwing at pigs to rescue them.
I just quickly added a MQTT client code, replied ball-thrown and pig-rescued events to MQTT broker. And the Pokeball in real world would vibrate and flash when the virtual character throws and catches pigs in the MindWurld.
Oh, that’s the Mixed Reality game setup at OAUX Exchange. Anthony had 3 days of fun time playing Rock Star, together with “real” people, “virtual” avatar, “real” avatar, “virtual” balls and “real” balls.
This is part 2 of my blog post series about the Ambient Visualization hardware (part 1). Also, please read John’s post on details about the creation of the actual visualization, from concept to build. In the first part, I focused on the hardware, a sonar sensor connected to a NodeMCU. In this second part, the focal point will be the software.
When I started working with ESPs a few years ago I was all gaga about the fact that you could use Lua to program these chips. However, over the last year, I have revised my thinking as I ran into stability issues with Lua. I now exclusively code in C/C++ for the ESPs using the arduino library for the ESP8266. This has led to much stabler firmware and with the advent of the likes of PlatformIO, a much better development experience (and I’m all for better DX!).
As I was not going to be present at the Exchange myself to help with the setup of the devices, I had to make it as easy as possible to set up and use. I could not assume that the person setting up the NodeMCUs had any knowledge about the NodeMCU, Sonars, C++ etc. Ideally, they could just place it in a suitable location, switch on the NodeMCU and that would be it! There were a few challenges I had to overcome to get to this ideal scenario.
First, the sonars needed to be “calibrated.” The sonar just measures the time it takes for a “ping” to come back as it bounces of an object … any object. If I place the sonar on one side of the room and point it to the opposite wall, it will tell me how long it takes (in µs) for a “ping” to come back as it bounces of that wall. (You can then use the speed of sound to calculate how far away that wall is.) However, I want to know when somebody walks by the sensor, i.e. when the ping that comes back is not from the opposite wall but from something in between the wall and the sensor. In order to be able to do this, I have to know how far away the wall is (or whatever fixed object the sonar is pointed at when it is placed down). Since I didn’t know where these sensors were going to be placed, I did not know in advance where these walls would be so this could not be coded upfront; this had to be done on-site. And since I could not rely on anybody being able to just update the code on the fly as mentioned earlier, the solution was to have the sonars “self-calibrate.”
As soon as you turn on the NodeMCU, it will go into “calibration mode”. The first few seconds it will take a few hundred samples under the assumption that whatever it “sees” initially is the wall opposite the device. It will then store this information for as long as the NodeMCU is powered on. After this, any ping that is close to the wall is assumed to be coming from the wall, and discarded. Whenever a ping is received of an object that is closer to the sonar than the wall, we assume that this is a person walking by the sensor (between the wall and the sensor) and we flag this. If you want to put the NodeMCU in a different location (presumably with the opposing wall at a different distance from it), you just switch it off, move it, and switch it back on. The calibration will make sure it works anywhere you place it. For the people setting up the sonars, this meant that all they’d have to do was place the sensors, switch them on and make sure that in the first 1-2 seconds nothing is in between the sensor and the opposite side (and if there was something in between by accident, they could just “reset” the NodeMCU which would recalibrate it). This turned out to work great, some sensors had a small gap (~2 meters), others had a much larger gap (+5 meters), all working just fine using the same code.
Second, the NodeMCU needs to be configured to connect to a WiFi. Typically this is hard-coded in the firmware, but again, this was not an option as I didn’t know what the WiFi SSID or password would be. And even if I did, conference WiFi is notoriously bad (the Achilles heel of all IoT) so there was a distinct possibility that we would have to switch WiFi networks on-site to a better alternative (e.g. a local hotspot). And as with the calibration, I could not rely on anybody being able to fix this in the code, on-site. Also, unlike the calibration, connecting to a WiFi requires human interaction; somebody has to enter the password. The solution I implemented was for the NodeMCU to come with its own configuration web application. Let me explain…
The NodeMCU is powerful enough to run its own Web Server, serving HTML, CSS and/or JS. The NodeMCU can also be an Access Point (AP) so you can connect to it like you connect to your router. It exposes an SSID and when you connect your device to this network, you can query up HTML pages and the NodeMCU Web Server will serve them to you. Note that this does not require any WiFi, the NodeMCU basically “brings its own” WiFi that you connect to.
So I created a Web Server on the NodeMCU and build a few HTML pages which I stored on the NodeMCU (in the SPIFFS). Whenever you connect to a NodeMCU running this firmware and point your browser to 192.168.4.1, it will serve up those pages which allows you to configure that very same NodeMCU. The main page allows you to set the WiFi SSID and password (you can also configure the MQTT setup). This information then gets stored on the NodeMCU in the Flash (EEPROM) so it is persistent; even if you switch off the NodeMCU it will “remember” the WiFi credentials.
This makes it very easy for novice users on-site to configure the NodeMCU to connect to any WiFi that is available. As soon as you restart the NodeMCU it will attempt to connect to the WiFi as configured, which brings me to the final UX challenge.
Since the NodeMCU does not have a screen, how do users know if it is even working? It needs to calibrate itself, it needs to connect to WiFi and to MQTT, how do I convey this information to the users? Luckily the NodeMCU has a few onboard LEDs which I decided to use for that purpose. To show the user that the NodeMCU is calibrating the sonar, it will flash the red LED (remember this happens at every boot). As soon as the sonar is successfully calibrated, the red LED will stay on. If for whatever reason the calibration failed – this can happen is the wall is too far away (+6 meters), not reflecting any sound (e.g. off stealth bombers) or no sonar is attached to the NodeMCU – the red LED will switch off. A similar sequence happens when the NodeMCU is trying to connect to the WiFi. As it tries, it will be blinking the blue onboard LED. If it connects successfully to the WiFi, the blue LED will stay on, if it failed however, the board will automatically switch to AP mode, assuming you want to (re)configure the board to connect to a different WiFi and the blue LED will still stay on (indicating you can connect to the NodeMCU AP) but very faintly. With these simple interactions, I can let the user know exactly what is happening and if the device is ready to go (both blue and red LEDs are on) or not (one of the LEDs or both are off).
This setup worked remarkably well and I had not one question during the Exchange on how these things work or need to be setup. All that needed to be done was set them down, boot them up, and make sure all lights were on. If they were not, try again (reboot) or reconfigure.
The actual capturing of data was pretty easy as well; the NodeMCU would send a signal to our MQTT broker every time it detected a person walking by. The MQTT broker then broadcasted this to its subscribers, one of which was a small (node.js) server that I wrote which would forward this message to APEX using a REST API made available by Noel. He would then store this information where it could be accessed by John (using another REST API) for his visualization.
As John mentioned in his post, one of the projects I worked on for OOW16 was the devices to provide the data to his Ambient Display. Unlike previous years, where we record attendance and then produce a report a few days or weeks after OOW, Jake proposed that we’d somehow visualize the data in real-time and show it to the attendees as they are producing the data themselves.
In order to produce the data, we wanted to strategically place “sensors” in the OAUX Exchange tent that could sense when somebody walks by them. Whenever this happened, the device should sent a signal to John so that he could consume it and show it on his visualization.
I considered several designs and my first thought was to build a system using a laser-diode on one side and a photo-resistor as a receiver on the other side: when somebody “breaks the beam” I would know somebody walked by, basically a laser-tripwire you can find in many other applications. Unfortunately, photo-resistors are fairly small, the largest affordable model I could find was half the size of my pinkie’s fingernail and so this meant that the area for the laser to hit was really small, especially as the distance increases. To add to this, we couldn’t attach the sensors to walls (i.e. an immovable object) because the OAUX Exchange is held in a tent. The best we could hope for to attach our sensors to was a tent pole or a table leg. Any movement in those would misalign the laser or the sensor and would get registered as a “walk by.” So I quickly abandoned the idea of lasers (I’ll keep that one in the bag for when we finally get those sharks).
Noel suggested to use an ultrasonic sensor instead. These work just like a sonar: they send out inaudible “pings” of sound and then listen for the sound to come back when it bounces of an object. With some simple math you can then work out how far that object is removed from the sonar sensor. I tested out a few sonar sensors but I finally settled on the LV-MaxSonar-EZ1, which had the right combination of sensitivity at the distances we needed (+2 meters) and ease-of-use.
Next I had to figure out what to attach the sensor to, i.e. what was going to be my “Edge” device. Initially I tested with a Raspberry Pi because we have a few of those around the office all the time, however this turned out to have several disadvantages. For one, the LV-MaxSonar-EZ1 is an analog ultrasonic sensor. Since the RPi does not support analog input I had to use an ADC chip to convert the signal from analog to digital. Although this gave me very accurate readings, it complicated the build. Also, we weren’t guaranteed power at each station so the end solution would have to be able to run on battery power all day long, something that is hard with a RPi.
Next I used an Arduino (Uno) as my Edge device. Since it has analog inputs, it was much easier to build but the problem is that it needs an additional WiFi Shield to be able to connect to the internet (remember, I needed to get the sensor data somehow to John), which is pretty pricy, combined we are now talking +$100. I wanted a cheaper solution.
As is customary now with me when I work on IoT solutions, I turned to the ESP8266/NodeMCU. It’s cheap (< $10), has lots of GPIOs (~10) and has Wifi built in. Also, we had a few lying around :-):
I hooked up the Sonar to the NodeMCU (using PWM on a digital GPIO) and within a few minutes I had accurate readings and was sending the data to the backend over the internet: IoT FTW! Furthermore, it’s pretty easy to run a NodeMCU off battery power for a whole day (as it turned out, they all ran the whole 3-days of the Exchange on a single charge, with plenty of battery power to spare!). It was really a no brainer so I settled on the NodeMCU with the LV-MaxSonar-EZ1 attached to it, all powered by a ~6000mAh battery:
Once I settled on the hardware, it was on to the software, which I will explain in detail in a second post.
This year I had the great opportunity to attend in person Oracle OpenWorld 2016 and JavaOne 2016. Since I was student, I heard how fantastic and big is this conference but you cannot realize it until you are in it.
All San Francisco is taken by a bunch of personalities from all companies around the world, and it’s a great space to talk about Oracle, show off our projects and of course, our vision as a team and organization.
In this conference you can see a big contrast between attendees profiles. If you walk near to Moscone Center, you probably will see attendees wearing suits and ties and talking all time about business. In contrast, if you walk couples block to downtown you will see more casual dress code (shirts and jeans) meaning that you are entering to developers zone.
Either way, the whole city is all about Oracle. Even, there are a couple of main streets that are closed to set up a lounge area, booths and entertainment. You can see hanging posters and glued around the entire city. It’s awesome.
Conference is divided in two, OpenWorld and JavaOne. So as I said, this conference cover a lot of interesting areas of technology.
I attended this year to polish our demos before the conference and to help Oracle Network Technology (@oracleotn) with our IoT Workshops. This workshop was at both OpenWorld and JavaOne conferences, I helped at JavaOne.
The idea behind the IoT Workshop was to introduce technical and non technical people to the IoT world. Show them how easy is to start and teach them the very basic tools, hardware and of course, code to connect things to internet.
From the beginning, we were skeptical in the results. This was the first time we ran this workshop in a big conference three days in a row. Our schedule was five sessions per day, one hour each session. The start was slow, but we got a lot of traction the consecutive days. The response from attendees was awesome. Last two days, pretty much all sessions were packed up. At some point we had a long waitlist and all people wanted to get the IoT Starter Kit.
Speaking of Starter Kit, we were giving away the kit to all attendees at the end of the session. The kit includes one NodeMCU with an ESP8266 WiFi micro controller, a push button, a buzzer, a resistor, a LED and some cables to wire the components. Attendees could take the workshop in two ways; from scratch, meaning that they had to use their own computer and install all required tools and libraries and then compile the Arduino code, wire the components and flash the NodeMCU or the expedited way, meaning that we give them pre-flashed micro controller and they just wire components.
It was very surprising that many attendees decided to take the long path, that showed us that they were very interested to learn and potentially keep working on their own projects. Part of the session, we spent some minutes talking about how OAUX is using IoT to see how it will affect user experience and propose projects that can help Oracle users and partners in their daily lives.
Specifically at JavaOne, we had many conversations about how potentially they could find a niche in their companies using IoT, and they came up with pretty cool ideas. It was so fun and interesting having direct contact with both technical and non technical people.
I think Java is one of my preferred programming languages so far, and I had never had the chance to attend a conference about Java. This time was awesome, I had the chance to present and at the same time be an attendee.
The rest of the team was working at the OAUX Exchange. We presented all our demos and I didn’t miss the opportunity to see how people get very excited with our demos.
And to close with a flourish, some OOW attendees were invited to visit our Gadget Lab to show more about our vision and new integrations with gadgets we have got lately.
Overall, OOW is the result of our team work and collaboration during the year. It’s where we see reflected all our work into smiles, wows and people’s enthusiasm. It’s a feeling that cannot be described.
Finally we are here rolling again, getting prepared for the next OOW. So stay tuned on what we are cooking up to surprise you.
OK, it wasn’t me exactly. It was more like some of my software-based representatives.
Hi, I’m Ed (@edhjones). And I’m not one of the AppsLab folks. But I’m always interested in the work they do, so I try to hang out with them whenever we’re co-located. I was intrigued then when, a couple of months prior to OOW16, I get a mail from Jake (@jkuramot) CC’ing Raymond (@yuhuaxie). It said, simply:
“Ed did something cool w APEX and Minecraft that he showed at Kscope15 … you two should talk and share notes.”
What was this cool something that I did? For starters, whilst undoubtedly cool (even though I say so myself!) it wasn’t really Minecraft. Although, to be fair, it did look quite a bit like it, thanks to my rather basic 3D modeling skills, and because I borrowed some textures from BDCraft. It’s actually something that I whipped up for the APEX Open Mic night at the Kscope15 conference. It was just an experiment at the time, so I was very excited that the AppsLab wizards might be able to put it to some use.
It’s a web application running on Oracle’s internally hosted APEX (#orclapex) instance. It uses Three.js to present an interactive 3D visualization of information in the Oracle database. And it just so happens that that visualization looks somewhat like a blocky character walking around in a low-poly world. The data in question is provided by back-end service calls to the US Geological Survey’s point query service, which is then cached in the database and provided to clients as streamed chunks of JSON. In the case of the demo, the elevation data was used to simulate a scaled down version of Hawaii.
Other service calls reach out to the Clara.io browser-based 3D modeling and animation software, from where some of the character models are loaded on-the-fly. Other scenery data, like rocks and trees, are generated procedurally based on pseudo-random seeds calculated from the object’s geographical location in the virtual world. No Man’s Sky, eat your heart out.
The “game” aspect of the demo is implemented as (yet more!) service calls to Oracle’s Social Network. Conversations which you create in the Social Network, and tag in a certain way, appear in the visualization as chests. You open the chest, and you see a “parchment” containing the related OSN conversation, and that gives you a clue as to where the next chest might be, and so on, until you complete the treasure hunt.
It’s also multi-player so that many people can be hunting together. And they can see each other, unlike No Man’s Sky. And it’s integrated with our internal OraTweet micro-blogging platform, built many years ago by Noel (@noelportugal) and still going strong, to allow those players to talk to each other from within the game.
But, why? As I say, it was an experiment; an experiment into the amazing capabilities that today’s modern browsers provide, specifically in the way of hardware accelerated 3D graphics and HTML5 audio, and it’s a demonstration of how seamlessly Oracle Application Express (APEX) is able to interface to a multitude of external services, and efficiently handle large volumes of data. There are a lot of data-points in a map of Hawaii. It was (IMHO) a cool experiment, I’d moved on to other things, but now it was about to get a new lease of life.
The discussions kicked-off with Jake and Raymond mentioning that they were investigating some interesting experimental control schemes and devices, but they needed something (fun, preferably) to control. Exactly what those control schemes are will be the subject of a future post from Raymond but, suffice to say; if we could resurrect my experiment, and connect it up to these devices, then that surely would be a cool demo for Oracle OpenWorld.
Since I didn’t know what environment I’d be running in (it might not have access to Oracle’s internal network, or any network at all, for example) I wanted to make it a bit easier to move the application around and I wanted to reduce the dependencies upon other systems. So, here’s what I did:
- I modified the original APEX application to, instead of serving up an interactive web-application, just serve up the data upon which that application relied, so I was able to create a new (simplified) version of the application running more or less from static files.
- Ported (a simplified version of) the back-end logic from the original PL/SQL to Node.js running a locally hosted Express-based server.
- Added gamepad support via the HTML5 API, because I have a PS4 controller that’s color-coordinated with my Mac. 😉
- I wanted to make it prettier, so I added a reflective animated water shader. Showcasing, even more, how powerful browser-based 3D has become.
- Since I’d removed many of the external service calls, including those to the Oracle Social Network, we needed something for the players to do; the chests now shower you with treasure courtesy of GPU driven particle effects!
- And there’s also pigs! Initially they’re trapped in pens around the island, but you can push the barriers out of the way and set them free. Then they just wander around aimlessly until they, rather sadly, fall into the sea.
- But all is not lost because, fortunately, you are equipped with a “Magic Ball” which looks strangely familiar. You can launch this toward any pigs you’ve freed, capture them, and teleport them to a place of safety.
All fun and games. But we still needed some kind of controls. And, at this point, I had no concrete idea of exactly what scheme Raymond was dreaming up. So, we needed a “loose” way of providing bi-directional communications between the game and something.
The browser client then was connected up to the server using socket.io to facilitate real-time communication between the two. When certain events happen in the client (you rescue a pig, for example) then messages are sent to the server, when the server sends certain messages (for example, a command to “push” something) then the client performs a pre-determined action, like pushing a barrier out of the way.
At the server end, I added functionality to listen for messages sent to specific MQTT channels, interpret them and pass appropriate actions on through the websocket connection to the browser client. The theory being; we can now connect up any input device, even remote ones and multiple different ones, as long as they’re able to send the right messages to the right channel on an MQTT broker somewhere.
To test this out, before we had the real control devices available, I simply used jQuery Mobile to whip up a quick interface for my phone (served from the same Node.js server as the main application) which sends messages to the broker which then get passed on to the client. It’s a pretty cool experiment to be able to control a 3D world that’s hosted on my MacBook (but deployable to any Node.js application container platform, I used Modulus) running in Chrome, on a gaming PC displayed on your TV in your lounge, from an interface your phone, whilst standing on the sidewalk at the opposite end of the street, through messages being bounced from my tiny home town in Australia via an MQTT channel on the other side of the planet.
At this point, I made a final push to github and was done. Now it was up to Raymond to weave his Maker Magic and connect up his innovative control devices. Happy that my little 3D people and pigs would be off on their own to Oracle OpenWorld 2016, I simply left it in the more than capable hands of our beta-testers.
We have been quietly observing and evaluating our options before we finally decided to get a telepresence robot. Telepresence technology dates back to 1993 (Human Productivity Lab) and telepresence robots are not completely new.
There is a growing array of telepresence robot options (see comparison) and the list is bound to get cheaper and better. Before we settled on getting the Double Robotics robot, we tested the Suitable Technologies Beam. The Beam robot is a pretty solid solution, but it lacked one of our primary requirements: an SDK. We wanted a platform that we could “hack” to explore different scenarios. So we got the Double 2 robot, which does have and SDK and promptly gave it a name: Elliot after the main character in Mr. Robot.
As far as usability, driving around is not difficult at all. The Double 2 does lack a wide angle camera or foot camera since it uses the camera from the iPad. (Edit: It was pointed to me that The Double 2 standard set includes an attachable, 150 degree wide-angle camera and an always-on downward facing camera. We just didn’t buy the standard set.) But driving the Double 2 feels really smooth, so moving around to look and moving side to side is not a problem. The iPad housing has a mirror pointing to the bottom so you can switch to the back camera and see the bottom. There is an Audio Kit with external mic and speaker that helps you hear and be heard better. Overall the experience is good as long as you have good internet connectivity.
I have been virtually attending some of our Cloud Lab tours and the reaction is always positive. I also attended a couple meetings and felt a bit more integrated. Maybe that would wear off with time, but that is one of the reason we have it, to research the human aspect of these devices.
I am eagerly working on making Elliot a little more smart. Thanks to the SDK I can automate movement, but sadly the Double 2 doesn’t have any external sensors. So we are working on retrofitting some sonar sensors similar to the ones we used for this project to give Elliot a little more independence. So stay tuned to see more coolness coming from Elliot.
One month before we entered the OAUX Exchange tent at OpenWorld, Jake (@jkuramot) challenged us to come up with a visualization “that would ambiently show data about the people in the space.”
Mark (@mvilrokx), Noel (@noelportugal) and I accepted the challenge. Mark put together the Internet of Things ultrasonic sensors, Noel created a cloud database to house the data, and it fell to me to design and create the ambient display.
An ambient display is the opposite of a dashboard. A dashboard displays an array of data in a comprehensive and efficient way so that you can take appropriate actions. Like the dashboard of a car or airplane, it is designed to be closely and continuously monitored.
Ambient displays, in contrast, are designed to sit in the background and become part of the woodwork, only drawing your attention when something unusual happens. They are simple instead of complex, unified instead of diverse, meant for glancing, not for scanning.
This project was not only a chance to design an ambient display, but also a chance to work with master makers like Mark and Noel, get my feet wet in the Internet of Things, and visualize data in real time. I’ve also long wanted to make an art installation, which this sort of is: an attractive and intriguing display for an audience with all the risks of not really knowing what will happen till after the curtain goes up.
My basic concept was to represent the sensors as colored lines positioned on a simplified floor plan and send out ripples of intersecting color whenever someone “broke the beam.” Thao (@thaobnguyen) suggested that it would be even better if we could see patterns emerge over time, so I added proportion bars and a timeline.
Since we only had a few weeks we had to work in parallel. While Mark and the rest of the team debated what kind of sensor to use, my first task was to come up with some visuals in order to define and sell the basic concept, and then refine it. Since I didn’t yet have any data, I had to fake some.
So step one was to create a simulation, which I did using a random number generator weighted to create a rising crescendo of events for four colored sensor beams. I first tried showing the ripples against a white background and later switched to black. The following video shows the final concept.
Once Mark built the sensors and we started to get real data, I no longer needed the simulation, but kept it anyway. That turned out to be a good decision. When it came to do the final implementation in the Exchange tent, I had to make adjustments before all four sensors were working. The simulation was perfect for this kind of calibration; I made a software switch so that I could easily change between real and simulated data.
The software for this display did not require a single line of code. I used NodeBox, an open source visual programming tool designed for artists. It works by connecting a series of nodes. One node receives raw cloud data from a JSON file, the next refines each event time, subtracts it from the current time, uses the difference to define the width of an expanding ellipse, etc. Here is what my NodeBox network looks like:
One challenge was working in real time. In a perfect world, my program would instantly detect every event and instantly respond. But in the real world it took about a second for a sensor to upload a new row of data to the cloud, and another second for my program to pull it back down. Also, I could not scan the cloud continuously; I had to do a series of distinct queries once every x seconds. The more often I queried, the slower the animation became.
I finally settled on doing queries once every five seconds. This caused an occasional stutter in the animation, but was normally not too noticeable. Sometimes, though, there would be a sudden brief flash of color, which happened when an event fired early in that five-second window. By the time I sensed it the corresponding ripple had already expanded to a large circle like a balloon about to pop, so all I saw was the pop. I solved this problem by adjusting my clock to show events five seconds in the past.
Testing was surprisingly easy despite the fact that Mark was located in Redwood Shores and Noel in Austin, while I worked from home or from my Pleasanton office. This is one of the powerful advantages of the Internet of Things. Everyone could see the data as soon as it appeared regardless of where it came from.
We did do one in-person dry run in an Oracle cafeteria. Mark taped some sensors to various doorways while I watched from my nearby laptop. We got our proof of concept and took the sensors down just before Oracle security started getting curious.
On the morning of the big show, we did have a problem with some of the sensors. It turned out to be a poor internet connection especially in one corner of the tent; Noel redirected the sensors to a hotspot and from then on they worked fine. Jake pitched in and packaged the sensors with hefty battery packs and used cable ties to place them at strategic spots. Here is what they looked like:
The ambient display ran for three straight days and was seen by hundreds of visitors. It was one of the more striking displays in the tent and the simple design was immediately understood by most people. Below is a snapshot of the display in action; Jake also shot a video just before we shut it down.
It was fun to watch the patterns change over time. There would be a surge of violet ripples when a new group of visitors flooded in, but after that the other colors would dominate; people entered and exited only once but passed across the other sensors multiple times as they explored the room. The most popular sensor was the one by the food table.
One of our biggest takeaways was that ambient displays work great at a long distance. All the other displays had to be seen closeup, but we could easily follow the action on the ambient display from across the room. This was especially useful when we were debugging the internet problem. We could adjust a sensor on one side of the room and look to the far corner to see whether a ripple for that sensor was appearing and whether or not it was the right color.
It was a bit of a risk to conduct this experiment in front of our customers, but they seemed to enjoy it and we all learned a lot from it. We are starting to see more applications for this type of display and may set up sensors in the cloud lab at HQ to further explore this idea.
Companies talk about “Gamification,” but the first time I felt like I was playing a game at work was driving our Double telepresence robot around the office floor, rolling down the hallway and poking into cubicles. With a few simple controls—forward, backward, left, and right—it took me back to the D-pad on my NES, trying to maneuver some creature or robot on the screen and avoid obstacles.
It’s really a drone, but so much less stressful than controlling a quadcopter. For one, you can stay put without issue. Two, it’s not loud. And three, there aren’t any safety precautions preventing us from driving this around inside Oracle buildings.
Of course, this isn’t the intended use. It’s a telepresence robot, something that allows you to be more “present” in a meeting or at some remote site than you would be if you were just a face on a laptop—or even more invisibly—a (mostly silent) voice on a conference call. You can instead be a face on a robot, one that you control.
That initial drive wouldn’t have been nearly as fun (or funny) if I were just cruising around the floor and no one else was there. A lot of the enjoyment was from seeing how people reacted to the robot and talking to them about it.
It is a little disruptive, though that may wear off over time. Fellow AppsLab member Noel (@noelportugal) drove it into a meeting, and the whole crowd got a kick out of it. I could see throughout the meeting others gazing at the robot with a bit of wonder. And when Noel drove the robot behind someone, they noted how it felt like they were being watched. But no one forgot Noel was in the meeting—there was an actual presence that made it feel he was much more a part of the group than if we were just on the phone.
On another virtual walkaround, Noel met up with Mark (@mvikrokx) and they had a real work conversation about some hardware they had been emailing back and forth about, and being able to talk “face” to “face” made it much more productive.
All this provokes many interesting questions—is a telepresence robot better than video conferencing? How so, and by how much? How long does it take for the robot to seem “normal” and just become a part of a standard meeting?
And of course—what would a meeting be like that consisted solely of telepresence robots?
In last post, we have setup development environment for coding and uploading scratches to NodeMCU, an IoT device.
This post, we will upload and run two examples to demonstrate how IoT device sending data into Cloud and receiving commands from Cloud. You can find the source code and MQTT library requirement on github.
4. Architecture Diagram
It involves several tiers and components to make the whole IoT loop. However, you will just focus on device communication with MQTT, all other components have been setup properly.
5. Wiring Diagram
For the two testing examples, you can just use the following diagram:
And here is an example of actual wiring used to test the example code:
6. Test Sample #1
Demonstrate that IoT device interacts with Internet over MQTT. You can get the source code from github: https://github.com/raymondxie/iotws/blob/master/iotws_mqtt.ino
Please note, you need modify the code by supplying necessary connection parameters for WiFi network and MQTT broker. Check the parameter values with your instructor.
The example let you press a button, the event is sent to MQTT broker in the Cloud, and NodeMCU board is also listening to that channel for input, essentially the information just come right back to the board. Based on the button press count (even / odd count), the board plays a different tune for you.
Have fun playing the tunes!
7. Test Sample #2
Send a message into Oracle IoT Cloud Service (IoTCS) by press of a button. You can get the source code from github: https://github.com/raymondxie/iotws/blob/master/iotws_iotcs.ino
Please note, you need modify the code by supplying necessary connection parameters for WiFi network and MQTT broker. Check the parameter values with your instructor.
This sample let you press a button, and a message along with your name is sent to MQTT broker. There is a Raspberry Pi listening to inputs to that particular MQTT channel. The Raspberry Pi acts as a gateway to IoTCS, and relays the message to it. You can then verify your message with your name in the IoTCS console.
AppsLab and OTN will jointly host IoT Workshop at Oracle OpenWorld and JavaOne conference in 2016. We look forward to seeing you at the Workshop.
Here is some details about the Workshop with step-by-step instructions. Our goal is that you will learn some basics and get a glimpse of Oracle IoT Cloud Service at the workshop, and you can continue playing it with IoT package after going home. So be sure to bring your computer so we can setup proper software for you.
Before we get into the step-by-step guide, here is the list of hardware parts we will use at the IoT Workshop.
1. Download and install software
We use the popular Arduino IDE to write code and upload to IoT device.You may download it from Arduino website even before coming to the workshop.
Just to make sure you get the proper platform for your computer, e.g. if you have a Windows machine, get the “Windows installer.”
The installation is straightforward, as it is very typical installation on your computer platform. If needed, here is instruction: https://www.arduino.cc/en/Guide/HomePage
2. Setup Arduino IDE to use NodeMCU board
We use a IoT device board called NodeMCU. Like Arduino Uno board, it has many pins to connect sensors and LED lights, but also has built-in WiFi chip which we can use to send input data into IoT Cloud.
You have installed Arduino IDE at step 1. Now open the Arduino IDE.
Go to File -> Preferences, and get to a page like this:
Add this “http://arduino.esp8266.com/stable/package_esp8266com_index.json” to the “Additional Boards Manager URLs” field, and then hit “OK” button.
Restart Arduino IDE, and go to “Tools” -> “Board” -> “Board Manager”, and select “esp8266 by ESP8266 Community”. Click it and install.
Restart Arduino IDE and go to “Tools” -> “Board”, and select “NodeMCU 1.0” board.
Also set up corresponding parameters on CPU Frequency, Flash Size, etc, according to above screenshot.
3. Quick Blink Test
To verify that we have set up the Arduino IDE for NodeMCU properly, we can connect the board to computer using a USB-microUSB cable.
Then go to “File” -> “New”, copy & paste this example code into coding window: https://github.com/raymondxie/iotws/blob/master/iotws_led.ino
Select the proper Port where board is connected via USB:
Click “Upload” icon on the top left of Arduino IDE, and observe that the sample code is loaded onto board. The on-board LED should blink once per second.
For some Macbook, if you don’t see proper port of “USBtoUART”, you need install a FTDI driver – you can download it from here.
For Windows machine, you will see certain “COM” ports. You need install this driver.
You can also play around and connect an external LED light to a pin similar to following wiring diagram, and modify the code to use that pin to blink the LED.
By now, you have completed the setup of Arduino development environment for NodeMCU – an IoT device, upload and execute code on the device.
Want to learn more about the Internet of Things?
Are you attending Oracle OpenWorld 2016 or JavaOne 2016? Then you are in luck! Once again we have partnered with the Oracle Technology Network (OTN) team to give OOW16 and JavaOne attendees an IoT hands-on workshop.
We will provide a free* IoT Cloud Kit so you can get your feet wet on one of the hottest emerging technologies. You don’t have to be an experienced electronic engineer to participate. We will go through the basics and show you how to connect a wifi micro-controller to the Oracle Internet of Things Cloud.
Note: OK, so that Gluon JavaOne app, 1) isn’t new this year and 2) I posted the wrong links. This year’s app is called JavaOne16, so look carefully. You can find the IoT Workshop signups under OTN Experiences.
Or find us at the OTN Lounge on Sunday afternoon. Workshops run all day, Monday through Wednesday of both conferences. Space is limited, and we may not be able to accommodate walkups, so do sign up if you plan to attend.
Then come to the OTN Lounge in Moscone South or the Java Hub at Hilton Union Square with your laptop and a micro-usb cable.
*Free? Yes free, while supplies last. Please make sure you read the Terms & Conditions (pdf).
“Supercharged Perseid Meteor Shower Peaks This Month” – as the very first edition of Daily Minor Planet brought us the news on August 4th, 2016.
Daily Minor Planet is a digital newspaper on asteroids and planetary systems. It features an asteroid that might fly by Earth for the day, or one of particular significance to the day. Also it features a section of news from different sources on the topics of Asteroid and Planets. And most interestingly, it has a dynamic orbit diagram embedded, showing real-time positions of the planets and the daily asteroid in the sky. You can drag the diagram and see them in different angles.
You can read the live daily edition on the Minor Planet Center website. Better yet, subscribe to it with your email, and get your daily dose of asteroid news in your email.
Daily Minor Planet is the result of collaboration between Oracle Volunteers and Minor Planet center. Since the Asteroid Hackathon in 2014, we have followed up with a Phase I project of Asteroid Explorer in 2015, which focused asteroid data processing and visualization. And this is the Phase II project, which focuses on the public awareness and engagement.
The Oracle Volunteers on this phase consisted of Chan Kim, Raymond Xie (me!), Kristine Robison, DJ Ursal and Jeremy Ashley. We have been working with Michael Rudenko and J.L. Galache from Minor Planet Center for past several months, and created a newspaper sourcing – editing – publishing – archiving system, with user subscription and daily email delivery functionality. And during the first week of August, the Oracle volunteer team were on site to prepare and launch the Daily Minor Planet.
Check out video of the launch event, which was hosted in Phillips Auditorium, Harvard-Smithsonian Center for Astrophysics, and live streamed on YouTube channel. The volunteer’s speech starts around 29:00 minute mark:
It was a quite intense week, as we were trying to get it ready for launch. In the end, as a reward, we got a chance to have a tour of the Great Refractor at Harvard College Observatory, which was located just in next building.
By the way, the Perseid meteor shower this year will peak on August 12, and it is in an outburst mode with potentially over 200 meteors per hour. So get yourself ready and catch some shooting stars!
By now, I have played Pokemon GO for 2 weeks and have reached the coveted level 22. Pokemon GO (POGO) is a massively popular mobile game that has been a viral hit. It became the most popular paid app in the iOS store within a few days, received more than 10 million downloads within its first week, surpassed Twitter in daily active users (DAU) and has already generated $14.04 million in sales, which is 47% of the total mobile gaming market. It’s so popular that players are deciding where they eat based on the restaurant’s proximity to a Pokestop. In lieu of this, Yelp added a Pokestop filter in their web and mobile app. POGO’s popularity has led to massive amount of server issues that is common amongst the initial launches of massively multiplayer online role-playing games (MMPORG) like Sim City, Diablo 3 and Guild Wars 2. To be fair, POGO wasn’t expected to be this popular outside of their already established fan base and is technically still in beta 0.29.3. I’m happy to say that the server has stabilized and I rarely encounter any server issues during peak times. Despite the lack of communication and transparency that should be a part of any customer experience, Niantic worked hard and proved with their launch in Japan that servers issues will be a thing of the past.
It’s safe to say that POGO has transformed how we experience reality through our phones. It did it so smoothly in a matter of days! There are a lot of game play dynamics at play, but before I get into that, there are a few external dimensions that led to the success of POGO.
- Demographic Appeal – The Pokemon IP comes with a ready fan-based of mid-20s to 30-somethings whom may already have children at the perfect age for mobile games. The brand consciously tries to appeal to people of all ages, with marketing schemes that tries to draw new fans in and keep the old ones around. Just a few weeks ago before the POGO game launch, I was at a Build-A-Bear factory at the West Edmonton Mall only to find that the Pikachu skins that I saw the morning off was sold out later when I visited the same night.
- Dev UX – Pokevision and Pokemon Go for Slack are a few add-ons that spun off from Niantic’s open API. This is rare for a mobile game to allow their users to build custom tools to enhance game play. Developers are users too.
- Android and iOS launch – I don’t remember an instance when a mobile game app launched on both Android and iOS stores at the same time. In combination with the single sign-in and summer timing of the launch helped boost conversion.
- New technology – The seamless camera integration for Augmented Reality (AR) is the differential when comparing POGO to other mobile games. Seeing the small creatures layered over reality makes the game play experience seem more “real.”
- Dedication & Vision – The game took 20 years in the making, with one single vision of having a game layer over the world. UX is not just about being simple, beautiful nor having a set of easy to use features. That vision laid the groundwork for every design decision made and helped identify strategic opportunities for a potentially disruptive market (More of product thinking and UX vision). In POGO’s case, Keyhole and Ingress laid the groundwork for the success of the game. It’s turning point was the 2014 viral success of finding Pokemon in Google Maps.
My Experience and the UI
A few others have written about the easy on-boarding of the game, so I will not rehash that.
I found that the game incentivizes things that we do already when on the go (Pokemon GO :]) We go to work, we go out to eat, we walk the dog, we go to school, and hang around in groups at parks and meetups. Walking helps us hatch eggs for rare or high IV Pokemon, find other Pokemon that hides in the tall grass, while also getting you from point A to point B. Walking also gets you to gyms and Pokestops for much needed supplies. Best of all, walking takes us to new places and outside to meet new people with the same common interest of playing POGO.
As a game that’s meant to be played quickly and on the go, everything happen within minutes. The traditional Pokemon game play is replaced with a minimum viable feature list. We don’t spend 5+ minutes battling a Pokemon, agonizing over the move sets, IVs (Individual Values) or natures anymore. I mean…unless you want to. Instead, we spend at most 90 seconds trying to take over a gym, move sets are randomly selected for us and catching a Pokemon is done with a quick flick of a finger.
The third person avatar view and map overlay is just real enough to be believed. Our brains are harsh judges of things that try to be realistic but falls short. This is a challenge with virtual reality. When something is represented to us as real, we try to find the smallest discrepancies which prevents us from suspending our disbelief; yet when we are presented with something that is not “real” our brains easily accepts that representation and fills in the gaps cognitively. As I walk around, I find myself amazed at how accurate my avatar seems to follow me. Even as I am standing still and turning to face different directions, my avatar follows smoothly.
Strangely, I felt connected to the real world as I was walking around zombified with my peers. Just the other day, a fellow player yelled “Starmie!” and the location of that Pokemon. Unsurprisingly, we all slowly got up and walked in a huge group to the other end of the park. Though we are still staring at our phones, we are really watching our avatar walk in a map overlay of the real world. We are aware of the river to the left of us and the road that is coming up ahead as depicted on the map. The Pokestops are easter eggs of wall murals, sculptures and other places of interest that I never would have stopped to look at before.
The game is addicting as Facebook and Instagram are. There is a constant need to check if there is a new Pokemon spawn around the corner. Feedback is constant and instantaneous. Catching and spinning a Pokestop is just as satisfying as clicking on the red notification bubble or pulling to refresh a feed. Despite server issues, there were intrinsic rewards tied to every game mechanic.
Since we have to walk around to play an augmented reality game, we are encouraged to interact with strangers. On the game map you can find high activity hot spots. Many times in and out of work, I have no problems befriending others while finding an elusive dratini at the Oracle lagoon or when picking a random picnic spot between high traffic lures at Guadalupe Park and chatting about our latest Pokemon catches, know-hows and food. Last week, I walked across the street to have lunch at my friend’s work place. The many times that I’ve been there before, I’ve talked to only 2 or 3 of her co-workers. Now when I walk over, we have lunch then join a group of my friend’s Pokemon hunting colleagues and we found a rare Hitmonlee together. They shared the location of an Electabuzz spawn. They taught my friend and I how to hunt nearby creatures using the on-screen compass.
Interestingly enough, there is no need to share your activity with your virtual social network, nor is there a push for you to purchase in-app items. How many times have you been asked to invite your friends to play to progress further in a game? How many times in a game is an advertisement for an in-app purchase persistent through every screen? I’m never bombarded with such eye sores in POGO. Everything seems more organic. It’s refreshing from the usual Facebook game apps and Candy Crush games that gamifies your network to level up further.
Life has definitely changed as illustrated by this meme (credit: http://www.dorkly.com/post/79726/life-before-pokemon-go-and-after).
Thoughts on the Future of Pokemon Go
Having gone this far in the game, it’s hard to keep motivated. Catching Pokemon and gaining experience is harder unless you are willing to shell out money for more pokeballs, lucky eggs and incubators. Other than the group meet ups and the need to “catch em’ all,” the rewards to get up to the next level isn’t incentivizing enough. For those that have caught ’em all or are have the grinding stages of the game (lvl 22+), Pokemon Go’s announcement at the San Diego Comic Con 2016 gave current players a reason to keep playing.
- They are planning on releasing the 6 elusive legendary Pokemon to round out the original 151 Pokemon in the 1st generation series.
- The teams we have chosen will have a bigger role in the story of the game. I’m excited that there will be a more immersive story that will translate into the real world. When I currently play with players from other teams, we are simply taking turns imperializing gyms. There is no purpose other than to gain experience points and bragging rights. Storytelling inspires and persuades. It makes your games more real and engaging. The three teams in POGO already has a persona behind them that frames each player’s alter ego in the game. Just as people can easily identify with and exhibit character traits from Gryffandor, Slytherin, Hufflepuff and Ravenclaw in Harry Potter, I’ve seen groups in the real world exhibit the characteristics of their chosen team as they play the game. I’m excited to see what narrative Niantic has planned out for us.
Since the goal of the game is for players to go out and explore and/or be on the move, what if there was a Fitbit like band that that counts your steps so you can hatch eggs when running on a treadmill? Can Google glass make a comeback? Instead of staring at the phone, I can still hunt for Pokemon while keeping my eyes on my real surroundings? How about a wearable like an Apple Watch that vibrates when a Pokemon comes up. I can just tap to automatically throw a ball without looking if I am riding a bike.
The game will definitely spur more AR games that may or may not have as huge of an impact as POGO but will increase adoption of AR as a social media and marketing platform. McDonalds is the first to partner up with the game to turn every location in Japan to a gym. Eateries, museums and police stations have all been inserting themselves into the game by purchasing lures to attract crowds of players into their establishment.
So far I’ve only seen glimmers of what the game hopes to be. It’s not polished and lacks the social feature that its Nintendo counterparts have weaved in seamlessly. Despite all these setbacks, it’s still made a huge impact on our culture and technology. I’m excited to see how Niantic plays this out, especially as mixed reality devices like the Microsoft Hololens and Magic Leap come to market.
A couple weeks ago Noel (@noelportugal) and I were invited by the Oracle Apps UX Innovation Labs team to collaborate as technical mentors and judges in BIAC Connected Communities, Connected Lives hackathon.
What would be the best place to hold a hackathon? Cancún. Beautiful weather, beautiful beach, Mexican food, what else could I ask for?
This hackathon was organized around the 2016 Organisation for Economic Co-operation and Development’s (OECD) Ministerial Meeting on the Digital Economy, which discussed topics like innovation, growth and social prosperity.
It was a big event with a bunch of important personalities from politics and economic fields.
The idea of the hackathon was turn ideas into apps, showcase talents and collaborate with peers and technical mentors from all over the world to develop innovative solutions to a local or global challenge.
There were categories like Cultural Heritage, Smart City, Social Inclusion and Entrepreneurship.
Oracle was one of the organizing partners a long with AT&T, CISCO, Disney, Intel, Microsoft and Google.
AT&T was offering $2,000 cash prize and up to 4 nano degrees scholarships from AT&T and Udacity for the best use of the M2X API. Our team had already experience using this API from AT&T’s past hackathons, so we were selected by the AT&T team to mentor and to be judges for AT&T Excellence Award.
Also, we were mentoring and judging for Oracle Excellence Award.
Oracle gave the winners an expense paid trip to Oracle Mexico Development Center in Guadalajara for up to 4 team members; including a tour of Oracle facilities and interviews with senior management.
There were participants from México, Canada and Colombia. Also from all kinds of schools, public and private. Up to 170 developers were participating for the $10K USD grand prize.
The hackathon had excellent vibes. We had a lot of mentoring and support for many teams and team’s ideas were spectacular. Also I could use my little experience with Unity and VR to help out a team that was building VR experiences for kids rehabilitation for people with low income. That team won two categories, Social Inclusion and Disney Excellence Award.
Noel and I also helped with IoT stuff. As you may know (or not), Noel has been a big ESP8266 WiFi module fan for a long time and the hackathon was a good place for advocating that module. I was pleasantly surprised to see teams using the Photon WiFi module for prototyping IoT; our team already had hands on it, and it’s worth a complete post, stay tuned.
This is my first time voting for a winner in a competition, and I have to say it, it’s pretty hard. Noel and I had a hard time deciding the winner for AT&T Excellence Award, but we think we choose correctly based on all arguments.
It was such a great experience participating on the other side of the competition as a mentor and judge, but I couldn’t resist my desire to code 🙂
For more on the event, check out this video made by the Oracle Apps UX Innovation Labs team:
Probably the best way to get to know your users is to watch them work, in their typical environment. That, and getting to talk to them right after observing them. It’s from that perspective that you can really see what works, what doesn’t, and what people don’t like. And this is exactly what we want to learn about in our quest to improve our users’ experience using Oracle software.
That said, we’ve been eager to get out and do some site visits, particularly for learning more about supply chain management (SCM). For one, SCM is an area most of us on the team haven’t spent too much time working on. But two, at least for me–working mostly in the abstract, or at least the virtual—there’s something fascinating and satisfying about how physical products and materials move throughout the world, starting as one thing and being manufactured or assembled into something else.
We had a contact at Micros, so we started there. Also, they’re an Oracle company, so that made it much easier. You’ve probably encountered Micros products, even if you haven’t noticed them—Micros does point of sales (POS) systems for retail and hospitality, meaning lots of restaurants, stadiums, and hotels.
For this particular adventure, we teamed up with the SCM team within OAUX, and went to Hanover, Maryland, where Micros has its warehouse operations, and where all of its orders are put together and shipped out across the world.
We observed and talked to a variety of people there: the pickers, who grab all the pieces for an order; the shippers, who get the orders ready to ship out and load them on the trucks; receiving, who takes in all the new inventory; QA, who have to make sure incoming parts are OK, as well as items that are returned; and cycle counters, who count inventory on a nightly basis. We also spoke to various managers and people involved in the business end of things.
In addition to following along and interviewing different employees, the SCM team ran a focus group, and the AppsLab team ran something like a focus group, but which is called a User Journey Map. With this research method, you have users map out their tasks (using sticky notes, a UX researcher’s best friend), while also including associated thoughts and feelings corresponding to each step of each task. We don’t just want to know what users are doing or have to do, but how they feel about it, and the kinds of questions they may have.
In an age where we’re accustomed to pressing a button and having something we want delivered in two days (or less), it’s helpful on a personal level to see how this sort of thing actually happens, and all the people involved in the background. On a professional level, you see how software plays a role in all of it—keeping it all together, but also imposing limits on what can be done and what can be tracked.
This was my first site visit, though I hope there are plenty more in the future. There’s no substitute for this kind of direct observation, where you can also ask questions. You come back tired, but with lots of notes, and lots of new insights.
Hard to believe it’s been nearly three years since we debuted the Leap Motion-controlled robot arm. Since then, it’s been a mainstay demo for us, combining a bit of fun with the still-emergent interaction mechanism, gesture.
Anthony (@anthonyslai) remains the master of the robot arm, and since we lost access to the original video, Noel (@noelportugal) shot a new one in the Gadget Lab at HQ where the robot arm continues to entertain visitors.
Interesting note, Amazon showed a very similar demo when they debuted AWS IoT. We nerds love robots.
We continue to investigate gesture as an interaction; in addition to our work with the Leap Motion as a robot arm controller and as a feature in the Smart Office, we’ve also used the Myo armband to drive Anki race cars, a project Thalmic Labs featured on their developer blog.
Gesture remains a Wild West, with no standards and different implementations, but we think there’s something to it. And we’ll keep investigating and having some fun while we do.
I previously had my Nexus 5, but over the time, Bluetooth stopped working and that was a good excuse to try this phone.
Also I was so excited because at SXSW I had a long talk with the Nextbit (@nextbitsys) development team about all technology behind this phone, more details below.
So Nexbit is a new company that wants to revolutionize hand held storage and this first attempt is really good.
They came up with Robin phone; it is square, rectangular with tight corners that looks like uncomfortable at first but it has soft touch finish. It has a decent balance of weight. People tend to ask me if this is the modular phone (Project Ara) by Google or if it’s new Lego’s phone. Either way, conclusion is that it has a pretty cool and minimalistic design and people like it a lot.
Talking about its design, power button on the right hand side with is also a fingerprint reader and tiny volume buttons on the left hand side. Probably that’s the worst part of the build; the buttons are small and round and of course kinda hard to press.
The power button does not protrude at all so it’s hard to press too. The fingerprint is actually really good though; accuracy and speed are on point. The fingerprint with the side placement like this, actually makes a lot of sense as you can register your left index finger and right thumb for the way you grip the phone and unlock it as soon as you hold the phone.
It has an USB Type-C at the bottom left corner with quick charging and dual front-facing stereo speakers, loud and clear. Quick charging is awesome.
Running the latest version of Android 6 with a custom Nextbit skin but all elements feel pretty stock.
Specifications are pretty good too, Snapdragon 808, 3 Gb of RAM, 2680 mAh battery, that makes the phone pretty smooth. Camera on the back with 13 MP with decent colors and details but dynamic range is weak.
I noticed that is very slow to actually take the photos, but they just have release new software update that solves the shutter lag.
But let’s focus on what’s the main spec of this phone, storage. All magic is in the Nextbit skin. Every Robin comes with 32 GB on-board storage but then also 100 GB of free cloud storage. Now, you’ll be asking why do you need cloud storage instead on-board storage?
What happens is Robin is supposed to be smart enough to offload the oldest and least frequently used stuff from internal storage straight to the cloud. So when you start to run out of local storage with old apps and old photos that haven’t been opened in a while they will be moved to the cloud and make room for more in your local storage seamlessly almost without you ever having a notice.
Directly in the application drawer you will notice that some app icons are grayed out, so these are the apps that are offline or stored in the cloud and not stored in the device anymore. If you want to use any of them, it takes a minute or so to download everything in the state you last left it in and then opens up right where you left off. So it’s a process of archiving and restoring.
You can also set apps to not get archived swiping the icon app down to pin them, and they will never go to the cloud. If you are using some apps all the time you shouldn’t even need to pin them as Robin will noticed that you use it a lot.
In order to save battery and don’t waste your carrier data, backing up process happens only when the phone is in WiFi and is charging.
Problem is that all restoring is dependent on the internet, so if you are out there with no data and want to use your app that is archived in the cloud, pretty much you’re lost.
In deep details, it has machine learning algorithms, cloud integrated into Android OS and onboard storage is merged with cloud seamlessly. Machine learning mechanism learns from your app and photos usage. Also it can think ahead, so months before you ever run out of storage Robin anticipates you will need more space and continually synchronizes apps and photos. For pictures, they are downsampled to screen resolution but full size version remain linked in the cloud.
For security concerns, all data stored in cloud storage is encrypted with Android built-in encryption.
I like the idea behind Robin system, but the cool thing is that you can use it like a normal phone, you can use your launcher of choice, even root it. The bootloader is actually unlocked out of the box and still under the warranty.
Pretty good phone for the price outside of the storage solution, but if you are looking for a phone focusing on having lots of storage, I’d look for something with a Micro SD card slot. Otherwise it’s definitely worth considering this. Definitely, I would use it as my main phone.
It’s cool to see this type of cloud-based storage solution in action.
Architects design space. A building is just a way to create spaces. Information architects at Oracle design relationships with abstract concepts. So far the main way we have to create visible spaces for our users is by projecting pixels onto glass screens.
This may change someday. If the promise of virtual reality is ever achieved, we may be able to sculpt entirely new realities and change the very way that people experience space.
One sneak peek into this possible future is now on display at Pace Gallery in Menlo Park. Last week the AppsLab research and design team toured the Living Digital Space and Future Parks exhibit by the renowned Japanese art collective teamLab.
Still photographs do not do this exhibit justice. Each installation is a space which surrounds you with moving imagery. Some of these spaces felt like VR without the goggles – almost like being on a holodeck.
The artwork has a beautiful Japanese aesthetic. The teamLab artists are exploring a concept they call ultra subjective space. Their theory is that art shapes the way people of different cultures experience space.
Since the renaissance, people in the west have been taught to construct their experience of spatial reality like perspective paintings with themselves as a point observer. Premodern Japanese art, in contrast, might have taught people to experience a very different flattened perspective which places them inside each space: subjective instead of objective.
To explore this idea, teamLab starts with three dimensional computer models and uses mathematical techniques to create flattened perspectives which then form the basis for various animated experiences. I can’t say that the result actually changed my perception of reality, but the experience was both sublime and thought-provoking.
Their final installation was kid-centric. In one area, visitors were given paper and crayons and were asked to draw spaceships, cars, and sea creatures. When you placed your drawing under a scanner it became animated and was immediately projected onto one of two giant murals. We made an AppsLab fish and an AppsLab flying saucer.
Another area lets you hop across virtual lillypads or build animated cities with highways, rivers, and train tracks by moving coded wooden blocks around a tabletop. I could imagine using such a tabletop to do supply chain management.
Ultra subjective space is a pretty high brow concept. It’s interesting to speculate that ancient Japanese people may have experienced space in a different way than we do now, though I don’t see any way of proving it. But the possibility of changing something that fundamental is certainly an exciting idea. If virtual reality ever lets us do this, the future may indeed be not just stranger than we imagine, but stranger than we can imagine.
Living Digital Space and Future Parks will be on display at the Pace Gallery in Menlo Park through December 18, 2016.