Cloud Robotics vs. Safety

So, with Google also now pushing cloud robotics, it seems likely to get more and more attention. However, I want to see more discussion of safety on the matter.

I mean, didn't we already have a Will Smith movie implying safety risks for combining the internet with robots? Robot perception is linked with behavior, and if either perception or behavior can be downloaded at any moment, there had better be some serious safety mechanisms outside of any such easy cloud intelligence.

There really needs to be some underlying primitive coping level that enforces certain levels of safety, there needs to be serious levels of "don't dare touch this without top security clearance" baked in.

As long as we are talking toys, maybe it's not a big deal, but anything strong enough to do real work is strong enough to cause damage, and that needs secured.

Native ROS (Robot OS) for Java ... and MATLAB?

So, Google and Willow Garage just announced about an alpha-status pure Java implementation of ROS, the robot operating system (from Willow Garage). ROS in some ways is just another messaging system, and there are already about five billion of those in Java. However, it's also getting serious traction from all over the robotics community, has lots of ready-made robot awesomeness, and nicely seems to be overshadowing non-open competitors in robot middleware.

They are pushing it as a solution for Android. Android-brained robots are cool, but in our lab (and others), we use MATLAB a lot. There presently isn't any stable support for MATLAB is ROS, just GNU Octave. We have connected ROS with MATLAB, but the software hasn't been much more stable than the official support from Willow. Though I've been dodging Java since the Oracle lawsuit, I'm seriously planning to try out the new rosjava as a MATLAB option. MATLAB integrates easily with Java. Just import packages/classes, and use them.

As a side note, it seems like the new rosjava (unlike normal ROS) supports multiple nodes per process. I'll have to see if I can work multiple Java threads into communication with the main MATLAB thread ...

WebGL not there on Firefox, either

I recently lamented the lack of general support for WebGL in Chrome. Here's what Mozilla says about the state of Firefox WebGL. Google says they are working on a software renderer for Chrome.

However WebGL reaches the masses, I have to say that it's not there yet. I'd consider it an early adopter technology at best. Would it have been better to focus on older OpenGL features to reach everyone today? Or is it better that they focused on the current modern, so that we don't regret old lock-in later? Whatever is best, I think WebGL will be safe to use for most of the web in about 5 years or so. I say five years because we need time for implementations to stabilize, support more drivers, use software rendering effectively, old computers to get replaced, and so on.

That's my guess. Five years. So 2016, I guess. (And I'm ignoring IE. I consider IE only as relevant as Microsoft wants it to be, by playing nice with everyone else.)

We'll see if I'm being too conservative.

But 2016 is still cool. Arbitrary 3D awesomeness. And I suspect JS will run very close to native speed by then, too.

What platform are you targeting for 2016?

Bullet in JS

I've recently found node.js bindings for Bullet and a JS port of JBullet. I'm not sure whether either supports hinges or capsules or other things I like. Lousy LGPL on that port. Not sure about the license on the bindings.

Or maybe JigLibJS is the right thing to try?

Maybe robot sim in browser will come before too many years.

Chrome WebGL a no go, methinks

So, Chrome has WebGL on by default ... if you have hardware OpenGL 2.0 support, so far as I can tell. Well, I suppose modern Direct3D support on Windows would also suffice, given their ANGLE compatibility library.

One of the Linux computers I use regularly has no such support, so WebGL content doesn't render at all. Said computer is a little over two years old, so I suspect I'm not the only one with problems.

Saying "Sorry, the web doesn't work on your fairly modern computer" isn't good enough.

Until WebGL just works on everyday computers and handhelds across Chrome and Firefox and Safari (and Opera?), it's a no go for me.

Anyway, if I'm misunderstanding the state of Chrome WebGL support, let me know, but for now it's just vaporware in my book.

Web server in CoffeeScript and Node

So, here's a first stab at a web server using CoffeeScript and Node:

# Imports.
{createServer} = require 'http'
{parse: parseUrl} = require 'url'
{readFile} = require 'fs'
{resolve} = require 'path'

# Setup.
base = "#{resolve('.')}/"
log = console.log

# Server definition.
server = createServer (request, response) ->
  reqPath = parseUrl(request.url).pathname
  filePath = ".#{reqPath}"
  status = 500
  respond = (content) ->
    response.writeHead status,
      'Content-Length': content.length
      'Content-Type': 'text/html'
    response.end content
    log "#{request.method} #{reqPath} #{status}"
  # Verify the path is local to the base!!!
  # TODO Better startsWith
  if resolve(filePath).indexOf base
    # TODO status = forbidden?
    respond("")
    return
  # Handle the request.
  if request.method is 'GET'
    readFile filePath, (err, data) ->
      if err
        if err.errno is 2
          status = 404
        data = ""
      else
        status = 200
      respond(data)
  else
    respond("")

# Start the server.
port = 8080
server.listen port, ->
  log "Running on #{port} from #{base} ..."

Not so bad. Probably could be cleaned up. I get tangled in CoffeeScript sometimes, but usually it's straightforward.

I don't drink coffee, but this is nice little scripting all right.

Python import angst

I've said it before, and I'll say it again, Python importing stinks. Either you corrupt your module namespace, or you put imports in all your individual functions. Both are horrible options.