Hi everyone,
I was toying around with the idea of having an entire robot’s processing within a webpage – both for the purpose of educational simulations, as well as using phones as the brains of a simple robot without going through the mess that is native programming.
So I came up with this prototype of roslite.js – at the moment it’s just a publisher/subscriber interface:
Here’s a demo of it in action, intended to be run on an Android phone, that contain 4 nodes. Note that all nodes run in a single thread in an event-driven fashion.
- imu_node, which publishes the phone’s IMU data to /imu/data
- gps_node, which publishes the phone’s GPS data to /gps/fix
- echo_imu, a node that subscribes to /imu/data and echoes to the web page
- echo_gps, node that subscribes to /gps/fix and echoes to the web page
Demo (it will ask you for location permissions, for GPS):
https://dheera.github.io/roslite-demo/
Other ideas for nodes:
- A motor node! Use the phone to control motors over Bluetooth using the web bluetooth API, as I have run here, although this doesn’t yet use roslite.js: https://github.com/dheera/robot-tethys/
- Motor node that control motors using the headphone out port for left/right PWM signals, or over Wi-Fi to an IP-based motor controller
- Bluetooth access to a million other BLE sensors
- Access to IoT sensors over Wi-Fi
- Camera node that just uses the phone’s camera
In short, I feel like a full-blown robot brain could be made from within the web browser.
Questions to the community:
- Do you find roslite.js interesting? If so, why?
- Do you see value in writing robotics code in JavaScript?
- At the moment it’s just a publisher/subscriber interface, but what other features from ROS would you want to have in something like roslite.js? e.g.
- tf2
- service calls
- visualization tools for simulated educational robots in the browser
- console commands, e.g. rostopic echo, rostopic pub, rosnode list, etc.
- parameter server
- ability for a centralized server to connect to multiple remote ROS masters running on phones
- infrastructure to offload processing loops of nodes to Web Workers (downside: web workers can’t access the UI or sensors, but they can do heavy lifting e.g. simple SLAM algorithms) – note that ALL nodes run together in a single thread if you don’t use Workers so you need to avoid blocking operations