Back
[05:43:44] <z64555> Quick! Somebody tell me mho's law. :P
[05:44:50] <z64555> hm. too early i guess
[05:45:46] <Jak_o_Shadows> v = ir
[05:46:06] <z64555> nope, that's ohm's law :P
[05:46:28] <Jak_o_Shadows> i = v/r
[05:47:18] <z64555> still ohm's law
[05:47:48] <Jak_o_Shadows> but you know, somehwat trnasposed
[05:47:52] <z64555> i = vg
[05:47:59] <Jak_o_Shadows> psh.
[05:47:59] <z64555> that's mho's law :P
[05:48:00] <Jak_o_Shadows> same thing
[05:48:17] <z64555> It is, but it's a pedantic riddle
[05:48:24] <z64555> g = 1/r
[05:48:42] <z64555> where g is conductance, in mho's
[08:55:43] <rue_bed> conductance is in siemens....
[09:22:00] rue_house changed topic of
#robotics to: Arduino controlled, 3d printed psycho robots! |
http://tom-itx.no-ip.biz:81/~webpage/index.php | project updates at 2am GMT! | A is for Android
[10:32:24] <mrdata> https://en.wikipedia.org/wiki/Siemens_%28unit%29
[10:32:40] <mrdata> mho is an alternative name for the same unit
[10:51:18] <theBear> i usually get my conductance in copper form, usually a wire
[12:57:18] <deshipu> http://www.hobbyking.com/hobbyking/store/__41217__Turnigy_TGY_S508H_300_Digital_Intelligent_Robot_Servo_7_5kg_0_16Sec_66g.html <-- a smart servo for $27
[13:01:07] <veverak> seen that
[13:01:09] <veverak> still...
[13:01:13] <veverak> depends on project I suppose
[13:01:27] <veverak> 12x27$... :)
[13:05:51] <Snert_> I like Turnigy. But you only find out what is dofferent after you buy one.
[13:06:05] <Snert_> and something has to be different.
[13:06:25] <Snert_> or it would be patent infringment.
[13:52:59] <deshipu> veverak: for an arm, though? 3x27...
[13:53:20] <deshipu> Snert_: everything is different
[13:53:26] <deshipu> Snert_: also, plastic gears
[13:55:11] <Snert_> not that the chinese would necessarily care about infringment.
[13:55:41] <Snert_> but I usually wind up feeling cheated when I get the "plastic gears" surprise....to use your example.
[13:56:44] <Snert_> HK and Turnigy don't really do excellent data sheets on their stuff and some detail is always missing it seems.
[13:57:01] <Snert_> or the servo mounting holes are just a little different or something.
[13:57:28] <Snert_> or different diameter or something.
[13:57:53] <Snert_> all of this is no big deal if ya don't mind messing with that stuff.
[14:02:13] <deshipu> I'm not saying it's a replacement for dynamixels
[14:02:20] <deshipu> just one more option
[14:03:14] <Snert_> yes, I understand.
[14:03:34] <Snert_> and it shows that these things are becoming more common now days.
[14:03:49] <deshipu> soon...
[14:04:00] <Snert_> I just wish the openservo project would have stock to ship and it would get off the ground.
[14:04:23] <Snert_> I want a servo with an ip addy :)
[14:04:26] <deshipu> there are other similar projects
[14:04:33] <veverak> deshipu: sounds much better true
[14:04:47] <deshipu> let's put an esp8266 on a servo :P
[14:56:05] <vaskozl_> Hey programring some pid and I've got a question.
[14:56:16] <vaskozl_> I've got a line following bug
[14:56:22] <vaskozl_> and two analog sensors.
[14:56:28] <vaskozl_> Now the thing is they are slightly mismatched
[14:56:38] <vaskozl_> So even if on the same colour the give slightly off values.
[14:56:47] <vaskozl_> Now that really isn't a problem when you have a P, or PD controller
[14:56:59] <vaskozl_> But if I add the Integral, it becomes a bitch.
[14:57:23] <vaskozl_> Because as soon as it goes to white or I pick it up the slight mismatch will cause the integral to become huge after a short amount of time and fuck it up.
[14:57:30] <vaskozl_> Is there a good way around this?
[14:58:43] <deshipu> trim them?
[14:58:53] <deshipu> so that they give the same result
[15:06:30] <z64555> yes. trim them
[15:07:03] <z64555> basically you'd either put in a resistor to have each sensor output the same voltage for the same color
[15:07:11] <z64555> or have the trim software define
[15:08:27] <deshipu> and by resistor z64555 means a pot
[15:08:43] <z64555> yes
[15:08:52] <deshipu> you would probably calibrate it on a white surface first
[15:09:23] <z64555> Now, for software defined values. For example, if your PID is operating on the difference between the sensor's voltages, you could add a trim constant where the sensors are fused
[15:10:07] <z64555> e_sensor = V_1 - V_2; // your PID input
[15:10:45] <z64555> e_sensor = V_1 - V_2 + trim; // your PID input plus trim. Positive values favor V1 while negative values facor V2
[15:12:29] <deshipu> it may also be a factor or something more complex
[15:12:37] <deshipu> depending on the sensor's characteristic
[15:12:53] <deshipu> s/factor/multiplier
[15:13:36] <vaskozl_> And the trim value would be established by some calibrarting function in the beggining?
[15:13:39] <z64555> in which case it would be: e_sensor = (trim * V_1) - V_2;
[15:13:51] <vaskozl_> Ok
[15:14:02] <z64555> Right, either a calibration routine at startup, or something you do manually
[15:14:24] <vaskozl_> I was kinda hoping that I could have it take care of itself some how and not have to manually offset or stretch it or something.
[15:14:50] <vaskozl_> I guess I'll do that.
[15:15:07] <deshipu> the calibration procedure could be automatic
[15:15:21] <deshipu> just requiring that it starts on a white surface, for instance
[15:15:27] <vaskozl_> I'm gonna do that.
[15:15:58] <deshipu> start with manual
[23:15:52] <orlock> hah
[23:16:00] <orlock> rue: found the bug in my 'scope controller
[23:16:12] <orlock> https://github.com/graphworlok/Equatorial_Basic_RA_DEC_LX200_Driver/blob/master/Equatorial_Basic_RA_DEC_LX200_Driver.ino
[23:16:53] <orlock> lines 36 and 45 , compared to 250 and 251
[23:17:29] <orlock> i'm trying to compare longs and unsigned longs
[23:23:51] <orlock> i found the bug in my telescope control code
[23:24:01] <orlock> doh
[23:26:34] <z64555> hm.
[23:26:50] <z64555> I might be becoming elitist when it comes to coding style
[23:26:53] * z64555 worries