Rebuild and upload teensy software

$ roscd linorobot
$ cd teensy/firmware
$ pio run --target upload -e <platform>

Where currently platform is either teensy31 (Plarform2) or teensy41 (Platform1)

Raspicam

• We use a RaspberryPi v1 camera whose full documentation can be found at Raspicam Docs, this also includes hardware and software specs

• Additional information on how to install Raspicam hardware can be found at

AprilTags

• We use the pupil_apriltags package to detect fiducials in the Raspicam image so full documentation for the AprilTags can be found at

• The package works by taking the camera parameters, fiducial size and family, and additional fiducial detection parameters and creating a detector class which contains a detect method that inputs a camera frame and outputs a list of detected fiducials

Parameters and Tuning

• The params.yaml file contains all of the fiducial vision parameters

• The camera parameters which are used in the params.yaml file were found online in the raspicam section

• The size of the fiducial in meters can be adjusted by printing out new fiducials of a larger size

Transformation Math

• The src/transforms.py and src/geometry.py contain the methods used for transforming the fiducial detection results into easier to work with translations and rotations

• Also, parameters in params.yaml are used to slightly adjust the detection results after transformation

The robot was donated by the Hands-On Robotics Initiative. Due to time constraints and some delays, a prebuilt robot was delivered instead of a parts kits. The build instructions can be found on this Google Doc. It also includes other relevant instructions that will be referenced later, such as motor calibration, software installation and run instructions.

Hardware Overview

Default hardware (robot)

The robot consists of 12 C610 motor controllers, 12 M2006 motors, a Teensy board, cables and the chassis.

Additional hardware

• Raspberry Pi

• Raspberry Pi Camera

Battery Charging Settings

The battery charger in the lab supports charging the 6S Lipo Battery. Settings can be found below:

The batteries took around 1 hour to charge and last around 2-3 hours per charge.

The USB Battery Pack used was a generic one that provided enough voltage for the Pi. These are usually battery packs that support fast charge technology for smart phones. An appropriate cable is needed (e.g: USB 3.0 to Micro-USB or otherwise)

Calibration Tips

• Motor calibration can be found in the . The robot's casing may have to be opened to access some of the motor controllers.

• Instructions for leg calibration can be found . Best results were achieved by supporting the robot with a box and adding paddings (made of paper towels and tape) between the legs and the box to get desired motor angles.

Pupper Base Software Setup

Instructions for the base software setup can be found in the doc. See notes section for project-specific instructions.

Notes on the setup doc

• 3.c: en1 might not exist on the Pi. To find out which network interface to use run sudo ifconfig and look at the first interface it lists. For this project, it was eth0.

• 4.d.ii: Although it says Mac/linux, this is not always the case. If ls /dev | grep tty.usbmodem shows no results try ls /dev | grep ttyACM

Running base software

Follow instructions . The keyboard program mentioned can be found .

Setting up this project

Install the dependencies using pip:

Dependencies

• picamera

• pupil_apriltags

• tqdm

Running

The full software can be run using python main.py, or the controller can be run separately using python3 src/controller.py.

When a new robot is built, there are a number of steps needed to see that it is properly configured.

Encoders

Encoders need to be connected correctly. The left and right can be swapped, and also they may be backwards. These issues lead to very crazy and incomprehensible behavir, so it's best to check them first if your new robot is acting weird.

Motors

Motors also need to be connected correctly. They can be left-right swapped or forward-reverse swapped. It is worth again to test them separately. The kind of incomprehenible behavor from this kind of problem is totally different from the one when the encoders are backwards or swaps.

Front and back

It is very important that you know what the front of the robot is. Otherwise nothing makes sense. Our robots have the big wheels in front and the casters in back.

IMU

The IMU is connceted via an I2C Quick Connector to the Teensy. We have seen problems when the IMU doesn't work that were caused by the placement or length of the wire, so keep an eye out for that case.

linobase.h Pins

The most common problem with a new build is that the pin numbers are incorrect. You can find the hardware configuration in linorobot/teensy/firmware/lib/config/lino_base.h. In that same directory you will find other versions of that file for our different models. If you are qualifying a new model, then you should add a copy there.

There are numberous variables in this file. The key ones for now are:

and

MOTOR1 is front left, and MOTOR2 is front right. There are several misconfigurations possible, basically all the permutations of left/right and forward/backward, on both the motors and encoders.

Symptoms

If all wheels are spinning but the robot spins in circles, goes backward, is unresponsive to cmd_vel commands or in general acts crazy, your first hypothesis should be that one or more of the pins above are incorrect or swapped.

If one of the wheels doesn't spin at all then it's probably an electrical connection to the motor. If both wheels don't spin then it's probably a power/battery issue.

Erratic Travel on a newly built robot

Check Encoders

To check the encoders, disconnect the power from the motors, leaving just the encoders. Then when you roslaunch linorobot minimal.launch it will print four numbers over and over again which are the readings of the potential for encoders (two in front and two in the back.)

As I had only two wheels I just got two non-zero numbers. Put the robot on the floor and push it gently forward. Those two numbers will change. They should both go up approximately as fast, even though they are not the same number. In my case, they went in opposite directions. Note the one that is going down. The left wheel is encoder1 and the right wheel is encoder2. In the setup file I switched the pins for the corresponding motor and that solved it.

(Note: This is very obvious but I got it wrong: The caster is on the BACK of the robot not the front. You need to know what is the front of the robot to know which wheel is left or right.)

Check Motors

For me, this didn't quite solve it. So the next thing to check was the motor itself. I changed the Arduino code (.ino) so that instead of sending the calculated numbers to the motors, I sent 100 to the left motor and 500 to the right motor. This is so that I could tell if the left motor turned slower than the right. If not, I had to switch those pins. Next I had to tell that both motors turned so that the effect was forward motion of the robot. That was incorrect for me too. That too is fixed by switching PIN numbers.

Check PID

Next came the PID settings. The instructions are good there in terms of getting monitoring the result of the pid calculations but not as far as what numbers are right. There are an infinite number of references on the web on tuning pid and they are all vague and different.

Here again I made a small change to the Arduino code. I had it print out the error between the desired and actual rate of the left and right wheels. If things are working like they should that error starts at zero and when you give the robot a command it temporarily goes away from zero and then returns nicely to zero. I don' know yet what "technique" I used, nor whether I have the right parameters yet. But at least the robot is behaving better.

Over the years we've built up a varied collection of robots. Some are no longer in use and several types still are. This section contains a lot of the robot specific details. Today the main robots we use are the TurtleBot3 from Robotis and the home grown Platform line.

TurtleBot3 - Robotis

These have been our workhorses. They are robust and don't seem to break much. Probably because they are pretty musch standardized from the factory

Platform - Brandeis

These robots are homegrown, hardware design and manugacture by Charlie Squires and software stack based on the teensy

Intro to LinoRobot

Intro

Examine Linorobot again. You will see very detailed instructions for building a robot, both the hardware and the software. In our world, bullet, platform, cat are all fully compliant Linorobot robots.

Base hardware stack

• For the SBC we use either a Rasperry Pi 3B+ or a Raspberry Pi 4

  • Lidar is connected via USB to the Raspberry Pi

  • The Microcontroller is connected via USB to the Raspberry Pi

SBC Software

The SBC is running Ubuntu 20.04 and ROS 1.0. It is a standard install which we get from the Linorobot installation. Of course our own ROS code and scripts are then added to it. Certain standard Linorobot Nodes are launched.

Standard Linorobot Nodes

Microcontroller Software

The Teensy code is provided by Linorobot. We have tweaked it in small ways. See for information on rebuilding it and installing the software. This software has the following jobs:

1. Read the encoders to determine the apparent speed and direction of the robot

2. Subscribe to cmd_vel to determine the desired speed and direction

3. Use a PID controller to drive the motors to meet the desired speed and direction

• Consistent across Platform 1, 2 and 3?

• Raspberry Pi 4b

  • Arduino Teensy 3.1

  • MPU 9250 IMU

  • YDLidar X4

GoPiGo3 Basic Kit

We recommend that you start with a GoPiGo3 Basic Kit. Build it following the instructions. There is a lot written and a lot to google about it. Here are some useful links:

• Dexter Forum - where you can get many questions answered

• - where you find step by step instructions.

• - instructions for students taking Cosi119a at Brandeis University to order a miniRover.

In addition to what you received with the Basic Kit you will need the following to get through the instructions.

• A Raspberry Pi 3+

• A battery pack (with Y-cable and charger)

• A MicroSD card

The Battery pack is different from what the instructions talk about. The Y-Cable is used to connect the barrel connector of the battery pack with the corresponding battery connector on the "Red Board" which in turn will power the Raspberry Pi.

The robot will come with a microSD card with the dexter software. There is some very very simple calibration that you need to do.

Battery Pack

• The battery pack is specific in terms of voltage and capacity. Don't substitute it for another one.

• Note that the battery pack needs to be in the "on" position in order to have the charger do anything. And obviously it has to be in "ON" for the robot to work.

• It also comes with a charger and a y-cable. The y-cable is about 10" long and has three barrel connectors on it in a y-configuration.

Camera

You will have bought the camera separately, but the instructions talk about how to mount it to the robot. Make sure it is centered in all three dimensions. A good spot is on the front of the top plexiglass part. It can be do without any extra parts, but which works nicely too.

Lidar

The Lidar needs to be mounted on the top plexiglass part. You will need to drill two holes. Make sure that the Lidar is exactly centered and pointed forward. As far as the drilling: I kept it to a minimum and drilled only two. I think it doesn't matter much. Mostly that it be straight and centered. Note that the narrower part of the Lidar is the front. You want it centered and facing forward (which on the other side of the ball caster.) I drilled holes for the two posts at the back of the Lidar (the wider part.) I don't see that it matters much though, that was what was easiest for me.

MiniRover is our modification of the GoPiGo3 robot. It comes with software, a VPN and all kinds of fancy things which is why I decided to give it a special name. This page is under construction as I troubleshoot and make notes about things. I expect feedback from everyone where the instructions don't meet reality!

What it is

Linorobot is a software package for building our own robots. We have used their software and instructions to construct our own robots and configure the software for them. The above link is a major resource for you. In this section we will explain things that are specific to Brandeis but we won't repeat it.

Turning it on

It is important that you follow a rigid procedure when turning the robot on and off.

Assuming it is totally off:

1. Make sure the battery pack is correctly connected to the robot.

2. Switch on the battery pack

3. Click the micro button on the red board

1. Look at the Raspberry Pi (not the "red board") You will see tiny red and green LEDs blinking. Wait until the green one has settled down to slow flickering.

Turning it off

1. From your ssh command line on the remote computer, type sudo shutdown now

2. Once the Raspberry Pi has stopped blinking you can turn off the power switch on the battery pack.

Charging the Battery

The Battery pack came with a charger. It has a light on which is red while charging and green when fully charged. Note that the battery will not charge when its switch is set to off.

rset command

We've implemented a very simple tool to set up the IP addresses correctly. It will be changing as I figure out how to make it better. So for now...

1. If you have a cloud desktop and want to run simulations without a actual miniRover" rset cloud

2. If you have a cloud desktop add a real robot, run rset robot on your cloud desktop and rset pi on the actual miniRover (over ssh)

rset by itself displays the current status

(I know a combination is missing and plan a revision of this)

Starting the MiniRover ROS applications

Note that all we run on the MiniRover itself are roscore, and the nodes needed for the motors, lidar and camera. Everything else runs on your "remote". The following commands are to be done on the MiniRover from ~/catkin_ws

Web Desktop tools

Note that this includes all flavors, cloud based, local docker based, and gpu based browser desktops. If you just want to use the simulators on their own and are not using an actual miniRover, then: rset cloud is enough. At that point you can run your ROS programs.

There are numerous scripts, programs and launch files that are preinstalled on your ROS wegpgb desktop. I will document only some of them here but you can look around and find more that are interesting. All of them from the book are here. I have not renamed any of them for that reason.

Rset Command

In order to facilitate working in all the combinations of environments we have these commands:

• rset pi - declare that this is the raspberry pi

• rset cloud - declare that this is a cloud desktop working with sim

• rset robot - declare that this is a cloud desktop working with a real robot

Aliases

There are a bunch of handy aliases:

• myip - this computer's regular local ip

• myvpnip - this computer's vpn ip if it has one

• stopnow

Accounts and passwords

• miniRover

  • hostname gopigo3

  • default account pi

Key Environment Variables

ROS_MASTER_URI=http:/100.94.206.80:11311 (example!) should always be set to the computer where roscore is running. If you are using a physical robot, then roscore runs on the robot itself. If you are in the web deskop and working just with simulation then roscore would run there.

Robot

ROS_MASTER_URI = robot's own ip address ROS_IP = robot's own ip address

Remote Computer

ROS_MASTER_URI = robots ip address ROS_IP = remote computer's own IP address

These IP addresses are on different networks and cannot access each other. So instead we've created what is called a "virtual private network" that connects them together. Both your robot and your cloud desktop have an alternate ip address which they can both see.

IP Addresseses

• myip returns your local ip address

• myvpnip returns your vpn ip address (if you have one)

This section will help you get your robot set up to go. Note that if you received this from the Autonomous Robotics Lab then part of these steps may already be done.

See the important information about turning the robot on and off here: .

MicroSD Card (if needed)

If your robot was set up by us, then you should skip this step!

Author: Pito Salas

Gemeral

• An excellent and very detailed

The code can be found at Pupper GitHub Repository

Directory

Components Overview

Models

• The models can be found at /models/

• The obstacle, agent, and goal models are of type Shape which can be found within src/boundary_detection.py

• The parameters of the models can be found within params.yaml

Computer Vision

• The computer vision module can be found at /src/fiducial_vision.py

• The fiducial and computer vision package requires numerous parameters to work correctly, these include fiducial tag size, lens size, and center pixel of the image

• The module itself contains the Vision

Boundary Generation and Navigation

• The modules relevant to boundary generation and planning are src/boundary_detection.py, src/path_finder.py, /src/path_profiler.py, and path_test.py

• Boundary generation works by taking in the detected positions and rotations of fiducials and then creating obstacle classes to represent each fiducial. Then each obstacle.points

Visualization

• The visualization class in src/viz.py uses matplotlib to generate a plot of the agent model, obstacles, obstacle boundaries, position of the goal, graph nodes, and the path of the robot

Main

• The program can be run simply by navigating to the root of the repository and then running python3 main.py

The controller.py provides an API to control the robot by emulating a PS4 controller, similar to this. Main difference is some keybinds are different, but it can also be called from code.

The UDP message

This is a breakdown of the dictionary's fields that is sent through UDPComms to the robot.

Note: values [-1,1] means any values between -1 and 1 and values 1 or 0 are a toggle. This means that the first time 1 is sent, it will cause the value on the pupper to change. A 0 needs to be sent before another 1 will cause a toggle.

It is a good idea to use some sort of smoothing for lx, ly and rx to avoid abrupt stops.

Keybinds

If running the controller manually, these are the controls:

Control sequence

Robot must first be activated, this will also trigger calibration if the pupper software was run with the --zero flag. Then it must be in trotting mode and only then can it be controlled with other functions.

Context

The Pupper project uses the Stanford Pupper 2.0 which does not currently have public documentation but information on the original Pupper project can be found at . More detailed documentation on the original Pupper can be found at . This project explores topics related to fiducial detection, boundary generation, motion planning, controls, and hardware.

Discretization

• The discretization of the environment is done in /src/path_finder.py in the PathFinder

Setup

• We tested with 16 printed 0.03 meter fiducials and a floor sign to hold the goal fiducial

Environment

• Boundary generation occurs in the environment class within src/boundary_detection.py

• The class works by setting an ego agent (the pupper), adding each detected fiducial as an obstacle, and if a fiducial with id = 0 was detected then a goal object is added to the class as well

• Obstacle locations are updated if a fiducial with an existing id is detected and obstacle locations can be cleared with clear_obstacles

• Then a list of boundaries corresponding to each obstacle is created using the [Minkowski Sum](https en.wikipedia.org/wiki/Minkowski_addition) formula

Configuration Space

• Configuration space is essentially a series of points that represent infeasible locations and rotations for a robot in an environment

• We can use this along with discretization to generate a graph of all the feasible locations for the pupper robot in an environment with obstacles, assuming we have the models for the agent and the obstacles

• Below are two example configuration spaces shown in red for an ego agent in green for the obstacle in blue, notice how the configuration spaces changes when the rotation of the agent changes