Quick update on Offset Header availability.  They're now available on their own from sparkfun: http://www.sparkfun.com/commerce/product_info.php?products_id=9374

Guci:  you're correct.  my headers went to adafruit.  


TBAr:  no idea why they're sold this way.  we'll see where it goes from here.

Emily Jane:  that's a great technique.  my jig does something similar, only I'm using machined steel.  another method (if you only need one or two) would be to bend the pins with pliers.

Brett

I think this is going to do the trick:


I worked up a jig, and I can crank them out pretty quickly:


The first batch went to Adafruit today.  Hopefully having these widely available will result in the upgrade path I talked about above.  Only time will tell I suppose.

Brett

the more I think about it, the more I like this shifted male header:

Originally it was just a way to make a cheap protoShield. But if these can be made in decent quantities (I'm looking at making something that does,) it may provide a clean upgrade path for the arduino pin spacing problem.

it would let the current arduino mate with shields that are standard spaced, and let old shields mate with new arduinos that are standard spaced.  Shield makers could move to the new spacing without fear of being incompatible with the 60k+ Arduinos out there. Consumers could get a standard spaced 'duino and not worry that there's no shields for it.

am I being dumb here?  what am I missing

I just posted an instructable detailing a simple method for overcoming this problem: http://www.instructables.com/id/Embarassingly_Easy_Arduino_ProtoShield/

Without a large value for P the motor stops somewhat before the setpoint.  If P is too large things are unstable.

you may be experiencing a phenomenon known as "offset."  it can occur in non-I controllers if the internal baseline (known as the bias) is improperly initialized.

Not sure if that is what is happening here, but just a thought.  Before you switch the pid to Auto, make sure the output variable = 0 (assuming that 0 is "all stop")

I think this is one of those situations where assumptions are a killer.  all my statements are based on an assumed input variable.  something that represents the absolute motor position somewhere in that 5 revolution range.  I know that that's not what a motor sends, but it's usually pretty easy to take when the motor DOES send and turn it into something like that.

I think it might be time to show some code Ken that way we'll be on the same page.

I was assuming that the encoder was returning an absolute position between 0-15000, with the setpoint being a desired position somewhere in that range.  

in that scenario, the pid would keep adjusting its output (motor speed/direction) until input (position) = setpoint (desired position)

Also, I was hoping that the "D" term might let me achieve faster positioning.

That's a great point.  PD is used pretty often in motor control applications.  I had forgotten that. The bulk of my pid experience is in control of large chemical processes.

Any suggestions regarding an appropriate update interval if I use your PID library?

As a rule of thumb, I like to have the pid evaluate at least 10 times before it gets to the new setpoint.  this isn't an industry standard or anything, but in my experience it works.

Another method would be to start small (10mS say) and make it larger and larger until performance degrades.

Brett

I agree with Lefty (what are the odds?!) that the PID Library is probably WAY overkill for this.

that being said, you could totally do it.

Setpoint = desired position
Input = current position (no need to compute the difference.  the pid does that internally)
Output  = signal to the motor.  since you'll need to be able to spin the motor in both directions, you may need to use a technique similar to the one I detailed here: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1226431507/16#16

Lastly, with respect to tuning parameters. if you do the output method described above, you should be able to get away with a P-Only controller.  that is: P_Param = something, I_Param=0, D_Param = 0


Now let's circle back to why you probably don't need to use a pid. You could get the same performance as the P-only controller by doing this:

Code:

motorSpeed = (some_factor) * (Desired_Position - Current_Position)
if(motorSpeed>=0)
{
 //spin one way at motorSpeed
}
else
{
 //spin the other way at -motorSpeed
}

I'm all for people using the pid library, but it is quite big.  I'd say try the above code first, then move onto pid if needed.

Brett

So to set a limit I simply write in the same place I added in the "SetSampleRate",

myPID.SetOutputLimits(0,70);

? or something like that... if I want to max it out at 70% output?

Jetski,

The pid output will always range from 0% to 100%.  What SetOutputLimits does is specify what those values ARE.  By default, 0% = 0, and 100% = 255.

I chose those values as the default since those are the limits on a pwm output. I figured that's where most people would be sending the pid output.  The default works great until you want to send the output to something else. or, as in your case, you don't want to use the full pwm range.

If you want to limit the pid output to 70% of pwm range,  you first need to figure out what that value is.   use that value as the pid output max, and you're done.

so:
255*0.7 = 178.5
myPID.SetOutputLimits(0, 178.5);

hope this clears things up!

Brett

(also, as a side note: you can call this function in the setup area, but you can also call it on the fly.  if, in the middle of your program, you want to set new output limits, this function will work)

maybe you could add a light sensor (e.g. an LDR) to your list of parts.  point a PID controlled LED at it, and have the LED compensate for changes in ambient light.  room gets darker, led gets brighter.  by adjusting the tunings you can control how quickly that happens.

maybe a wide-angle infrared LED could go on that wrist strap.  every so often each strap sends out a unique sequence of pulses.  a conveniently placed detector in each room could figure out who's where.

kind of a half baked idea though.  is that a lot of equpment to have on your wrist? will the detectors be able to pick up the pulses on a bright day?  will you need to change a battery on each wrist strap every 20 minutes?  who knows.  

I think the shoplifting sensor makes more sense.  for visitors you need to make it sound an alarm every time they change rooms

how about an empirical method, baselined off of ambient temp? if a clear relationship is revealed, then you can just interpolate between a lookup table.

so for example, I would read the data you provided as "when the wall is 19deg above ambient, the tank is 44deg above ambient"

if you take various measurements you should be able to build a pretty good relationship between (wall-ambient) and (tank-ambient)  

I predict one of two things will happen.
1.  you'll get a pretty decent curve, which you can put into a lookup table.
2.  your values will be all over the place.  in which case no method using just those two temps will work.  there'll be some other factor you'll need to take into account.  maybe the amount of water in the tank or the rate of heating.

Hi everyone,  saw a couple of pid control posts on this thread and figured I throw up a shameless (ok, maybe a bit shameful) plug for the arduino PID library I wrote a few months back: http://www.arduino.cc/playground/Code/PIDLibrary

there's also been some healthy back-and-forth on this thread: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1226431507

the overhead may be a bit high for this application, maybe not.  figured I'd let people know it existed.

Cheers