GithubHelp home page GithubHelp logo

doggo's Introduction

Stanford DOGGO

Overview Of Stanford Doggo

This is the code for the Stanford Doggo quadruped robot. Stanford Doggo is a highly agile robot designed to provide an accessible platform for legged robot research. Currently, the robot holds the record (among all robots) for greatest vertical jumping agility1. Stanford Doggo can also jump twice as high as any existing quadruped robot. Weighing in at a little less than 5kg, Stanford Doggo is easy and safe to develop on, but at the same time, Stanford Doggo should not be expected to carry heavy loads or climb extremely aggressive terrain. The project is supported by Stanford Student Robotics http://roboticsclub.stanford.edu/.

1[Vertical jumping agility] = [maximum vertical jump height] / [time from onset of actuation to apogee of jump]

Overview of the Firmware

The Stanford Doggo firmware (contained here), runs on a Teensy 3.5 microcontroller. The code is Arduino-based, which we hopes lowers some barriers to entry, and is simple in structure. While the robot currently lacks advanced features like autonomous navigation or whole-body kinematic control, Stanford Doggo is exceptional at the basic behaviors like trotting and jumping. As we continue to work the robot, we hope to gradually add more sophisticated features that expand the domain of what's possible. Some of the current projects include: Sensing ground reaction forces, detecting obstacles via the natural leg compliance, acrobatic manuevers, and many more.

Code Requirements

To download the necessary submodules, run the following shell command from the Doggo directory:

git submodule init
git submodule update

This should download the ChRt library (https://github.com/Nate711/ChRt) to the lib/ directory.

Notes

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. We rarely use this command.
Working gaits
  • 'B': (B)ound. This gait is currently unstable.
  • 'E': Danc(e). Make the robot do a little dance.
  • 'F': (F)lip. Perform a backflip. (Make sure the IMU is working before attempting this).
  • 'H': (Hop). Perform small vertical hops.
  • 'J': (J)ump. Jump up using maximum torque.
  • 'T': (T)rot. Begin a forward trot.
  • 'Y': Turning trot. It is similar to the (T)rot, but supports turning as well. You can change the turning rate with the 's' command described below in the gait properties section.
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. Default for trot is 2Hz.
  • 'l {float}': Set the stride length in meters. Default for trot is 0.15m.
  • 'h {float}': Set the stance height (neutral height) in meters. Default for trot is 0.17m.
  • 'u {float}': Set the distance (in meters) that the leg travels above the neutral line during a stride. Default for trot is 0.06m.
  • 'd {float}': Set the distance (in meters) the leg travels below the neutral line during a stride. Default for trot is 0.04m.
  • 'p {float}': Set the proportion of time which the leg is below the neutral line versus above it. Default for trot is 0.35.
  • 's {float}': Set the difference in step lengths between the two sides in meters. Between -0.08 and 0.08 are good values. Default for trot is 0.0m.

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'.

Using a joystick controller

We have implemented basic support for controlling the robot from a Playstation dual shock controller. To use the controller, we actually use the same firmware, and instead add a program on the host computer's side that reads joystick values and sends the appropriate trot, stop, etc commands to the robot using the text-based XBee serial interface. You can find the code here: https://github.com/stanfordroboticsclub/DoggoCommand

doggo's People

Contributors

ademiadeniji avatar crazyaz avatar natalieferrante avatar nate711 avatar pslade2 avatar

Stargazers

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

Watchers

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

doggo's Issues

Add MIT license to github repo

The description states the code and design is open source, but it should have the MIT license (or other license) attached to it so that others can use it more freely.

Take 'hero' shots.

  1. Whole robot lab 64 in front of the banner
  2. Close up of belt drive system
  3. Pictures during some gait (prob trot)

Some problem in ODrive config.

Hi, I had some trouble in Odrive config. I run "full_calibration"(odrive/tool/doggo_setup.py) and test motor by "set_pos_position" like this:
odrv.axis0.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL
odrv.axis1.requested_state = AXIS_STATE_CLOSED_LOOP_CONTROL
time.sleep(3)
odrv.axis0.controller.set_pos_setpoint(2000.0, 0.0, 0.0)
odrv.axis1.controller.set_pos_setpoint(2000.0, 0.0, 0.0)
time.sleep(3)
odrv.axis0.controller.set_pos_setpoint(0.0, 0.0, 0.0)
odrv.axis1.controller.set_pos_setpoint(0.0, 0.0, 0.0)
time.sleep(3)
odrv.axis0.controller.set_pos_setpoint(-2000, 0.0, 0.0)
odrv.axis1.controller.set_pos_setpoint(-2000.0, 0.0, 0.0)
time.sleep(3)
odrv.axis0.controller.set_pos_setpoint(0.0, 0.0, 0.0)
odrv.axis1.controller.set_pos_setpoint(0.0, 0.0, 0.0)
time.sleep(3)
odrv.axis0.controller.set_pos_setpoint(4000.0, 0.0, 0.0)
odrv.axis1.controller.set_pos_setpoint(4000.0, 0.0, 0.0)
time.sleep(3)
odrv.axis0.controller.set_pos_setpoint(0.0, 0.0, 0.0)
odrv.axis1.controller.set_pos_setpoint(0.0, 0.0, 0.0)
time.sleep(3)
odrv.axis0.controller.set_pos_setpoint(-4000, 0.0, 0.0)
odrv.axis1.controller.set_pos_setpoint(-4000.0, 0.0, 0.0)
time.sleep(3)
odrv.axis0.controller.set_pos_setpoint(0.0, 0.0, 0.0)
odrv.axis1.controller.set_pos_setpoint(0.0, 0.0, 0.0)

But the motor sometimes will go crazy and the vel_limit doesn't seem to work. I exchanged the connection of two motor and ODrive, but the motor still go crazy randomly, and not sure which one will. It seems problem is not enconder failure. When I config single axis of ODrive, there is no problem.
And I also don't understand what's the difference between the flag "startup_encoder_index_search" and "startup_encoder_offset_calibration".

Doggo code seems not running

Dear team,
I compiled and uploaded the Doggo code into my Teensy 3.5 board in PlatformIO, however there was no LED flashing and no serial information output for monitoring, so I donot know if the Doggo code is running. I spent many days and still not solved the problem. Did anybody meet this kind of problem and know how to solve it? Or, any special concerns needed for compiling the Doggo
code? Thanks. BEN

Add state machine or task queue to better schedule events like jump or walking.

We could use a task queue to keep track of events such as a jump command. In that case we'd append the jump behavior to the task queue and then wait for it to complete before going back to default behavior. Using a task queue instead of a state machine might be more extensible because instead of writing an additional switch statement for every new behavior, you would instead only write the behavior function and pass that a pointer to that function to the queue. Something like that anyways.

BEN

Hi, guys, I am new here, and I have more than 25 years of microcontroller programming experience, and I found DOGGO platform on Internet, and I am very interested in developing more advanced features on this platform. Is any body knowing where can I or how can I buy a Doggo robot for testing? Thanks

Ben
Petrel AI System, Surrey,Canada
my email: [email protected]

where is the relay coil control wires connected to?

Hi, Doggo team, I am almost finishing the project. Does anybody know where is the relay coil control wires(the ESTOP) connected to ? Where is the ESTOP located? Where is the 12V volts to the relay control coming from? Thanks. BEN

The Steps

After installing the hardware, what should I do next? (software)

Teensy pin 13 conflicted: BlinkThread & IMU SPI all use it

Dear Team,
Now I am rebuilding the Doggo . I check the code ,find that "BlinkThread" use the LED_BUILTIN ( #define LED_BUILTIN (13) ), while the IMU SPI port still use the pin 13 as the SCK .
I know that I can re-assign a pin . But I just want to confirm that I start from a golden point .

Turning

Is the doggo able to rotate on the spot, or take arcing trajectories?

If no, are there any suggestions on how one might help contribute that functionality?

doggo codes don't run as well as expected

Hello there! I have done previous jobs to run doggo codes on teensy and Odrive boards which have had been tested in doggo-firmware,are working well.The thing is when I commanded a JUMP with "J;" in Arduino Serial Monitor, the motors were nearly like stucking(the fact is that they moved 5-8 degrees) with noise of heavy "cluck".I have tried to load up the leg but it didn't move at all.The wiring of motors and Odrive, Teensy to Odrives are exactly copied from the image you guys provided.
My guess is that I have to re-tune the gains of close-loop-control because the gains and setponits of each specific movement is settled according to source code and the paras maybe differ form hardwares.
Have you guys ever met this before?I am looking forward your sooner reply!Thank you!

How to configure ODrive before connect it to teensy?

Hi, I want to ask How to configure ODrive before connect it to teensy? I try to configure ODrive as follows but the motor go crazy(Rotating very fast) sometimes, is there any problem in config?

% init:
odrv0.erase_configuration()
odrv0.reboot()
odrv0.config.brake_resistance=0
odrv0.axis0.motor.config.pole_pairs=11
odrv0.axis0.motor.config.resistance_calib_max_voltage=4.0
odrv0.axis0.encoder.config.cpr=2000
odrv0.axis0.motor.config.current_lim=10
odrv0.axis0.motor.config.calibration_current=10
odrv0.axis0.motor.config.pre_calibrated=False
odrv0.axis0.encoder.config.pre_calibrated=False
odrv0.axis0.controller.config.pos_gain=0.01
odrv0.axis0.controller.config.vel_gain = 5.0/10000.0
odrv0.axis0.controller.config.vel_limit=5000.0
odrv0.axis0.controller.config.vel_integrator_gain = 0
% motor calibration:
odrv0.axis0.requested_state=AXIS_STATE_MOTOR_CALIBRATION
odrv0.axis0.motor.config.pre_calibrated=True
% encoder calibration:
odrv0.axis0.encoder.config.use_index=True
odrv0.axis0.requested_state
odrv0.axis0.requested_state=AXIS_STATE_ENCODER_INDEX_SEARCH
odrv0.axis0.requested_state
odrv0.axis0.requested_state=AXIS_STATE_ENCODER_OFFSET_CALIBRATION
odrv0.axis0.requested_state
odrv0.axis0.encoder.config.pre_calibrated=True
% startup config
odrv0.axis0.config.startup_encoder_index_search=True
odrv0.axis0.config.startup_closed_loop_control=True
odrv0.save_configuration()
% test motor
odrv0.axis0.requested_state=AXIS_STATE_CLOSED_LOOP_CONTROL %(1)
odrv0.axis0.controller.pos_setpoint = 1000 %(2)

The motor go crazy sometimes at (1) and sometimes at (2) . The encoder seem work properly, I read the encoder data find that set_postion at positive 1000 but the motor ratate in the negative direction and it's speed is getting faster and faster. Is there any sequential requirement for connection motor and ODrive connections?

Some Questions about Parameters

What does the parameter of “leg_direction” mean?Which leg does leg0, leg1, leg2, leg3 represent respectively?Thank you.

FLIP command what's the parameters set?

Doggo comman 'H' and 'W' are right. The 'F' command doggo is not good. The parameters use the software defualt value {0.15, 0.07, 0.06, 0.2, 0.0, 1.0, 0.0}, // FLIP;whitch value should change.

Thanks.

Doggo Can‘t Stand up?(current set 60A)

I have build up a doggo。 Calibration leg downward movement,next leg turn horizontal。Next send command set parameter:h 0.15,d 0.05,u 0.05,p 0.35,l 0.1,f 1.5,s 0.0;the parameter set successful。Then put doggo on the floor,leg can't stand horizontal。Next send W command let doggo walk,but Doggo fall down can‘t stand up。

Use state transition functions

Instead of directly setting the state variable, encapsulate that behavior in a function like "TransitionToStop," which could also do things like print "Transitioning to STOP state" and also have some side effects.

Motor no responding to teensy command

Hello!
We have configure teensy and odrive by your code(The only difference is we use AS5047P with a cpr of 4000, which I assume won't impact main function. We also comment out //#define USE_XBEE so we are using computer serial.)

However, when we send command (ie. E, R)to teensy by Serial software on computer, the motor was not moving at all, it just stay in close_loop state.

In the function SendByte, a "uint8_t" byte(which equals to unsigned char) is transformed into a "char", I guess this leads to my problem because when byte>=128 it will be transform to a negative number but I have not idea if this really matters.
void ODriveArduino::SendByte(uint8_t byte) { serial_ << (char)byte; }
Thanks!

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.