OpenServo.com

wpotter · Joined: 18 Jun 2010 Posts: 50 Location: Valencia, Spain

Hi All (specifically KBB)

I decided to make a new thread for your OpenServo_V3-experimental branch. For the sake of keeping everyone else up to date, I have 8 OpenServo's (MG995's and MG996's) with OpenEncoders installed. I wanted to find a better way to control them as the stock firmware in the CVS repository doesn't have any I control (Just P+D). While attempting to create a new PID module, KBB came to me and said that he had created a new PID module and he had put in into the CVS in the AVR_OpenServo_V3-experimental folder. However, he did not have OpenEncoders, and therefore could not test the compatability with my servos. Eager to avoid having to rewrite my own module, I started testing his code with my servos. I created this thread for discussion about the development of the "experimental" branch in hopes that we can bring better PID control to OpenServo.

wpotter · Joined: 18 Jun 2010 Posts: 50 Location: Valencia, Spain

i just spent a couple days testing the software on my servos and when I first installed it, the P and I worked, but I had no luck getting the D to work. Now, it appears that all three of them are working after some small modifications I made. I'm not sure how to access the CVS to commit them but I would be happy to send them to you if you want (just in the pid.c file)

This branch does work with OpenEncoder and I have had success tuning the PID settings.

My only complaint is that the PID control is not quite good enough with the higher resolution of the OpenEncoder. The motor will consistently get within 5 positions of the desired position and then stop while the code keeps running trying to get the motor to reach the seek position. Ideally, there would be a way to get the motor to reach that one position everytime.

Other than that, the PID module is working well. Thank you KBB!

EDIT: Also, when I have the servo move for a distance longer than 180 degrees, the motions is very inconsistent and seems to move in long pulses. Seem familiar?

kbb · Joined: 01 Jun 2007 Posts: 180

jharvey · Posted: Wed Jul 14, 2010 12:08 am Post subject:

The 5 ticks is likely the band gap thing. I seem to recall that OE can detect nearly 5 ticks based on gear backlash alone. The band gap is programmable via I2C. However, that band gap will have to correlate to the same band gap in the python script. So be careful, keeping those in sync.

A while back I posted a video showing an OE servo moving. When seeking a position at high RPM, and at about every 1/4 rotation, you can hear a change in the motor sound. I'm not exactly sure what is causing that, but I suspect it's the processor trying to keep up with the position. For position changes at under 1/4 rotation, it seems to get there with out those little skipps. I would expect normal operations will not need to run at the full RPM of the motor, and will actually want to rotate much slower. I would expect that jitter would cause the end position to vary from the commanded position. For example, if you command it to move 90 degrees from it's current position, it starts with 90 degrees of jitter. I would suspect that you would want less jitter, and would instead command it to move 10 degrees 9 times. I suspect that a normal application will be sending a continuous thread of positions, and the servo will try to hold those commanded positions as best it can. However for rapid moves this would be handy to iron out.

The direction thing, I seem to recall that the OE firmware figures out how to get there on it's own as well it's done via I2C commands. It's required for when it crosses the 0 degree transition. Perhaps that's done with another function and perhaps this other potential function is the source of the skips. I seem to recall that you've only got 1 rotation of buffer, then you had to keep track of larger numbers on the other side of the I2C. For example, you can't command OE to move to 645 billion, it's simply to big for OE. Instead it's limited to a max, and by using the direction thing, you can rotate it beyond it's max, and keep track of those bits at the commanding device.

kbb · Joined: 01 Jun 2007 Posts: 180

Looking at the code as it stands; whilst full rotation direction could be controlled by sending regular position changes to reach a destination, note that with position changes approaching 180 degrees or greater you cannot tell it to go there directly. This would be because the servo will move in the direction of the shortest path between the current and desired position, which may be in the opposite direction to what you want.

Ideally I would have thought that telling it which direction would be the best option. We could set this up as a configurable build option (for example #define FULL_ROTATION for direction control and #define FULL_ROTATION_CLASSIC for what is currently done).

Also “missing” from the full rotation implementation is a “continuous rotation” function; again this could be added as a configurable build option.

Note that controlling the position externally to achieve direction and/or velocity control might result in some jerky movement- as the servo firmware is already trying to do that itself. But there are other causes as well... From my observations with my other experimental firmware, I suspect the PID/PWM implementation needs a bit of a review when used with higher power servos. Things to look into later...

wpotter · Joined: 18 Jun 2010 Posts: 50 Location: Valencia, Spain

Sorry for my long delay, I have been away from the office for the past week.

kbb · Joined: 01 Jun 2007 Posts: 180

wpotter · Joined: 18 Jun 2010 Posts: 50 Location: Valencia, Spain

jharvey · Posted: Mon Jul 26, 2010 7:07 am Post subject:

That OE video was posted here.

http://www.openservo.com/Forums/viewtopic.php?t=940&start=89

I just added it to the wiki.

wpotter · Joined: 18 Jun 2010 Posts: 50 Location: Valencia, Spain

I am in the process of putting integral windup control into my new firmware. That might contribute to my large error when the servo moves large differences.

EDIT: It is already there, I just missed it.

kbb · Joined: 01 Jun 2007 Posts: 180

I now have an OpenEncoder up and running. There clearly appears to be something “not quite right” about the firmware’s behaviour when it is built with the encoder support. I will investigate shortly.

kbb · Joined: 01 Jun 2007 Posts: 180

Okay: I have uploaded an improved firmware to the “V3-experimental” branch of the OpenServo CVS. I have not included precompiled .hex files (although I could make a number of the popular combos).

Let me know if there are any anomalies.

Here are some notes:

Reminder: this firmware is derived from the “AVR_OpenServo_V3” firmware (because that is where the OpenEncoder support was added). Therefore the new features from “AVR_OpenServo_V3-dev” are missing. On the other hand that means that it is probably better for those of you already using an OpenEncoder build. If I get time I will make an updated version of “AVR_OpenServo_V3-dev” and we’ll see where to put it.

Reminder: when compiling, remember to update config.h to match your setup!

I would recommend executing “defaults” and “save” the first time this firmware is uploaded to the servo. Or at least checking the gains and dead-band setting.

If minimum and maximum positions are programmed in, then they will be adhered to. So for full-rotation you will need to reset them: “defaults” will set them to [0,4095] when full rotation is enabled.

I have added a new hardware type of HARDWARE_TYPE_MG995 to config.h with some conservative settings.

It will not drive the motor unless the velocity is >zero (and PWM is on). For example: try writing 4 to 0x13 to set a velocity (0 to 0x12 if it isn’t already) - No, I don’t know why the registers have been implemented big endian!

There are a lot of things I have not had time to address. These include:

Actually there is lots of potential for improvement; this may have to wait for V4- a code reworking would be useful and if done correctly will be compatible with both V3 and V4.

jharvey · Posted: Fri Jul 30, 2010 11:19 pm Post subject:

Cool, I'll have to give it a try some time. I've just shifted my projects around, so I should be able to find more time for this. Any chance you can compile and post a hex file for a MG995 with OE?

I'm curious does this use the same registers and commands as the other OE firmware?

kbb · Joined: 01 Jun 2007 Posts: 180

jharvey · Posted: Sun Aug 01, 2010 1:20 pm Post subject:

Awesome and thanks for posting the pre-compiled firmwares. I've run some quick tests and they appear to be a near feature match of my original firmware. However, my move script isn't working. Here's what I'm discovering in my short look at it.

my scan script reports nearly the same thing as my original script.