Delta Robot V3 – Step counts are doubled and…

[Anonymous]

I’ve spent the last few evenings after work going line by line through the code, but I am finally throwing in the towel and asking for some help with this one.

As of now, there appears to be 2 major issues with my delta bot.

1. All moves are roughly double the distance that is commanded.
2. Joint 3 consistently falls short of J1 & J2 in a purely Z+ move.

As an example of both of these issues, when I send “G01 Z0” from the home position, J1, J2, & J3 each report that they moved 38 degrees, but in reality, J1 & J2 both moved 76 degrees, and J3 only ~70 degrees.

As far as my trouble shooting goes, I have checked, double-checked, triple-checked all of my robot dimensions so many times it is not even funny. Since my entire delta bot is modeled in SolidWorks and then very carefully 3D printed, these dimensions are really a no-brainer and I’m certain that is not the issue. The only question I have there is dealing with the CENTER_TO_FLOOR dimension which I assume is to basically cap off the amount of Z travel which then makes all Z positions relative to the floor. Please correct me if I’m wrong.

In the Configuration.h file, I have made a few changes (some just temporarily for troubleshooting purposes)

#define BAUD                 (230400)  // How fast is the Arduino talking?
#define MAX_BUF              (32)  // What is the longest message Arduino can store?

#define STEPS_PER_TURN       (400.0)  // default number of steps per turn * microsteps
#define MICROSTEPS           (16.0)  // microstepping on this microcontroller

#define MAX_FEEDRATE         (30000.0)  // depends on timer interrupt & hardware
#define MIN_FEEDRATE         (150.0)
#define DEFAULT_FEEDRATE     (500.0)
#define DEFAULT_ACCELERATION (50.0)

#define MAX_ANGLE            (90+85)    //This does not appear to be in use anywhere???
#define MIN_ANGLE            (90-30)    //This does not appear to be in use anywhere???

// split long lines into pieces to make them more correct.
#define MM_PER_SEGMENT       (10)
#define NUM_TOOLS            (6)
// related to number of instructions that can be buffered.  must be a power of two > 1.
#define MAX_SEGMENTS         (16)

// turn this on if you need the robot to NOT buffer commands
//#define ONE_COMMAND_AT_A_TIME  (1)

The “STEPS_PER_TURN (400.0)” and “MICROSTEPS (16)” should also be correct. My steppers are 0.9 degree, and are being driven by a Ramps 1.4 board with the black Polulu A4988 drivers which have also had the current limit properly set, and with ALL jumpers in for the sixteenth step microstepping. I have validated this with the steppers out of the bot, and using a separate program where I can command 6400 steps, and the motors make exactly one revolution.

I also made this change since I’m using Ramps.

// arduino pins for motor control
//#define MOTHERBOARD 1  // RUMBA
#define MOTHERBOARD 2  // RAMPS 1.4

And since my arms are at 0 degrees when they hit the switches I changed this in deltarobot.ino.

  // The arms are 24 degrees from straight horizontal when they hit the switch.
  // @TODO: This could be better customized (per-arm).
  float horizontal = 0;    //Changed from 24 to 0
  long j, steps_to_zero = horizontal * MICROSTEP_PER_DEGREE;

As far as #2 above, where J3 seems to fall short, it is hard to tell if it is only happening in purely Z moves or if it is in all moves, but I’m pretty sure that it is happening all the time. When large X or Y moves are made without any Z component, it is fairly obvious that the kinematics are off because the delta plate (end effector) does not move perfectly parallel to the base. At first I suspected that I potentially had a bad stepper or a bad Polulu driver. However, after swapping both of them out, the problem still persists.

On a side note, I have been using Open CV with a webcam to feed the Delta the G-Code which is working beautifully, but if I am unable to resolve these two issues, it is all for nothing. I’m looking forward to sharing my project, but I’d rather get over these hurdles first.

Thanks in advance for your help.

Brian.

[Dan]

If everything moves double then I would suspect the stepper motors are 200 step per turn – they move 2x more per step than the model we use.

[Anonymous]

Thanks Dan, turns out you were right. I swung by Sparkfun on my way home from work this afternoon and picked up a new set of 0.9 degree steppers and now it appears that one of the two issues has been resolved. Unfortunately, J3 continues to fall short in it’s movements.

I tried swapping my J3 motor over to E0 on the Ramps board just in case it was an issue with the board, but the problem still persists. In addition, I swapped the J2 & J3 motor/switch connections on the ramps board, and the problem continued to follow whatever was configured as J3 in the software. With new motors, and all of the changes in configuration & wiring, swapping out stepper drivers, etc., there really doesn’t appear to be any options left other than a bug in the software that I can think of. Please let me know if you have any other ideas. I’ve tried everything I can think of from the hardware side of things. I should be receiving a new set of Polulu A4988 stepper drivers on Monday as well so I’ll give them a shot, but I honestly don’t expect them to provide any resolution to the issue.

Thanks again,

-Brian.

[Dan]

Also check your PS has enough amps.

[Anonymous]

It is a 12VDC/12.5 amp power supply running 3 steppers at 12VDC & 2 Amps each + the ramps board. It should be way more than sufficient. The problem follows the configuration for joint 3. If I swap the J2 & J3 pin assignments (MOTOR_1 & MOTOR_2) in the configuration.h file, the problem follows the Joint 3 configuration. In other words, which ever motor is assigned as MOTOR_2 in the configuration file, will end up being short on it’s travel. This tells me that it must be software, but I have been unable to find the error so far.

If I had to guess, maybe a rounding error somewhere, or a float being accidentally converted to an int in a calculation somewhere? …maybe?

The fact that it is joint 3 feels like a little bit of a clue to me since it is the last in line.

[Dan]

yes, three amps is enough for the kit we make.

All three are treated the same, motor agnostic. None of our other customers have reported a similar issue.
I will pull down a ready-to-go kit and see if I can repeat your results. Do you have a gcode example of a test you are running?

[Anonymous]

All I’m doing is homing the arms with “G28”, then sending “G01 Z0” or also “G01 X0 Y0 Z0” through the serial
monitor. Both yield the same results.

Just for grins, I also tried using the firmware from here, and github as well but there wasn’t any difference. I also opened up my ramps test code that I wrote that allows me to move all motors the same amount of steps (simultaneously) and the hardware all checks out because I get the same angle on each motor.

Thanks for looking into this, I really appreciate it. I will continue to see if I can find any clues that might help as well.

I can’t imagine that it makes any difference, but I wanted to mention again that my arms are on the limit switches when they are at 0 degrees. I intend to redesign the switch brackets at some point to allow some negative travel in the arms even though I don’t really need it.

[Dan]

erm, they shouldn’t be on the switches at (0,0,0). they should touch the switches and back off. I believe that z adjust you mentioned may be part of the issue. it’s hard to say, your machine may have slight differences from ours and our assumptions differ.

BTW, can I see a pic? post an imgur link and it should embed right here in the thread.

[Anonymous]

I’ll make the necessary adjustments so that 0 degrees is not on the switch and then get back to you on whether or not it solved the problem.

[URL=http://s721.photobucket.com/user/cohbra/media/3D%20Printing/FD96FF80-10D3-41C2-BF5C-2422D4ED3F02_zpsxvchf0nn.jpg.html][IMG]http://i721.photobucket.com/albums/ww212/cohbra/3D%20Printing/FD96FF80-10D3-41C2-BF5C-2422D4ED3F02_zpsxvchf0nn.jpg[/IMG][/URL]

[URL=http://s721.photobucket.com/user/cohbra/media/3D%20Printing/9E4A96E9-6FD0-42DE-949A-C569F5EEFEB1_zpsdr9yf2ys.jpg.html][IMG]http://i721.photobucket.com/albums/ww212/cohbra/3D%20Printing/9E4A96E9-6FD0-42DE-949A-C569F5EEFEB1_zpsdr9yf2ys.jpg[/IMG][/URL]

[Anonymous]

oops… let me try that again.

[Anonymous]

hmmm… wish I could edit those posts. One more time.

[Anonymous]

I made the changes so that 0 degrees is no longer on the switch, but unfortunately, nothing changed.

[Dan]

Eh… I can’t even see your switches. One thing to note is that the switches on our delta are at about -30 degrees (the arms are not horizontal when touching).

I don’t know why your third motor is being wierd. I’m slammed with work to get ready for re:make on friday, after that I will have time to make more videos (including a delta demonstration).

[Dan]

PS love the 3d printing. such style!

[Anonymous]

Thanks for the compliments.

I haven’t dug into why, but I changed the segment length from the default of 10mm to 1mm and the problem dissappeared.

[Dan]

possibly there is some cm > mm conversion going on that accidentally loses the fraction? i don’t know yet. It’s one data point. What happens at 5mm? at 2mm?

[Anonymous]

After playing around with the MM_PER_SEGMENT a little more, it appears that this setting causes an equal amount of offset towards arm 3 when Z=0. In other words, if you send “G01 Z0” with MM_PER_SEGMENT set to 30, the robot will move to Z0, but will be offset 30mm towards arm 3. It’s pretty difficult for me to get a really precise measurement though, so I am presuming that the offset is equal to the MM_PER_SEGMENT configuration based on my measurements. For the time being I have set it to 0.01mm to reduce the amount of error since it doesn’t appear to be negatively affecting anything else.

[Dan]

Yeah i dunno man, that’s wierd.

[Author]

Posts