Making a RHex-like Robot

I'm setting out to make a RHex-like robot. RHex is a robot from Boston Dynamics which can scale rough terrain using its six 'whegs'. Here is a video.

The robot has six legs. Three legs move at a time in sync. I would need to use encoders for this. I plan on using an Arduino Mega because it has six hardware interrupts. A PID control system would keep the motor position correct.

Please let me know if my plans so far are any good, and if there is something else I can do.

I think I would try to use chains to link the front and rear 'wheels' on one side and the middle 'wheel' on the other side. That reduces the problem to two motors and skid steering.

Really a great robot idea :slight_smile:

I second the 2-motor approach, but I don't know how to steer such a robot. Did you see how the legs are moved in opposite direction, in order to turn the robot in place?

But regardless of the number of motors, a simple sensor (switch) is sufficient for each motor, telling the default (bottom) position where the motor can be stopped after one turn. For inverse operation (top down) a second (top) sensor is required, and something like a tilt switch. I see no need for interrupts and PID here.

For a straight movement kind of a compass module may be required.

DrDiettrich:
I second the 2-motor approach, but I don't know how to steer such a robot. Did you see how the legs are moved in opposite direction, in order to turn the robot in place?

To me it looked like the wheels/legs in each triad always moved in sync. It appeared that for steering they just ignored the center wheels/legs and used skid steering like a tank.

DrDiettrich:
For a straight movement kind of a compass module may be required.

The video the OP referenced said that it was radio operated so the steering could be left up to the operator but one of the articles I looked at did say that they used a compass to maintain a straight line. I guess that allows the operator to move forward over uneven terrain without constantly having to manually correct the steering. It probably also has an accelerometer so it can reverse the motors when running inverted.

johnwasser:
To me it looked like the wheels/legs in each triad always moved in sync. It appeared that for steering they just ignored the center wheels/legs and used skid steering like a tank.
The video the OP referenced said that it was radio operated so the steering could be left up to the operator but one of the articles I looked at did say that they used a compass to maintain a straight line. I guess that allows the operator to move forward over uneven terrain without constantly having to manually correct the steering. It probably also has an accelerometer so it can reverse the motors when running inverted.

OP @lithiuminc in reference to @johnwasser comment:
Here is some code I use for with my balancing bot for direction control. Hope it helps :slight_smile:
I used a gyro MPU6050 to manage direction with standard yaw Here is a video of my balancing bot Balancing Bot hops off curb!!! notice at about 34 seconds my bot orients itself differently than where it is at when I stood it up. This is adjusting to setpoint of the last direction is had when it fell over.
My code Snips:

Capture the input  
      R12 = Radio12; // get input on pin 12  -500 to 500 with zero stick is centered
      if ( abs(YawInput) < 90) { // let the bot catch up Setpoint is always Zero 
// YawInput to PID is a product of YawOffset - actual Yaw Degrees and the PID loop always has a setpoint of Zero
        YawOffset -=  (double) - R12 * .013 ; only using 1.3% of -500 to 500  and subtracting it from the offset
        if (YawOffset > 180) YawOffset -= 360; // rollover to negative
        if (YawOffset < -180) YawOffset += 360; // rollover to positive
      }
 
// with this function I control the direction of my balancing bot
float BotTurnControl() {
  if (TurnControlEnable) {
    YawMPU = (ypr[0] * 180 / M_PI) ;
    if (StartUP) YawOffset = - YawMPU;
    YawInput = YawMPU + YawOffset;
    //    course_correction = (desired_heading-current_heading+180+720) % 360 - 180;
    if (YawInput > 180) YawInput -= 360; // rollover to negative
    if (YawInput < -180) YawInput += 360; // rollover to positive
    //  YawInput = YawInput;
    if (!StartUP) myTurnPID.Compute(); // this pid takes YawInput and PID calculates a offset for the motors sent to Turn
  } else Turn = 0;
  BalanceBotDrive(Turn);
}

Part of the function to actually drive my balancing bot
BalanceBotDrive(float TurnOffset){
	static bool LastADriveDir,LastBDriveDir;
	double Output = * myOutput;
	double AOutput =  Output - TurnOffset;// Power A motor for both forward and reverse
	double BOutput =  Output + TurnOffset;// Power B motor for both forward and reverse
	bool ADriveDir = AOutput > 0; // Zero or stopped can be either true or false
	bool BDriveDir = BOutput > 0; // Zero or stopped can be either true or false
	double absAOutput = fabs(AOutput);
	double absBOutput = fabs(BOutput);

	absAOutput = (absAOutput > outMax)? outMax : absAOutput; // Limits Output
	absBOutput = (absBOutput > outMax)? outMax : absBOutput; // Limits Output
	double DriveAOutput =  PID::map_Generic(absAOutput,0,outMax,DriveMin - PowerOffset,DriveMax);// Power motor for both forward and reverse
	double DriveBOutput =  PID::map_Generic(absBOutput,0,outMax,DriveMin + PowerOffset,DriveMax);// Power motor for both forward and reverse
//...

Note that in my code YawInput to PID is a product of YawOffset - actual Yaw Degrees and the PID loop always has a setpoint of Zero
for example actual yaw reading is 48° My YawOffset is at 38° giving an error of -10° (YawInput) the pid is now attempting to shift the “turn” value to drive the bot left by 10° to meet the setpoint of 0°

Z

Using chains to link the wheels would result in a robot that can only perform the basic walking gait. The RHex robot can use its legs in different ways to achieve tasks like stair climbing. My idea of using encoders came from ZebroLight, a Beaglebone based implementation of RHex detailed over here.

DrDiettrich:
But regardless of the number of motors, a simple sensor (switch) is sufficient for each motor, telling the default (bottom) position where the motor can be stopped after one turn. For inverse operation (top down) a second (top) sensor is required, and something like a tilt switch. I see no need for interrupts and PID here.

Could you please link to such a sensor?

You need a mark on an axis or other rotating part, that can be read by a hall sensor or reflective light barrier.