hardware robot moment issue, not following gazebo simulation trajectory

asked 2022-12-23 23:25:51 -0500

jagilamkumar gravatar image

updated 2022-12-26 22:42:14 -0500

we made robot hardware running with nema 17 stepper motors without encoders of DM542 stepper drivers and arduino ...when we execute the commands, all working well in gazebo simulation world, but same trajectories are not following with the real time hardware robot, the robotic arm is moving ahead of its designated point and then coming back to the same point. so finally end effector is reaching goal position but following strange trajectories..as on search we couldnt find the arduino stepper motor code for drivers, we written code as ourselves, i think problem is all about arduino code , we tried a lot with code ..but could not make it i am attaching youtube video link that shows real hardware and gazebo simulation...and also attaching the arduino code as well...kindly suggest some solution to the problem........thank you

Ros source package link : robot_sourceyoutube link: https://youtu.be/R2brv3ZZEIk arduino code:

#include <ros.h>

#include <std_msgs/Empty.h>

#include <std_msgs/String.h>

#include <std_msgs/Int8.h>

#include <std_msgs/Int16.h>

#include <std_msgs/UInt16MultiArray.h>

#include <mwc_stepper.h>

#include <math.h>

#include <AccelStepper.h>

//#include <MultiStepper.h>

#define PUL1 5

#define DIR1 4

#define PUL2 7

#define DIR2 6

#define PUL3 9

#define DIR3 8

// Define the working range for each joint

#define MIN_RANGE 0

#define MAX_RANGE 180

int posfactor = 19/(0.225*2);

int posfactor_1 = 14/(0.225*2);

int directionMultiplier = 1;

// Defining ROS node handle.

ros::NodeHandle nh;

AccelStepper base(AccelStepper::DRIVER, PUL1, DIR1);

AccelStepper shoulder(AccelStepper::DRIVER, PUL2, DIR2);

AccelStepper elbow(AccelStepper::DRIVER, PUL3, DIR3);

//MultiStepper robojoints;

void reach_goal(AccelStepper& motor, int goal){


    // goes from the start point degrees to the end point degrees

    directionMultiplier = 1;

    motor.moveTo(directionMultiplier * goal);

  } else{

    // goes from the end point degrees to the start point degrees

    directionMultiplier = -1;

    motor.moveTo(directionMultiplier * goal);



void arm_actuate_cb( const std_msgs::UInt16MultiArray& msg){

  // check that the received data are bounded correctly

  if(msg.data[0]<MIN_RANGE) msg.data[0] = MIN_RANGE;

  if(msg.data[1]<MIN_RANGE) msg.data[1] = MIN_RANGE;

  if(msg.data[2]<MIN_RANGE) msg.data[2] = MIN_RANGE;

  //if(msg.data[3]<MIN_RANGE) msg.data[3] = MIN_RANGE;

  if(msg.data[0]>MAX_RANGE) msg.data[0] = MAX_RANGE;

  if(msg.data[1]>MAX_RANGE) msg.data[1] = MAX_RANGE;

  if(msg.data[2]>MAX_RANGE) msg.data[2] = MAX_RANGE;

  //if(msg.data[3]>MAX_RANGE) msg.data[3] = MAX_RANGE;

  reach_goal(base, msg.data[0] * posfactor);

  reach_goal(shoulder, msg.data[1] * posfactor);

  reach_goal(elbow, msg.data[2] * posfactor_1);


// Define the subscriber to the topic /servo_actuate where are published UInt16MultiArray messages

// Define the function that will be triggered each time a new message is published on this topic

ros::Subscriber<std_msgs::UInt16MultiArray> sub("arduino/arm_actuate", &arm_actuate_cb );

void setup() {

  // Attach and Initialize each Servo to the Arduino pin where it is connected










  // Inizialize the ROS node on the Arduino ...
edit retag flag offensive close merge delete


If it were me, I'd write test programs to verify you are able to move each joint through its full 0-180° motion. The video makes it look like there is some mismatch with the command sent to the 3nd joint (the elbow?) - perhaps the physical joint's 0° is not where you think it is.

Mike Scheutzow gravatar image Mike Scheutzow  ( 2022-12-24 09:33:40 -0500 )edit

thank you for the comment, but Physical joints's 0° can't be determined in my case as i am currently using open-loop system. my NEMA 17 stepper motor doesn't have encoder.

jagilamkumar gravatar image jagilamkumar  ( 2022-12-26 01:01:33 -0500 )edit

For robot arms, all the arm-movement code I'm aware of relies on having the current value of each joint. Open loop is seen as too imprecise. Do you have any plan in mind to obtain this joint information?

Mike Scheutzow gravatar image Mike Scheutzow  ( 2022-12-28 08:56:57 -0500 )edit