Giter Club home page Giter Club logo

robotmoose's Introduction

RobotMoose Web Robotics System

Join the chat at https://gitter.im/robotmoose/robotmoose

This is a simple, modern version of a networked robotics stack, built around the modern web. The major pieces are:

  • A web front end for user friendly robot setup, teleoperation, and programming. See www/js for the code, which is built in JavaScript on bootstrap.
  • A central JSON server called superstar, used by the robot to make its sensor values available to the front end (as /superstar/robotname/sensors), used the by the front end to post robot commands (at /superstar/robotname/robots), and used for persistent storage as well. See superstar/ for the code, which is built in C++ on Mongoose, but the HTTP get and set commands can be sent from any language, and is conceptually similar to MongoDB.
  • An on-robot back end, that relays superstar commands to the robot hardware, and keeps track of the robot location. See tabula_rasa/chromeapp for an easy to use RobotMoose chrome app GUI; or tabula_rasa/ for a command line C++ backend.
  • A runtime configurable Arduino firmware, which allows new robot hardware to be added at runtime without re-flashing or editing the code.

The typical usage model puts the front end on the robot pilot's web browser, superstar on a cloud server accessible from anywhere, the backend on a laptop onboard the robot, and the Arduino directly wired into the robot hardware. But you can run all the software on a single low-end laptop for a network-free version, or use a dedicated superstar on a closed network, or many other permutations.

Installation and Setup

To get started with a simulated robot, just visit robotmoose.com/robots/, and click the "Simulate a Robot" button. This will let you get a general sense of how the website works.

Firmware Installation and Physical Backend

You need Google Chrome to run the backend, the version control system git to get this code, and the Arduino IDE to flash the Arduino firmware.

Windows:

macOS:

Ubuntu:

  • Terminal command: sudo apt-get install git arduino

Now open Terminal (macOS/Ubuntu) or Command Prompt (Windows), and run this command to download the code:

git clone https://github.com/robotmoose/robotmoose

On Ubuntu, you'll need to run this command to give yourself access to serial devices:

sudo usermod -a -G dialout $USER

You'll need to log out and log back in to be in the new group.

Now plug in the Arduino and open the Arduino IDE. Open the project at robotmoose/tabula_rasa/arduino/arduino.ino, and click the upload button.

You can double check the installation by opening the Arduino as a serial port at 57600 baud. You should get a welcome message.

Open Chrome, and install the backend app. Open the backend app, enter your year/school/robot info, and click connect.

You can now use the web interface to configure and pilot your robot!

Configure and Pilot your Robot with the Web Front End

You access the main robot web interface at http://robotmoose.com/robots/.

  • Connect to the school ("test") and robot name ("yourbot") you gave the backend above.
  • Configure the robot in the "Configure" tab by selecting a piece of hardware and hitting "Add". I always start with a "heartbeat" so I can verify communication works. Hit "Configure" to copy this configuration to the Arduino.
  • Check the "Sensors" tab to see the data sent back by your robot. The "heartbeat" is a number that counts up from 0 to 255 again and again, so you can see the Arduino is connected. The "location" is a guess of the position of the robot, and is updated as the robot moves.

There are many options for robot driving hardware (tabula_rasa/arduino/motor_controller.cpp) supported by this system. Once you configure any of these robot motors, the "Drive" tab will gain a set of arrows allowing you to drive the robot!

  • "create2" is a serial connection to an iRobot Create 2 or 500/600 series Roomba. Arduino Pin 2 should be wired into the serial port wakeup line (otherwise when you press "Configure", you may need to press the Roomba's power button to wake up the Roomba, or the Arduino will sit waiting for the Roomba to connect).
  • "bts" represents two BTS 7960B motor controllers, used to drive the left and right wheels of your robot. There are four pins listed, two PWM pins for each motor. (Tie the BTS's VCC and EN lines to Arduino 5V, and the GND line to Arduino ground. You can leave the IS pins unconnected.)
  • "sabertooth2" is a Dimension Engineering SaberTooth dual motor controller, version 2. You set the serial port that sends serial commands to this device. (Set address 128, packetized serial format, 9600 baud)
  • "sabertooth1" is a Dimension Engineering SaberTooth, version 1. (Set simple serial format, 9600 baud)

There are also several robot peripherals supported:

  • "pwm" is a pulse width modulated (PWM) pin, which can be used to smoothly vary the brightness of an LED. For example, pin 13 is the standard Arduino LED, so you can control it by adding a pwm device on pin 13, and dragging the brightness slider around. This is a good first project to try!
  • "servo" is an RC servo, like with a model plane. You can hook the servo's white control wire to any Arduino pin, and power the red from 5v and black to ground. In the "Drive" tab, you set the servo position in degrees, from 0 to 180 degrees.
  • "analog" reads an Arduino analog pin, like A3. The read value will show up in the Sensors tab.
  • "neato" is a Neato XV-11 laser distance sensor, which uses a laser to measure distance in a 360 degree plane around the robot. You give a serial port to read the neato's serial data distance reports, and a pin to control the neato's motor power via a transistor.
  • "latency" measures the Arduino firmware's control loop latency, in milliseconds. It should normally read 1 millisecond.
  • "heartbeat" is incremented every 10ms by Arduino firmware. If you can see this number changing in the "Sensors" tab, you have connectivity between the web front end, superstar, backend, and Arduino. If this number stops changing, something has been disconnected.

Making a Superstar

For most tasks, it's best to use UAF's main superstar server (http://robotmoose.com/superstar/). But if you don't have reliable internet access, or want to change our web user interface code, you need your own local superstar server. These instructions assume you're running macOS or Ubuntu, with basic dev tools installed.

To make and run your own local copy of superstar:

cd ~/robotmoose/superstarv2
make
./superstar > log &

When you first start your superstar, you will not have an admin password, or have any robots. You will need to create them by using the superstar utility programs:

cd ~/robotmoose/utils/superstarv2
./starpasswd.py -s localhost:8081
./make_robot.py -s localhost:8081  2018/testschool/testbot

That starpasswd command creates an admin password.

That make_robot command creates a robot named "testbot" at "testschool".

(If you have password problems, the password paths and hashes are stored in a plain text file named "robotmoose/superstarv2/auth".)

Start a robot backend and connect it to this local interface by changing the "robotmoose.com" dropdown to "127.0.0.1:8081".

You should now be able to point your web browser to http://localhost:8081/robots/ and see your local copy of the web user interface. Edit the files in ~/robotmoose/www/js and hit reload to modify the interface. You can also manually examine the entries in http://localhost:8081/superstar/ to see how the robot configuration, sensor, and pilot information is exchanged, using superstar get and set operations.

Using the entire robotmoose system on your local network, with robots on different machines accessing your local superstar, requires a few extra steps:

  • First, you must note the local IP address of the machine running your local superstar (for example, "192.168.1.24").
  • Next, you must add this IP address to the Chrome App:
  • Finally, you must load the modified chrome app onto all of the backend computers:
    • Copy the modified chromeapp folder tabula_rasa/chromeapp and its files to the backend computer(s).
    • Go to chrome://extensions/, click the developer mode checkbox. If you have already loaded the chrome app from the git before, you will have to remove it because of the changes to manifest.json.
    • Click "load unpacked extension", browse to the chromeapp folder, then click ok.
    • When you launch the chrome app, the IP of your local superstar should appear in the backend dropdown!

Fun Tricks

The superstar server has been tested with up to ten robots and pilots connected. Normally, each robot has a unique name, which allows the pilot to control it.

If you give several robots the same name, the pilot interface jumps between their sensor data as they report it, which isn't very useful. But all the robots read the same pilot commands, so they move together like synchronized swimmers!

If several pilots connect to the same robot, they all see the same sensor data, but the pilot's commands overwrite each other, which makes for very jerky driving.

Debugging

The real trick with debugging is slowly and systematically looking at what is happening.

Problem: Arduino permission error

If you have an Arduino permission problem, flashing the Arduino from the command line (cd ~/robotmoose/tabula_rasa/arduino; make) will error with:

avrdude: ser_open(): can't open device "/dev/ttyACM0": Permission denied
ioctl("TIOCMGET"): Invalid argument
ioctl("TIOCMGET"): Invalid argument

Even if you manage to flash the Arduino, if you have a permission problem the backend will hang when connecting to the Arduino:

Uploading new config to arduino!
Arduino startup:

A temporary fix is to force the Arduino device to be readable and writeable, but this will need to be repeated every time you unplug the Arduino:

sudo chmod 777 /dev/tty[UA]*

The permanent fix for both problems is to make all serial devices readable and writeable by your user account:

sudo usermod -a -G dialout $USER

You'll need to log out and log back in to be in the new group, and then any Arduino should work correctly, permanently.

Problem: Internet Connection Error

The backend needs a network connection to the superstar server, or you will get errors like this:

Connecting to superstar at http://robotmoose.com/
terminate called after throwing an instance of 'skt_error'
  what():  Invalid domain name: 'robotmoose.com'

Check that the wireless network is connected correctly. Can you reach google from the backend laptop?

Problem: Robot does not drive

Things to look at:

  • Are you getting a heartbeat in the "Sensors" tab? If no heartbeat is listed, configure one. If the heartbeat is shown but not counting, the problem is either the backend or the Arduino. Is the backend laptop running, and does it have internet? Is the backend running, and does it display any error messages? Is the Arduino plugged in?
  • Is the Roomba running? If the heartbeat is running but the "light" sensors are not changing, you may need to go to the "Configure" tab and hit Configure again to restart the Roomba. Also check the Roomba battery in the "Sensor" tab; a Roomba with a low battery will not drive.

Problem: Superstar compilation fails with "Missing dependency operator"

If you get an error similar to this when you try to make Superstar:

make: "/usr/home/christopher/Code/robotmoose/superstar/Makefile" line 7: Missing dependency operator
make: "/usr/home/christopher/Code/robotmoose/superstar/Makefile" line 9: Need an operator
make: Fatal errors encountered -- cannot continue
make: stopped in /usr/home/christopher/Code/robotmoose/superstar

The problem is that Superstar's Makefile uses GNU make-specific features. To solve the problem, install gmake on your system (if it's not installed already), then run gmake instead of make.

Project Background

This is an NSF-funded ITEST research project, with full name: Collaborative Research: ITEST-Strategies: Human-Centered Robotics Experiences for Exploring Engineering, Computer Science, and Society

robotmoose's People

Contributors

arsh25 avatar finetralfazz avatar grubbly avatar hoyr avatar michaeasmith avatar mrmoss avatar olawlor avatar permutationlock avatar raikadial avatar ryanstonebraker avatar woodchip-dev avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

robotmoose's Issues

Utility to copy robots

Script or utility to create new robots from already existing robots. Ideally, the user will be able to specify what they want copied.

Eg: Make new KT's from a demo KT and copy over only the config or the config and example code.

Blockly drag-and-drop programming

It'd be awesome to be able to use Google's Blockly to support drag and drop programming.

We need to keep the ability to switch back and forth to plain JavaScript.

Android App

Import from Kanban.

Robotmoose Cordova Android App.

Presence Sensing

Import from Kanban board.

Be able to know where people are based on sensor data.

Chrome App leaks sockets (sometimes)

The backend can enter a state where Chrome just says "Waiting for socket" when connecting to robotmoose, probably due to leaked sockets (in "getnext"?).

This was observed after 15 minutes on a Windows 10 box, with several disconnects/reconnects.

See which pilots are watching robot

The frontend should display which pilots are watching your robot while you're driving.

(Low-priority feature request, for AFTER workshop)

Backend causes apache to lock up

Something about having many robots connected causes apache to need a restart. This is not good for a reliable production system.

It's possible this is related to proxying our comet-style getnext requests. If this is fixable in the apache config file, we should do that and document it so other people can use the same fix. If it is not fixable, I'd be tempted to change our getnext implementation, since apache is a sort of default web server, and our software should work with it.

Federate Superstars

Creation of local Superstars to allow local Superstars to communicate with parent nodes.

Video Disconnect Heartbeat

Use the same underlying heartbeat infrastructure for use with the video dropdown. If video is being viewed, update the heartbeat. If video is not being video, don't update the heartbeat.

Finish device wheel_encoder

The device wheel_encoder has been partially implemented on the chrome backend, complete this so that positioning actually works.
The device consists of 2 hall effect sensors and a wheelbase.

Backend uses a lot of network

Look at the backend network traffic, and 4 times per second there's a "?sub" request for the year, school, and robot name. This is way too often.

UI tab needs to be brought up automatically

When I click "run" on a code sample that uses buttons or labels, the UI tab should immediately be shown and brought to the top. Needing to know it exists breaks the flow with the code.

Code editor shouldn't auto-indent

By default, the editor indents every line unless it has a semicolon. Since we're not making students use semicolons, this gets irritating for them.

Old Superstar on Backend

Backend uses the superstar you had selected the last time you closed (saved) rather than the one you actually have selected.

Per-robot chat room

To coordinate backend and frontend, having a little chat room visible to everybody would help a lot.

Sim on backend app

Add KT simulation functionality to backend app.

As a side note, teachers expressed to me that they loved letting the students practice driving in a simulation.

Can't hit UI buttons during delay()

In code interface, if you make a button in a state with a delay, the button will not work unless you time it so your press is not during a delay.

Formalized QA/testing and deployment process

Normally, we move fast and break things, and that works fine -- until it doesn't, and we're making last-minute changes to try to fix things we broke with our previous last-minute changes. When the infrastructure is broken, we look bad, and when we look bad, people are less likely to work with us.

Here's a (maybe excessively bureaucratic) policy example I came up with:

  • Every commit to master is automatically deployed to test.robotmoose.com using GitHub webhooks.
  • Changes which have been tested and verified to work (by someone other than the author) are merged into a production branch.
  • Deployments to robotmoose.com from the production branch happen on a set schedule.
    • Production deployments should only happen outside of that schedule in an emergency situation (a critical feature is broken, etc.)
    • Production deployments are the responsibility of one person, and nobody else should do them unless it's both an emergency situation and the regular deployment person is unavailable.
  • Superstar's database should be backed up prior to every deployment, so it can be rolled back if needed.

My proposal isn't necessarily the one we should use (for example, I know most of you hate branches), but I think we're reaching a point where we need to have something in place.

(Also, I realize this doesn't belong on the bug tracker, but it's hard to write in detail on the Kanban board, and we don't have much else in the way of group communication. Emailing everyone seemed excessive.)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.