Skip to content

Latest commit

 

History

History
464 lines (351 loc) · 21.2 KB

README.md

File metadata and controls

464 lines (351 loc) · 21.2 KB
Raw

SUTDoggo

SUTDoggo is a highly agile robot designed to be an accessible platform for legged robot research. We adopt the Stanford Doggo for this project. This could serve to inspire fellow SOAR members in robotics.

Credits to the original Stanford Doggo repository!

This repository will be divided into three parts to house the different parts of the SUTDoggo:

  1. This main root folder will contain the main project files such as the BOM, updated CAD files, circuit diagram for electronics, general guidelines, project goals and plans, FAQ, etc.
  2. The ODrive subfolder will contain the modified version of the ODrive firmware (merged v0.4.11 of the official factory firmware with Nate's code customizations).
  3. The Doggo subfolder will contain the custom Doggo firmware. Currently, it is still using the default Doggo codebase. Future plan would be to refactor this codebase into a ROS workspace to enable ROS package integrations.

Detailed instructions can be found in the accompanying wiki.

Table of Contents

SUTDoggo

Stakeholders & Maintainers

Current Project Lead: Ian Goh Yiheng (Maintainer)

Current Team:

  • Ashley Ho Si Ci
  • Ian Goh Yiheng
  • Michael Lim
  • Myo Min Khant

Honour Roll:

Mentors:

Supervisor:

  • Prof. Tan U-Xuan

Objectives & Deliverables

Goal Deadlines & Status

  • Mechanical Assembly (Status: Completed ✔️)
  • Electrical Assembly (Status: In Progress ⌛)
    • Basic electrical assembly completed
  • Software Adjustment (Status: In Progress ⌛)
    • Testing/Debugging Firmware (Status: In Progress ⌛)
  • Detailed Documentation - Wiki (Status: In Progress ⌛)
  • Teleoperation Calibration (Status: Not Yet ❌)

Extra Objectives

  • Integration with Robot Operating System
    • Implement ZED Stereo Camera/Intel RealSense Camera
  • Implement autonomous navigation like LinoRobot
  • Complete documentation of Doggo's navigation stack

Features & Technologies

Features

The Doggo boasts locomotion capabilities, including:

  • Trotting
  • Jumping
  • Backflipping
  • (More acrobatic moves/maneuvers to come)

Technologies

The Doggo's firmware is written in C++. The Doggo is equipped with RF-based communication protocol using the XBees. In implementing autonomous navigation, we would replace the XBees with a Raspberry Pi equipped with the ROS navigation stack.

Prerequisites

Before diving into this project, make sure that you are at least familiar with:

  • Arduino & C++
  • Mechanical Manufacturing & Assembly Techniques
  • Electrical Circuits (Microcontrollers, Motors & Encoders)

Gallery

Include some videos, GIFs and/or pictures in this space! (And some brief walkthrough.) [color=#e053c1]

Troubleshooting

# Tick when the problem is solved.

After solving a problem, rephrase the problem to include the solution so as to suit this troubleshooting section. [name=James R T] [color=#907bf7]

Unsolved

  • Current Doggo is flimsy and "limps over" when walking. Status is not ready for deployment. Need to attach the silicone leg molds since we suspect that there is almost no friction preventing the Doggo from slipping. If the molds are not compatible, need to recreate the molds. After molds are attached, recalibration is needed and some firmware constants might need to be changed. If done properly, the Doggo should be able to trot and walk properly. Only by then, testing for backflipping can begin.
  • Once Doggo is working properly, update this README and populate with relevant details, especially these sections: Objectives, Demo, Troubleshooting & FAQ and Future Plans & Implementations.

Solved

  • The M3 10mm and M2.5 8mm screws are not long enough to fix the encoder mount and T-Motor onto the side panel. Solved by buying new screws.
  • The holes on the 3D printed parts on the electronic plate support are too big to fit the insert. Need to reprint the part or buy bigger inserts. Solved by buying new inserts.
  • The spacers between gears and motors need to be laser cut. Solved by laser cutting the parts.
  • The leg parts fabricated according to the CAD files don't include the holes needed to tighten the leg and the axial Solved by trilling holes and using set screws to tighten up.
  • The belt is not tight enough and it could slip in cases of high angular velocity of the motors. Solved by attaching the brackets on top of the belt assembly (original design by Stanford). However, this is a short-term solution since it might loosen over time or break.

Future Plans & Implementations

We plan to implement autonomous navigation using the ROS navigation stack with a ZED camera. We also plan to add more acrobatic moves to the Doggo. Another possible implementation is to add OpenPose feature into Doggo.

Improvement Points for Doggo Mk. II

Minimize rabz gotchas and hacky stuffs.

  • Fix the Minitactor implementation.
  • Enable full IMU implementation (not just for recording backflips).
  • Add space to allow headers to be soldered to the encoders (solving the pressure issue).
  • We would need to redesign the whole belt assembly in order to be able to variably tighten the belt. This would lead to a more sustainable tightening mechanism, instead of using a 3D-printed part that could break or bend over time (prevent the CF from bending).
  • Change the gear-motor adapter material from acrylic to metal (by CNC).
  • Implement a better cable management system (shorten cables, tidying up cable space, use JST connectors, etc).
  • Implement a proper mounting of the electronics to the electronic CF plate (instead of only by using cable ties and tapes).
  • Increase encoder reliability by securing them in their corresponding positions with better methods.
  • Change all ODrives from 24V to 48V to prevent any burning (since the battery's voltage can rise to about 25V).
  • Convert the Doggo firmware into a ROS workspace.
  • Create a customized electronic circuit optimized for Doggo (perfboard or PCB) [OPTIONAL].
  • Add a charging circuit [OPTIONAL].

Components

SOAR operates in Singapore, which has a significantly different economic landscape compared to Stanford in USA. Thus, some of the original parts were a bit difficult to find and we opted for alternatives. A full list of the components that we used will be included in the detailed BOM.

BOM

We will do up a new, improved, more detailed and more reliable BOM. Also, any ideas on how to improve the organization of these components? [name=James R T][color=#ea9b12]

Mechanical

Gear Brace

The triangular gear brace might seems a bit big and doesn't fit the gears well. But it is actually for pushing the gears away a bit so that the belts can be tightened.

Legs & Coaxial

The leg parts didn't come with holes to fix them to the coaxial parts. So we need to drill holes ourselves and use set screws or dowel pins to fix the legs.

Spacers between Gears and Motors

There should be spacers between the gears and motors in order to mount the gears onto the motors.

Controller/Driver

Teensy

The code does not have a .ino file. Instead we use Platformio to compile all the code in the src and lib folders and upload it to the teensy.

  • Install VSCode and PlatformIO

    • Download and install official Microsoft Visual Studio Code. PlatformIO IDE is built on top of it
    • Open VSCode Package Manager
    • Search for official platformio ide extension and install the PlatformIO VSCode Extension.
    • Install PlatformIO IDE.

  • Check if you possess the 49-teensy.rules file under the /etc/udev/rules.d/ directory. If you do not have it, grab the latest version from here and put it under the specified folder. This is necessary for the firmware to be properly flashed to the Teensy after building.

  • Get the PlatformIO sketch

    • Clone https://github.com/Nate711/StanfordDoggoProject

    • Open VSCode

    • Open the Doggo folder in VSCode

    • Open config.h and comment out line 28 (#define USE_XBEE)

      This is done to test the motors through USB when the XBee is not configured/connected yet.

    • Take note that some serial monitors like XCTU may use Carriage Return for line breaks, which is not recognised by the Teensy code. To enable it, change line 21 of Doggo/src/usb_serial.cpp:if (c == ';' || c == '\n' || c == '\r') {

    • Plug in the teensy using a USB cable

    • Press Build (tick in the bottom left bar of vscode)

    • Press Upload (right arrow in the bottom left bar of vscode)

    • Open the Serial Monitor (electric plug icon in the bottom left bar)

Alternatively, run platformio run --target upload on the root Doggo folder that contains the platformio.ini file.

In Doggo's src folder, change the original #include library lines of datalog.cpp and imu.cpp from "arduino.h" to "Arduino.h" and of debug.h from "ChRT.h" to "ChRt.h".

  • Connect the UART cables from teensy to ODrives

    • connect TX to RX and vice versa

    • serial pins for teensy as described in https://www.pjrc.com/teensy/td_uart.html

    • Teensy 3.5 ports listed:

      Serial port RX TX
      1 0 1
      2 9 10
      3 7 8
      4 31 32
      5 (for XBee controller) 34 33

    • Odrive UART TX / RX

      TX RX
      GPIO1 GPIO2
  • Open a serial monitor (Arduino IDE or PlatformIO serial monitor should be fine)
  • Available serial commands:

    • Use a serial monitor (we use the Arduino one) to send over these commands to Doggo in order to set the behavior or to change parameters.

    • Changing behavior

    • General behaviors:

      • 'S': Put the robot in the STOP state. The legs will move to the neutral position. This is like an software e-stop.
      • 'D': Toggle on and off the printing of (D)ebugging values.
      • 'R': (R)eset. Move the legs slowly back into the neutral position.

    • Working gaits:

      • 'B': (B)ound. The gait is currently unstable.
      • 'E': Danc(e). Make the robot do a little bouncy dance.
      • 'F': (F)lip. Execute a backflip.
      • 'H': (Hop). Causes the robot to start making small vertical hops.
      • 'J': (J)ump. A full-torque upwards leap.
      • 'T': (T)rot. Begin a forward trot. This is currently the only working forward gait.

    • Available, but not working:

      • 'W': (W)alk. Does not work currently.
      • 'P': ( P )ronk. Much like hop, but this one doesn't work.

    • Changing gait properties:

      • 'f {float}': Set the gait frequency in Hz.
      • 'l {float}': Set the stride length in meters.
      • 'h {float}': Set the stance height (neutral height) in meters.
      • 'u {float}': Set the distance (in meters) that the leg travels above the neutral line during a stride.
      • 'd {float}': Set the distance (in meters) the leg travels below the neutral line during a stride.
      • 'p {float}': Set the proportion of time which the leg is below the neutral line versus above it.

    • Changing compliance (gains):

      • 'g {float} {float} {float} {float}': Set the compliance gains. The ordering is {kp_theta} {kd_theta} {kp_gamma} {kd_gamma}. A good default is 'g 80 0.5 50 0.5'.

Sensors

Contactor

alt text

Encoder

  • Make sure the magnet and encoder have the same center as the T-motor axle
  • Commonly seen in e-skateboards

Coaxial

  • The inner and outer leg shafts are supposed to be tight fitting with the bearings. Due to fabrication inaccuracy, the shafts might be a bit thicker than the bearings. When putting them together, must be careful not to break the bearings.

ODrive

  • Although the original Doggo uses ODrive v3.5 24V, we ended up using ODrive v3.6 25V.

  • Testing of the ODrive

    • Follow this: https://docs.odriverobotics.com/

    • Run these and hope the odrive usb is detected

      echo 'SUBSYSTEM=="usb", ATTR{idVendor}=="1209", ATTR{idProduct}=="0d[0-9][0-9]", MODE="0666"' | sudo tee /etc/udev/rules.d/50-odrive.rules
sudo udevadm control --reload-rules
sudo udevadm trigger # until you reboot you may need to do this everytime you reset the ODrive

    • If the ODrive is not connecting, try changing the power source. A dim light on the ODrive indicates insufficient power.

    • Always calibrate when the ODrive is first started

      odrv0.axis0.requested_state = AXIS_STATE_FULL_CALIBRATION_SEQUENCE

    • Reccomended P gain

      odrv0.axis0.controller.config.pos_gain = 0.05

    • Manual control is only enabled when closed loop control is enabled:

      odrv0.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL

    • try moving the motor

      odrv0.axis0.controller.pos_setpoint = 1000

  • Setup (in Linux)

    • Installing custom firmware

      • Clone Nate's Odrive repository https://github.com/Nate711/ODrive

      • Navigate to ODrive/Firmware

      • Copy tup.config.default as 'tup.config' cp tup.config.default tup.config

      • Edit the value of CONFIG_BOARD_VERSION according to the ODrive you are using:

        ODrive model Value Remarks
        3.1 v3.1 Untested
        3.2 v3.2 Untested
        3.3 v3.3 Untested
        3.4 24v v3.4-24V Untested
        3.4 48v v3.4-48V Untested
        3.5 24v v3.5-24V
        3.5 48v v3.5-48V
        3.6 24v v3.6-24V Requires change to Tupfile.lua
        3.6 24v v3.6-56V Requires change to Tupfile.lua / Untested
        • Note: for ODrive 3.6 and later: An addition to Tupfile.lua is required (based on the main branch of the ODrive repo).
        elseif boardversion == "v3.5-48V" then
    boarddir = 'Board/v3'
    FLAGS += "-DHW_VERSION_MAJOR=3 -DHW_VERSION_MINOR=5"
    FLAGS += "-DHW_VERSION_VOLTAGE=48"
### ADDITIONAL PART STARTS HERE
elseif boardversion == "v3.6-24V" then
    boarddir = 'Board/v3'
    FLAGS += "-DHW_VERSION_MAJOR=3 -DHW_VERSION_MINOR=6"
    FLAGS += "-DHW_VERSION_VOLTAGE=24"
elseif boardversion == "v3.6-56V" then
    boarddir = 'Board/v3'
    FLAGS += "-DHW_VERSION_MAJOR=3 -DHW_VERSION_MINOR=6"
    FLAGS += "-DHW_VERSION_VOLTAGE=56"
### ADDITIONAL PART ENDS HERE
elseif boardversion == "" then

      • Do make

        • This may require you to sudo apt install tup

      • The firmware can be found in ODrive/Firmware/Build/

      • For users of ODrive 3.4 and lower please refer to https://docs.odriverobotics.com/odrivetool.html#device-firmware-update for firmware flashing instructions

      • For ODrive 3.5 and higher, run the following:

      odrivetool dfu path/to/ODrive/Firmware/build/ODriveFirmware.hex

  • Setting parameters

      - Nate's default configuration script can be found here:
  ```
  python ODrive/tools/doggo_setup.py
  ```
  - By default the ODrive takes no action at startup and goes to idle immediately. In order to change what startup procedures are used, set the startup procedures you want to True. The ODrive will sequence all enabled startup actions selected in the order shown below.
      ```
      odrv0.axis0.config.startup_motor_calibration = True
      odrv0.axis0.config.startup_encoder_offset_calibration = True
      odrv0.axis0.config.startup_closed_loop_control = True
      ```
  - Repeat for axis1.
      ```
      odrv0.axis1.config.startup_motor_calibration = True
      odrv0.axis1.config.startup_encoder_offset_calibration = True
      odrv0.axis1.config.startup_closed_loop_control = True
      ```
  - Save and reboot
      ```
      odrv0.save_configuration()
      odrv0.reboot()
      ```

    • Refer to the teensy section on how to connect the ODrive to the Teensy via UART

    • take note that odrv0.save_configuration() only works once per reboot!

XBee

  1. Follow this tutorial.

  2. Install X-CTU, Digi USB RF Drivers and FTDI Drivers for your respective operating system.

  3. Connect both XBees to your master computer for initial configuration.

    X-CTU can only detect XBees that do not have wires soldered to the LED pins yet.

  4. Follow the tutorial to define your unique network (CH, ID, DH, DL and MY).

  5. Done! You can proceed to connect one XBee to your master computer and the other XBee to the Teensy. a. Connect RX(Xbee) to RX(Teensy Serial port 5) and TX(Xbee) to TX(Teensy Serial port 5) b. when using XCTU console to send commands to the teensy, use ; to simulate a line break to send commands

IMU

  • The particular IMU used for our Doggo is the CJMCU-80
  • information taken from page 10 of https://cdn.sparkfun.com/assets/1/3/4/5/9/BNO080_Datasheet_v1.3.pdf
  • How to connect the IMU to the teensy:
    • Teensy 3.5 port IMU port meaning
      3.3V 3.3V Power
      GND GND Ground
      11 SA0 MOSI (data input)
      12 SDA MISO (data output)
      13 SCL SCK (SPI clock)
      14 PS0 Protocol Select 0 / WAKE (also needs to be turned high on boot to activate SPI)
      15 PS1 Protocol Select 1 (needs to be turned high on boot to activate SPI)
      16 RST Reset pin
      17 INT Interrupt pin ( to bug the teensy )

Additional Resources

Software

Prerequisites

ODRIVE Development Tools

The recommended tools for ODrive development are:

  • make: Used to invoke tup
  • Tup: The build system used to invoke the compile commands
  • Python: For running the Python tools
  • ARM GNU Compiler: For cross-compiling code
  • ARM GDB: For debugging the code and stepping through on the device
  • OpenOCD: For flashing the ODrive with the STLink/v2 programmer

Linux (Ubuntu 18.04)

$ sudo add-apt-repository ppa:team-gcc-arm-embedded/ppa
$ sudo apt-get update
$ sudo apt-get install gcc-arm-embedded
$ sudo apt-get install openocd

// To install Tup
$ sudo add-apt-repository ppa:jonathonf/tup 
$ sudo apt update 
$ sudo apt install tup

source: link

ODrive Default Firmware

// Clone Nate's ODrive Firmware
$ git clone https://github.com/Nate711/ODrive.git

$ cd ODrive/Firmware
$ make
// if all blue then good
// if got red, then check error message

$ cd build

// Flash firmware's hex file to odrive
$ sudo odrivetool dfu ODriveFirmware.hex