Romi Arm

[ahartnet]

Got around to screwing with the robot arm kit on the Romi. Pretty fun! The code I have can be found here (largely based on ZQ and R^2): GitHub - Pearadox/Romi

One of the things I’m struggling with though is the servos are very twitchy. I started down a path of trying to look at some wpilib documentation for servo deadbands (the setbounds function) or something else, but no luck. It’d also be great if I could figure out how to print out the pulse width it’s currently at so I can try to set it up to match the Romi documentation. Anyone have suggestions for making the servos less twitchy? I suspect it’s just from trying to maintain a setpoint from the weight of the arm pulling it down and overcorrecting, but it seems like there should be a decent way of managing that? I’ve also tried disconnecting the gripper and wrist servos to see if it was just noise, and had the arm in the full down position so that it didn’t have extraneous force on it (the servo horn was facing straight up) and it still is twitchy.

It also seems that there’s not a good way to set what the default servo set point is when the robot is disabled, or at least from my reading of the documentation. That’s definitely workable, so not a huge deal - but want to make sure I’m not missing anything there either.

Here’s a video showing the twitchiness. I’ve got a 5V, 3.2A step down voltage regulator, getting Vin from VSW: https://photos.app.goo.gl/aEtb5SBQTXjaohaQ8

Some pictures of the set up just cause:

[zeequeue]

The Romi takes in angle values (via servo.setAngle()) and maps it from [0,180] degrees to [544,2400] microseconds.

Re: twitching, one thing to try is to try to actuate the servos without them being connected to the arm (just to make sure it’s not something going on with the firmware/servos themselves). On my romi with the arm, i did see a little bit of buzzing while lowering the arm.

Yeah the default setpoint is a little… weird. We wanted to make sure that if you connected a PWM motor controller or continuous rotation servo, that they would stop upon reset/disable (since we don’t have a good way of cutting bus power).

[Mr.R_2]

The way I dealt with these two issues is the same way I did it for the gripper.

1. Default position. Detach the servo horns and power the robot (running the code). Change the angle of the horn so it positions the arm where I want it to be in neutral and reattach (I may have done this powered off without disconnecting the servo).
2. Remap the joystick so that the joystick outputs 0-1 rather than -1 -+1.

I do hear the servos in disabled mode. I guess you could account for that in software by setting them to a more stable value in disabledInit().

[ahartnet]

Is your Romi arm twitchy while in teleoperated too?

I’ll disassemble the arm/wrist from the servos tomorrow to see if their twitchy without the weight of the arm.

[Mr.R_2]

I have not been using the arm lately so do not remember how bad it was, but I definitely think it was twitchy when I first got everything running. I do remember that when both the gripper angle and the lift servo were working against each other, it was twitchy. I will look into it when I get a chance.

You may be able to play with the scale more to smooth it like you would a motor, but it may not work the same since we are setting angles not velocity.

It is interesting. The Vex kits use regular motors for the gripper arm. I feel the servos are better suited to the task.

[ahartnet]

@zeequeue

The Romi takes in angle values (via servo.setAngle()) and maps it from [0,180] degrees to [544,2400] microseconds.

This is very helpful, thanks! Is this in the wpilib documentation for servos somewhere that I missed? Or is it specific to the Romi in some way?

[zeequeue]

It’s Romi-specific…ish. The firmware uses the arduino servo library, and specifically the writeAngle call, which does the mapping I mentioned above

[veg]

In my experience, servo twitchiness is kind of par for the course. It usually seems to happen when the analog PWM waveform is near the transition between two discrete setpoints, as interpreted by the servo’s internal controller. Sometimes a slight nudge to the requested angle can stabilize the situation and stop the twitch/buzz. It is definitely related to resonance in the physical system being controlled.

I think the problem is compounded in the Arduino firmware, where the standard servo libraries take an integer angle, meaning that there are a limited number of command-able setpoints between 0 and 180 degrees. The underlying resolution of the PWM hardware is typically much more capable.

It might help to tighten all the bolts and add a few drops of Locktite. My Romi arm dismantles itself regularly.

[Mr.R_2]

I got ours working relatively smoothly. There are some times when the arm and the wrist servos fight one another, but it is smooth for the most part. I put the arm on the Yaxis and the wrist on the Xaxis of a game controller (but also put low and high on buttons. You all probably know the map formula, but here is what we use for conversion just in case it could help anyone.
output = (((input-inputLowerLimit)/inputRange)*outputRange)+outputLowerLimit;