Haptic Controller for Robotic Manipulation

Project Overview

The goal of this capstone project is to design a robotic manipulation system consisting of two robotic fingers and a controller with haptic feedback to work in radioactive hotboxes. The most important features of this system are both human-like dexterity to operate chemistry equipment, and haptic transparency to improve ease-of-use for operators. The design is further constrained as it needs to fit onto the end of a robotic arm.

This repository contains the code for the alpha design of this system which is powered by Teensy 4.1 boards.

Directory Structure

• src/: Contains the source code for the project.
  • controllers/ : Contains controllers that manage
  • informants/ : Contains information sources, as of currently, these are not used. Encoders read directly by the teensy will be integrated here.
  • odrive_utils : Contains important odrive messages, classes, and functions for interacting with the odrives.
  • python : Contains visualization code.
  • system_descriptions : contains the files which define the mechanics and kinematics of the systems. This includes transmission ratios as well as joint limits. Currently this only defines four systems:
    • robot_finger.hpp
    • haptic_finger.hpp
    • robot_thumb.hpp
    • haptic_thumb.hpp
  • utils : Contains general helper functions such as limiting and unit conversionn
• include/: Contains defines.h, which specifies some settings for operation.
  • SYSTEM_ID: Specifies which subsystem you are compiling for
  • DEBUG: If defined, enables debug printing to serial
  • PROFILE: If defined, enables the printing needed for profiling
  • TESTING: If defined, runs unit tests rather than normal execution
  • The GPIO pins for various things are also specified in this file.
• docs/: Contains the documentation for the project, generated using Doxygen.
• imgs/ : Contains images of flowcharts and figures used in documentation.
• dbc/: Contains the dbc files for the CAN messages sent. These can be loaded into the TSMaster to view messages.
• test/ : Contains unit tests.

Building and Running the Project

To build the project ensure you have platform.io installed. Instructions for this can be found at https://platformio.org/.

Check include/defines.h to set the specifics of which system to build. The stiffness and damping for the system can be set inside main.cpp under the (end/joint)MirrorState Functions. Stable values for each system are:

• Robot Finger : Stiffness: 400, damping 1.65
• Haptic Finger : Stiffness: 400, damping 0.0
• Robot Thumb : Stiffness Waggle: 3, Damping Waggle 0.0, Stiffness Curl: 1.0, Damping Curl 0.0
• Haptic Thumb : Stiffness Waggle: 3, Damping Waggle 0.0, Stiffness Curl: 1.0, Damping Curl 0.0

Once this is complete, you can build the system. Ensure you are connected to the correct Teensy. Once flashed, the code should start running whenever power is provided. For debug information, see the debug section below.

System Flow

The code follows a state machine architecture, which is shown below. There are four main states: initializing, ready, running, and error. The initializing, ready, and error states do not send torques and the running state does. All state transitions are detailed in the diagram. The actions in the running state can be alterted depending on the defined system definition.

The communication test is based on not timing out on the mirroring teensy and both odrives it's connected to.

The safety test is a combination of our own position hard and soft limits as well as any non safe odrive errors, which is shown below.

Startup Procedures

Upon startup of the teensy and successful connection to the Odrives and teensy, the teensy will be in "Ready" state. Before moving into "Running" , the startup procedure has to be run

1. Move each joint to its 0 position
2. Zero the positions by clicking the four "clear error" button
3. With the robot side in "Running", move the haptic side to a comfortable position for the user to insert their hand
4. Move haptic side into "Running" by pressing the dead-man switch

System Timing

By the nature of our system, the timing and latency of our system is very important. We achieve a ~1ms latency with a 1kHz update rate, with the system mostly limited to the speed at which we can receive encoder values back from the Odrive. There are a few future solutions that can be looked into, which are in the Odrive discord.

By timing each component of our code, we see:

Thus, the full system from end to end has a timing structure that looks as follows:

Debug

Teensy Debug

There are 3 RGB leds on the data board. The top LED corresponds to the state of the system, with initializing as blue, ready as orange, runnning as green, and red as error. The middle LED correseponds to the Teensy-Teensy heartbeat timeout where red is timed out and green is successful. The bottom LED corresponds to the Odrive heartbeat states, where it is green if both Odrive heartbeats are fine, magenta if Odrive0 goes out, and cyan if Odrive1 goes out. There are two leds on the button board that light up when the buttons are pushed. If they do not light up, the buttons are not working.

ODrive Debug

If the code should be running, ensure the Odrive lights are green. This means the ODrive is in closed loop control. If the light is blue move to a zero position and then clear errors. If the light is red, either move to a zero position and clear errors. If it enters error again, see below.

• DC_BUS_UNDERVOLTAGE
  • Don't be dumb. Check the Estop. If still occuring, power off and check for shorts immediatley.
• Pole Pair Mismatch
  • Double-check number of poles with datasheet. If correct, increase calibration scan distance.
• Missing Estimate
  • Ensure encoder wires are properly connected and encoder GPIO is correct. If still not working, check the magnet is properly centered above the encoder.
• Missing Input
  • Unplug teensy and then clear error.
• Estop_Request
  • The Teensy requested this error, find out why.
• Does not enter control loop from teensy
  • Push Estop then release Estop and clear errors. Otherwise, re-calibrate.

When in doubt, power cycle and recalibrate to fix many things.

Visualization and Profiling

• Connect the Teensy to a computer via USB
• Set the DEBUG or PROFILING flags in defines.h
• Run finger_viz.py, finger_viz.py, or profiler.py
  • Make sure no other applications are reading from serial
  • Set COM_PORT to the port the Teensy is connected on