Oculus Go Hands On: One Week With Facebook’s Standalone VR Headset

Last week, Facebook released the Oculus Go, a $200 virtual reality headset. Outside of the initial setup that’s handled with your phone’s Bluetooth connection, this is an entirely standalone device. It doesn’t connect to your PC like the Oculus Rift, and you don’t snap in your phone like you would with the Gear VR. The screen, sensors, radios, and processing power are all inside the Go headset.

For better or worse, we’ve covered a lot of VR tech over the years. The early hype was massive, and the headsets were promising, but the first round of major helmets were something of an anti-climax. Even so, consumer VR isn’t dead as long as giant companies like Google, Amazon, and Facebook keep pumping in a ton of R&D dollars.

I have a generally positive view of the PSVR sitting in my office, but I’m often hesitant to use it because of the elaborate setup process. As such, I’ve been looking forward to the influx of standalone VR solutions for months now, and the Oculus Go is my first real opportunity to try out VR unplugged.

Look and Feel

While the Oculus Go doesn’t cost much in comparison with other VR headsets, the build quality doesn’t seem to be compromised at all. The headset itself is encased in a nice hard plastic, and it feels solid without being heavy. And when the straps are fitted properly, it doesn’t press into your face during long sessions. Intentionally slipping in and out of the helmet is a snap, but it remains steadfastly in place during swift movements.

The part of the helmet that touches your face is padded, and it’s covered in cloth. It’s comfortable to wear, but I wince a little bit when I think of all of the face oils I’m swapping whenever I lend it to a friend. The soft rubbery material used in the PSVR seems, if nothing else, easier to clean thoroughly.

As for the included remote, it feels substantial in the hand – not like some flimsy afterthought. The buttons are nice and clicky, the layout makes sense, and the touchpad is responsive. And while it doesn’t offer the same kind of positional tracking that a PlayStation Move or Oculus Touch would, the movement does feel smooth and precise. The judder we see in other controllers is nowhere to be found here.

Presence

Like most other mobile VR solutions, the Oculus Go can’t really do proper positional tracking, so room-scale VR is entirely out of the question here. The helmet can’t tell if you’re leaning in or out, and that means games like Job Simulator simply don’t work within the limitations of the hardware. It’s disappointing, but that doesn’t mean that the Oculus Go can’t successfully transport you to another place.

The head tracking is impeccable, the 1440p resolution allows for fairly crisp images, and the screen and lenses work together to all but eliminate the screen-door effect. For a $200 standalone device, the tech is quite impressive.

Somewhat amusingly, the most convincing implementation of presence I’ve experienced so far with the Oculus Go has been viewing stereoscopic 360 images of a location I’ve visited dozens of times. Using the Gala360 app, I loaded up a gallery of images from the Longwood Gardens conservatory. Taking in both the crowds and the spectacle of the foliage properly transported me. Of course, some of us aren’t even capable of perceiving stereoscopic images, so your mileage may vary.

[Image credit: Jay Bergesen, edited]

Nausea

Because the fundamentals of the Oculus Go are solid, and it entirely lacks the failure point of outside sensors, it’s not surprising that the Oculus Go didn’t make me hurl. The head tracking worked exactly as expected at all times, so there simply isn’t anything to complain about on that front.

It should be noted that I’m not especially susceptible to motion sickness. Even when other VR helmets have completely freaked out, I’ve never been close to puking. At worst, I felt mildly uncomfortable when the batcave began spinning entirely out of control when my PSVR had a hiccup. With the Go, I haven’t felt even the tiniest hint of nausea.

However, my father regularly suffers from motion sickness, so I had him fiddle about in the Oculus Go for about an hour. Happily, I can report that no lunch was lost, and my dad’s queasiness level barely even registered.

Real-World Captures

There are countless dedicated apps on the Oculus store that deliver 180- and 360-degree videos in both 2D and 3D flavors. Discovery VR, Amaze, and Visbit are solid representations of what’s available, and that’s good news if short documentaries, virtual tours, and slice-of-life experiences are what you’re after.

YouTube is also a treasure trove of 360-degree videos, but the Oculus Go lacks a native client. Even so, simply visiting Google’s video site in the built-in browser allows you to quickly jump into the entire catalog. Similarly, you can get VR porn up and running quite easily right from the browser.

Of course, stereoscopic photography isn’t a new concept, so we have well over a hundred years of relevant media to draw upon. If you want to explore these works of art, Looking Glass VR offers up dozens of stereoscopic photos from the late 1800s and early 1900s, and the effect is stark. Even in grainy black and white, the addition of depth adds a kind of tangible sense to what could otherwise be considered unremarkable photos.

Polygonal Environments

Since we’re more-or-less dealing with smartphone hardware here, it’s no surprise that the polygonal worlds that can be rendered on the fly aren’t pushing the envelope here. And since it’s only $200, nobody would ever expect it to blow the doors off.

Polygonal experiences like Ocean Rift and Tomb Raider VR: Lara’s Escape are perfectly acceptable on the Go, but the fidelity is closer to what you’d expect on an Xbox 360 – not an Xbox One X. We’re still a long way away from high-end games being able to run on an affordable standalone device like the Oculus Go, but that’s not a deal breaker. After all, this headset isn’t being target toward hardcore gamers.

Bot or Not: Identifying Twitter Bots With Machine Learning

I recently happened across this Tweet from Mike Kearney about his new R package called botornot. It’s core function is to classify Twitter profiles into two categories: “bot” or “not”.

Having seen the tweet, I couldn’t not take the package for a spin. In this post we’ll use try to determine which of the Buffer team’s Twitter accounts are most bot-like. We’ll also test the botornot model on accounts that we know to be bots.

Data Collection

The botornot function requires a list of Twitter account handles. To gather the Buffer team’s accounts, we can collect recent tweets from the Buffer team Twitter list using the rtweet package, and extract the screen_name field from the collected tweets. First we need to load the libraries we’ll need for the analysis.

1 2 3 4 5 6 7 8

# load libraries library(rtweet) library(dplyr) library(botornot) library(openssl) library(ggplot2) library(hrbrthemes) library(scales)

This query only returns tweet data from the past 6-9 days.

1 2	# gather tweets tweets <- search_tweets("list:buffer/the-buffer-team", n = 10000)

We can gather and list the account names from the tweets dataframe.

1 2 3

# gather usernames users <- unique(tweets$screen_name) users

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

##  [1] "julheimer"       "julietchen"      "alfred_lua"     ##  [4] "Mike_Eck"        "Maxberthelot"    "davechapman"     ##  [7] "Kalendium"       "thedarcypeters"  "eric_khun"       ## [10] "moreofmorris"    "Brian_G_Peters"  "hitherejoe"     ## [13] "kiriappeee"      "stephe_lee"      "karamcnair"     ## [16] "hjharnis"        "Semakaweezay"    "juliabreathes"   ## [19] "joelgascoigne"   "RoyOlende"       "hailleymari"     ## [22] "ay8s"            "Bonnie_Hugs"     "kellybakes"     ## [25] "emplums"         "hamstu"          "A_Farmer"       ## [28] "tiggreen"        "kevanlee"        "mwermuth"       ## [31] "danmulc1"        "katie_womers"    "suprasannam"     ## [34] "TTGonda"         "bufferreply"     "JordanMorgan10" ## [37] "bufferdevs"      "Ashread_"        "stevenc81"       ## [40] "KarinnaBriseno"  "bufferlove"      "no_good3r"       ## [43] "redman"          "courtneyseiter"  "goku2"           ## [46] "josemdev"        "twanlass"        "FedericoWeber"   ## [49] "CaroKopp"        "parmly"          "natemhanson"     ## [52] "michael_erasmus" "hannah_voice"    "ariellemargot"   ## [55] "djfarrelly"      "toddba"          "jntrry"         ## [58] "nystroms"        "BorisTroja"      "nmillerbooks"   ## [61] "mickmahady"      "ivanazuber"      "_pioul"         ## [64] "OCallaghanDavid"

Great, most of the team is present in this list. Interestingly, accounts like @bufferdevs and @bufferlove are also included. It will be interesting to see if they are assigned high probabilities of being bots!

The Anti Turing Test

Let’s see if the humans can convince an algorithm that they are not bots. Before we begin, it may be useful to explain how the model actually works.

According to the package’s README, the default gradient boosted model uses both users-level (bio, location, number of followers and friends, etc.) and tweets-level (number of hashtags, mentions, capital letters, etc. in a user’s most recent 100 tweets) data to estimate the probability that users are bots.

Looking at the package’s code, we can see that the model’s features also include the number of tweets sent from different clients (iphone, web, android, IFTTT, etc.), whether the profile is verified, the tweets-to-follower ratio, the number of years that the account has been on Twitter, and a few other interesting characteristics.

I’ll obfuscate the Twitter handles for privacy’s sake, but they can easily be found by reproducing the steps in this analysis or by using a MD5 reverse lookup.

The following code calculates the bot-probabilities for the Buffer team’s accounts and sorts them from most to least bot-like.

1 2 3 4 5 6 7 8 9 10

# get bot probability estimates data <- botornot(users)   # hash the usernames data$user_hash <- md5(data$user)   # arrange by prob ests data %>%   arrange(desc(prob_bot)) %>%   select(-user)

1 2 3 4 5 6 7 8 9 10 11 12 13 14

## # A tibble: 64 x 2 ##    prob_bot user_hash                       ##       <dbl> <chr>                           ##  1    0.999 3ff40b69a60e6210f3cbda8db1cb4ae2 ##  2    0.989 3e921417f41b66f1c24862710537f192 ##  3    0.985 d093563010eedd85801769f91909265d ##  4    0.964 712a4384e6681bd521c5266e16789c29 ##  5    0.906 0edb7ec9098076761bd14c9c3ca97bd3 ##  6    0.899 6ed84e511f386eb4942cfab089b02602 ##  7    0.897 db82005412c13e740c03860b29aec7b7 ##  8    0.894 8dc5886d5c56e75b89ab191e0e5958cd ##  9    0.891 a1d8e95101f88a8d7ef65d5106b7183c ## 10    0.868 fa3d30c0919008e2ab8b5e87192a13ac ## # ... with 54 more rows

The model assigns surprisingly high probabilities to many of us. The account @bufferlove is assigned a 99.9% probability of being a bot – the @bufferdevs and @bufferreply accounts are also given probabilities of 90% or higher. Verified accounts and accounts with many followers seem less likely to be bots.

Working for a company like Buffer, I can understand why this model might assign a higher-than-average probability of being a bot. We tend to share many articles, use hashtags, and retweet a lot. I suspect that scheduling link posts with Buffer greatly increases the probability of being classified as a bot by this model. Even so, these probabilities seem to be a bit too high for accounts that I know not to be bots. 

Let’s gather more data and investigate further. We have tweet-level data in the tweets dataframe – let’s gather user-level data now. We’ll do this with the search_users function. We’ll search for users with “@buffer” in their bio and save it in the users dataframe.

1 2	# search for users users <- search_users("@buffer")

Once we have the user list, we can join users to the data dataframe on the screen_name field.

1 2 3

# join dataframes buffer_users <- data %>%   left_join(users, by = c("user" = "screen_name"))

Let’s see how the probability of being a bot correlates with the number of followers that people have. We’ll leave our CEO, Joel (@joelgascoigne), out of this since he is such an outlier. He’s too famous!We can see that there is a negative correlation between follower count and bot probability. This makes sense – bots seem less likely to have lots of followers.

Now let’s look at the relationship between bot-probability and the percentage of Tweets sent with Buffer. First we’ll calculate the proportion of tweets that were sent with Buffer for each user.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

# get Buffered tweets for each user by_user <- tweets %>%   mutate(sent_with_buffer = source == "Buffer") %>%   group_by(screen_name, sent_with_buffer) %>%   summarise(buffered_tweets = n_distinct(status_id)) %>%   mutate(total_tweets = sum(buffered_tweets),          percent_buffered = buffered_tweets / sum(buffered_tweets)) %>%   filter(sent_with_buffer == TRUE) %>%   select(-sent_with_buffer)   # join to buffer_users dataframe buffer_users <- buffer_users %>%   left_join(by_user, by = c('user' = 'screen_name'))   # replace NAs with 0 buffer_users$buffered_tweets[is.na(buffer_users$buffered_tweets)] <- 0 buffer_users$percent_buffered[is.na(buffer_users$percent_buffered)] <- 0

The plot below shows the relationship between the probability of being a bot and the percentage of tweets Buffered.

We can see that there is a positive correlation between the proportion of tweets Buffered and the probability of being a bot. This is interesting, but not totally unexpected.

Definitely Bots

Now it’s time to see how the model does with accounts we know to be bots. I gathered some names from this site, which maintains a few lists of Twitter bots.

1 2 3 4 5 6 7 8 9

# list bot accounts bots <- c('tiny_raindrops_', 'KAFFEE_REMINDER', 'MYPRESIDENTIS', 'COLORISEBOT', 'OSSPBOT',             'GITWISHES', 'SAYSTHEKREMLIN', 'NLPROVERBS', 'THEDOOMCLOCK', 'DAILYGLACIER')   # get botornot estimates bot_data <- botornot(bots)   # view prob ests bot_data %>% arrange(desc(prob_bot))

1 2 3 4 5 6 7 8 9 10 11 12 13

## # A tibble: 10 x 2 ##    user            prob_bot ##    <chr>              <dbl> ##  1 tiny_raindrops_    1.000 ##  2 thedoomclock       0.998 ##  3 GitWishes          0.998 ##  4 MyPresidentIs      0.998 ##  5 kaffee_reminder    0.996 ##  6 osspbot            0.994 ##  7 saysthekremlin     0.987 ##  8 NlProverbs         0.983 ##  9 colorisebot        0.966 ## 10 dailyglacier       0.872

Surprise! They all have been assigned very high probabilities of being bots, because they are bots. The “tiny_raindrops_” account is 100% a bot.

Conclusions

We had a fun time playing with this package – thanks for following along! I could imagine something like this being used as a weighted input in a spam prediction model in the future, however the botornot model is imperfect as-is. We’ll continue to have some fun with it and will have to consider making some tweaks before putting it into production.

Thanks for reading! Let me know if you have any thoughts or questions in the comments below!

post credits: bufferapp