#robotics Logs
Feb 07 2021
#robotics Calendar
12:21 AM mrdata_: https://imgur.com/gallery/UFEXJDJ
12:57 AM Jak_o_Shadows: voxels
01:01 AM Jak_o_Shadows: Also, wow, calibration of servo angles to actual real world angles is annoying
01:37 AM rue_mohr: yea I made a whole layer for it
01:37 AM rue_mohr: hey all those voxels are the same size
01:37 AM rue_mohr: thats not efficeint
01:38 AM rue_mohr: what happened to the subdivided ones?
01:39 AM rue_mohr: wow cool
01:39 AM rue_mohr: 6 cables, so there is some rotational control too?
02:22 AM Jak_o_Shadows: I need to write a generic calibration layer
02:23 AM rue_mohr: typedef struct servo_s {
02:23 AM rue_mohr: volatile float target;
02:23 AM rue_mohr: volatile char update;
02:23 AM rue_mohr: volatile float zero;
02:23 AM rue_mohr: volatile float scale;
02:23 AM rue_mohr: volatile float limL, limH; // software limits.
02:23 AM rue_mohr: } servo_t;
02:24 AM Jak_o_Shadows: What's update?
02:24 AM rue_mohr: threading
02:24 AM rue_mohr: you have a loop pushing to the servos and a loop calculating new positions
02:25 AM rue_mohr: if there has not been a new position defined, the system probably doesn't need to crowd the bus updating the hardware
02:25 AM Jak_o_Shadows: ah
02:25 AM rue_mohr: Status_t ServoSetTarget(servo_t *this, float target){
02:25 AM rue_mohr: target = Limit(target,this->limL,this->limH);
02:25 AM rue_mohr: if (this->target != target) {
02:25 AM rue_mohr: this->target = target;
02:25 AM rue_mohr: this->update++;
02:25 AM rue_mohr: }
02:25 AM rue_mohr: return OK;
02:25 AM rue_mohr: }
02:26 AM Jak_o_Shadows: I have the same sort of thing, but at a different layer
02:27 AM rue_mohr: <Jak_o_Shadows> I need to write a generic calibration layer
02:27 AM rue_mohr: zero and scale are the mapping
02:27 AM Jak_o_Shadows: I have it as the specific to servo protocol bit
02:30 AM rue_mohr: SimotaniouslyLinearlyInterpolateMultiAxis( &axies ); // initializes system
02:31 AM rue_mohr: oh
02:31 AM rue_mohr: I did another system too
02:31 AM rue_mohr: where I could save an array of transformation settings in a file
02:32 AM rue_mohr: typedef struct transBuffer_s {
02:32 AM rue_mohr: float * in;
02:32 AM rue_mohr: float * out;
02:32 AM rue_mohr: unsigned int count;
02:32 AM rue_mohr: transformSet_t *tf;
02:32 AM rue_mohr: } transBuffer_t;
02:32 AM rue_mohr: its in the middle of a system, so that doesn't make much sense
02:33 AM Jak_o_Shadows: I think I want this level to just be angle stuff
02:33 AM Jak_o_Shadows: Not even getting to pulse width part
02:33 AM rue_mohr: yea mine isn't
02:33 AM rue_mohr: its just a position
02:34 AM rue_mohr: but all servo adjustments will ahve a zero offset and a scale
02:34 AM rue_mohr: my track-and-record system uses 3 transforms
02:35 AM Jak_o_Shadows: I think the scale would be 1 though, unless you're doing stuff on the mechanical side?
02:35 AM rue_mohr: one "input units" to "real angles" one "input angles" to "output angles", and one "output angles" to "robot units"
02:35 AM rue_mohr: I have a capture arm
02:35 AM rue_mohr: I can capture to file as generic angles
02:36 AM rue_mohr: I can take that file and push it to one of a few robots
02:36 AM rue_mohr: nonally are the robots not zero/scaled the same, but their axies are mixed differently
02:37 AM rue_mohr: the transform config file lets me mix axies
02:39 AM rue_mohr: 3, 1, 3.000000, 7.000000
02:39 AM rue_mohr: 4, 4, 1.000000, 0.000000
02:39 AM rue_mohr: destination channel, source channel, scale, offset
02:40 AM rue_mohr: transformSetLoadFrom(&T, "testset.tf");
04:21 AM mrdata_: veverak, cool
10:30 AM veverak: thanks
05:51 PM Tom_L:
05:51 PM Tom_L:
05:51 PM Tom_L:
05:51 PM Tom_L:
05:51 PM Tom_L:
05:51 PM Tom_L: woops
05:59 PM veverak: so
05:59 PM veverak: I did price estimate of my robot (which is "profesisonal eyeballing")
06:00 PM veverak: servos/rpi - amazon prices
06:00 PM veverak: bolts/screws - local prices, but with heavy rounding up
06:01 PM veverak: 3d printed parts - slic3d model of assemblies (so screws/servos included) and used local prices of quality material
06:01 PM veverak: (used slic3r weight estimate)
06:01 PM veverak: ~400$
09:40 PM veverak: hmmm
09:40 PM veverak: anybody now how to handle PID crossing 0 ?
09:40 PM veverak: I have servomotor with 360 encoder
09:41 PM veverak: so there is a phase where the servo goes 4..3...2..1..0...359..358...
09:41 PM veverak: when PID is set to 0.5 and the servos croses to <0, it spins
09:41 PM veverak: it spins entire circle the other way
09:42 PM Tom_L: use integer value
09:42 PM veverak: that's like, not relevant to the rpoblem
09:43 PM Tom_L: yeah i'm not sure. i was just thinking what i did on my mill when it turns in reverse
09:44 PM Tom_L: not quadrature encoders?
09:44 PM veverak: nope
09:46 PM Tom_L: https://www.chiefdelphi.com/t/talon-pid-on-swerve-crossing-0-360-boundary/161356
09:46 PM Tom_L: may or may not apply
09:47 PM Tom_L: https://forum.arduino.cc/index.php?topic=475470.0
09:49 PM veverak: well, you got more luck at googling this
09:49 PM Tom_L: :)
09:50 PM veverak: !!!
09:50 PM veverak: there is that trick, damn it
09:50 PM veverak: I knew it! .... but forgot it :(
09:51 PM Tom_L: one of those get it?
09:51 PM veverak: (you rotate the target pos/encoder reading by 180 degrees wheere than is chance for error)
09:52 PM Tom_L: on mine i had a runaway issue when i would switch from fwd to rev quickly
09:53 PM Tom_L: did a couple things to eliminate it but i'm not using that code at all now
09:53 PM veverak: thought about using quaternions O:)
09:55 PM veverak: btw: the magic trick is that
09:55 PM veverak: 1 + 180 % 360
09:55 PM veverak: = 181
09:55 PM veverak: (359 + 180) % 360
09:55 PM veverak: = 179
09:57 PM veverak: shit, but pid won't like that jum[
09:57 PM Tom_L: not likely
09:58 PM veverak: 'D' term is the problem
09:59 PM Tom_L: http://linuxcnc.org/docs/2.8/html/man/man9/near.9.html
09:59 PM Tom_L: it won't apply but might give you an idea
09:59 PM Tom_L: i limited the differential value
09:59 PM veverak: yeah, got the somewhere I think
09:59 PM veverak: I can make this part of the code
10:00 PM Tom_L: if you want the source for that it's on github linuxcnc
10:00 PM veverak: yeah, ty
10:00 PM Tom_L: i'd have to dig for it but i'm sure you can figure it out
10:19 PM Tom_L: veverak, https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/components/near.comp
10:20 PM veverak: yeah, this part is easy
10:20 PM veverak: using it properly in PID is the trickier part :)
10:23 PM Tom_L: for velocity or position?
10:24 PM veverak: got serial servo with trash regulator for position control
10:24 PM veverak: so I am using velocity commands of the servo to control position
10:26 PM veverak: which just "control position with velocity"
10:26 PM Tom_L: i did something similar with a 2nd PID loop for spindle orient for tool change
10:27 PM Tom_L: so once it reached it's position it stopped
10:27 PM Tom_L: the spindle motor was so crappy though it would float around the position but never settle on it
10:28 PM Tom_L: i scrapped it for a vfd and bldc motor since then
10:29 PM veverak: damn it
10:29 PM veverak: I can't fix this without duplicating the PID code
10:30 PM veverak: the code simply has to be awar of the % going on in there and shit
10:32 PM Tom_L: is this for an avr, arm etc?
10:32 PM veverak: yes
10:32 PM Tom_L: 8bit?
10:33 PM veverak: no :)
10:33 PM veverak: CortexM4, 170Mhz
10:33 PM Tom_L: well that's a plus at least
10:33 PM veverak: I was allready looked bad at because I use floats for the PID only
10:33 PM veverak: *looked at bad
10:34 PM veverak: I think, I can make separate method for the PID, that handles modularity properly
10:37 PM veverak: let's say the value is `% m` -> apply m/2 offset when the `error` is <m/4 and the goal `g` is on problematic half: 'g` < m/4 or `g` > 3m/4
10:39 PM veverak: hmmm
10:39 PM veverak: is float modulo fast on arms?
10:39 PM Tom_L: i've never used arm sry
10:41 PM Tom_L: https://embeddedgurus.com/stack-overflow/2011/02/efficient-c-tip-13-use-the-modulus-operator-with-caution/
10:44 PM veverak: that's unsigned, I know it can do unsigned
10:44 PM veverak: was curious about floats
10:45 PM Tom_L: does it have a FPU?
10:45 PM veverak: yes
10:45 PM Tom_L: that should help alot
10:47 PM Tom_L: https://mcuoneclipse.com/2019/03/29/be-aware-floating-point-operations-on-arm-cortex-m4f/
10:47 PM Tom_L: they suggest avoiding floats
10:48 PM veverak: wut
10:49 PM veverak: Tom_L: it's, not relevant
10:49 PM Tom_L: k
10:49 PM veverak: I use -Wconversion from like ... a long time ago to avoid this kind of problems
10:49 PM Tom_L: like i said, i haven't programmed arm
10:49 PM veverak: but the conlucsion "do not use floats becuase they can be doubles!" is just stupid
10:50 PM Tom_L: a guy that used to do 68hc11 did similar to avoid floats on it
10:50 PM veverak: the conclusion should be "learn to user your compiler"
10:50 PM Tom_L: probably so
10:50 PM veverak: anyway, it seems that float modulo is few float operations anyway
10:50 PM veverak: should be fine
11:10 PM mrdata_: float modulo should be about as fast as division
11:54 PM veverak: well
11:54 PM veverak: in the bus I realized that I got this all wrong
11:54 PM veverak: I can just add offset to the used angle range
11:54 PM veverak: that is used at all times
11:55 PM veverak: for this context, it's ont 0...360, but rather 0...240 by manufacturer
11:55 PM veverak: which is -10...250 in reality
11:55 PM veverak: which is 350...359,0....250 as used in servo