Back
[02:41:01] <deshipu> veverak: yes, mostly for force sensing
[02:41:10] <deshipu> veverak: but that's too complex mechanically
[02:41:29] <deshipu> veverak: for a robot that anyone should be able to build
[03:26:14] <veverak> but maybe
[03:26:16] <veverak> :)
[03:26:40] <deshipu> I rely on the felxibility of the servo horns instead
[03:26:58] <deshipu> I plan to try and put some hal sensors and magnets on them, to measure deformation
[05:49:34] <anonnumberanon> really nice design but very low torque and very expensive:
http://www.aliexpress.com/store/product/RCOMG-D1-LP-CP08S-Middle-Aluminum-Case-Coreless-digital-servo-rc-car-servo/1906422_32458243434.html
[06:24:11] <LiohAu> anonnumberanon: isn't feetech better ?
[06:24:38] <LiohAu> http://www.feetechrc.com/product/digital-servo/23kg-cm-high-torque-hv-metal-case-digital-car-servo-fi8625m/
[06:25:44] <LiohAu> torque * 2,5, but a little bit slower
[06:26:28] <deshipu> wow, that's a lot of gears
[06:27:01] <LiohAu> ?
[06:27:22] <LiohAu> where did you see the number of gears
[06:28:01] <deshipu> http://g01.a.alicdn.com/kf/HTB1TB9cJpXXXXbBXVXXq6xXFXXXo/RCOMG-D1-LP-CP08S-Middle-Aluminum-Case-Coreless-digital-servo-rc-car-servo.jpg
[09:26:11] <veverak> http://i.imgur.com/Bt0nlQ9.jpg
[09:26:18] <veverak> <3 label maker
[09:26:20] <veverak> :D
[09:26:51] <myself> nice
[09:28:35] <SpeedEvil> How does it make labels
[09:28:37] <SpeedEvil> Oh - nvm
[09:56:55] <deshipu> pitch?
[09:59:23] <veverak> https://upload.wikimedia.org/wikipedia/commons/5/54/Flight_dynamics_with_text.png
[09:59:25] <veverak> cam tilt
[09:59:52] <deshipu> you are putting a camera on it?
[10:00:56] <veverak> yep
[10:00:58] <veverak> :)
[10:01:04] <veverak> deshipu: that part works now
[10:01:12] <veverak> except that I don't know how to control those servos yet
[10:01:34] * veverak was able to get low latency via ROS and raspi cam over wifi
[10:13:37] <deshipu> https://www.youtube.com/watch?v=TqvW_6PmBIA
[10:17:47] <Snert> that little spider is so sweet :)
[10:18:26] <Snert> that is exactly what I would pay $2,500.00 for.
[10:19:23] <Snert> though I'm sure it would cost way more than that
[10:20:43] <SpeedEvil> veverak: define low
[10:21:07] <veverak> dunno
[10:21:11] <veverak> didn't measured
[10:21:36] <veverak> SpeedEvil: time delay with "fast move hand in front of camera and wait till it's on screen"
[10:21:41] <veverak> was good enough for me
[10:21:42] <veverak> :)
[10:22:56] <SpeedEvil> you can measure
[10:23:04] <SpeedEvil> you take the camera, and point it at the monitor
[10:23:08] <SpeedEvil> then you tilt it a little
[10:23:21] <deshipu> wheeee
[10:23:32] <SpeedEvil> you can then work out which frame is which, and also multiply the visible frames by a lot
[10:23:52] <SpeedEvil> how were you doing it?
[10:23:59] <veverak> what exactly?
[10:24:12] <SpeedEvil> roughtly
[10:26:41] <veverak> ?
[10:26:43] <veverak> :)
[17:22:15] <anonnumberanon> serial workshop, now!
[17:22:24] <anonnumberanon> https://www.youtube.com/watch?v=U1kr9gYviMc&index=48&list=PLE72E4CFE73BD1DE1
[17:30:03] <veverak> hmm
[17:30:06] <veverak> been thinking
[17:30:09] <veverak> for walking robot
[17:30:15] <veverak> there are several algorithms/ways one can use
[17:30:21] <veverak> and each its "good" for specific case
[17:30:36] <veverak> question is, how to manage system which switch them?
[17:31:00] <veverak> and I start to like the idea that each algo/way, calculate's "priority" value for itself
[17:31:28] <veverak> based on sensory/state/goal values
[17:31:49] <veverak> and algo/way with biggest priority is given control over robot to do what he wants
[17:32:34] <ace4016> have a score function
[17:32:43] <ace4016> whoever scores highest takes control
[17:32:47] <veverak> yeah
[17:32:52] <veverak> that's more or less what I want
[17:32:54] <veverak> :)
[17:33:18] <ace4016> but the hard part is coming up with a way of evaluating each
[17:33:23] <veverak> this way it could be easy to develop new algorithms and so on
[17:33:34] <veverak> ace4016: it should evalute itself
[17:33:44] <veverak> but yeah, this can easily go out of control
[17:33:51] <veverak> have to figure out how to keep it sane
[17:33:54] <veverak> :)
[17:34:44] <veverak> for example
[17:35:24] <veverak> when fast walking algorithm, will tell algorithm that stabilizes robot "he you, please increase your priority over 100 points for 2sec, thanks!"
[17:36:01] <veverak> with behavior like this the whole idea can get really messy ...
[17:37:02] <veverak> on the other hand
[17:37:23] <veverak> things like that robot ended on it's "roof" ... (fliped)
[17:37:27] <veverak> could be solved easily
[17:38:04] <veverak> just make one algorithm which can flip robot back, and make him that when sensors indicates that it;s fliped over, it's pripority skyrockets
[17:38:06] <veverak> hmm
[17:38:22] <veverak> it makes sense to estabilish some values as examples what to do
[17:39:10] <veverak> like " 100 points got 'stand on place" algorithm, 500 points normal walk, 700 points warnings situations, 800 high priority and 900 dangerous ones"
[17:39:12] <anonnumberanon> "highest score corresponds to thing that maximizes chances of robot not falling"
[17:39:15] <anonnumberanon> start with that
[17:39:40] <veverak> that's also part of evaluation
[17:39:51] <veverak> and I think that you fand many things that are part of evaluation
[17:39:54] <veverak> or should be
[17:39:59] <veverak> but you will also find that not everytime
[17:40:16] <veverak> => thous my idea that each thing should calculate it's score by itself
[17:40:17] <veverak> :)
[17:40:33] <veverak> and have some shared ways of calculating it
[17:41:10] <veverak> or shared services that evulates ie. "chance of failing" and things that decide based on that, just includes it in it's calculations
[17:42:06] <veverak> ok, I think that effectivnes of this solution can be good enough for my needs
[17:42:15] <veverak> but have to properly design evaluation system
[17:42:18] <veverak> good
[17:42:19] <veverak> ;)
[17:43:28] <anonnumberanon> are you anton?
[17:43:44] <anonnumberanon> with the 3d printed large humanoid?
[17:44:02] <veverak> anton?
[17:44:04] <veverak> nope
[17:44:06] <anonnumberanon> nvm
[17:44:09] <anonnumberanon> antonius
[17:47:48] <veverak> anonnumberanon: my main goal is software mainly
[17:47:51] <veverak> but using deshipus tote
[17:48:06] <veverak> "little cute quadruped"
[17:48:08] <veverak> :)
[17:49:11] <deshipu> veverak: you can switch gaits fluently
[17:49:35] <deshipu> veverak: changing leg order is not hard, and changing the duty cycle of the gait can be fluent
[17:49:41] <veverak> I know
[17:49:51] <veverak> deshipu: that system doesn't make fluent change hard/imposible
[17:50:15] <deshipu> what I mean is that you don't have individual algorithms, it's a fluent spectrum
[17:50:47] <veverak> yeah
[17:50:50] <veverak> but my idea is
[17:50:51] <deshipu> a creep only differes from a trot in the duty cycle, and you have the ripple gaits in between
[17:51:17] <anonnumberanon> veverak, ah i thought this was humanoid
[17:51:31] <anonnumberanon> you want to improve tote? I don't get it
[17:51:35] <veverak> "standing", "walking" (switching duty cycles), "simple trot", "stand up when you fall"
[17:51:51] <veverak> deshipu: what you described is one of the for main things i would use
[17:52:05] <veverak> ("simple trot" is backup until "walking" is properly developed)
[17:52:58] <veverak> best roadplan is
[17:53:10] <veverak> that during development, there will be several multiple nodes
[17:53:30] <veverak> more likely most of them will be turned off entirely, just for developing/testing multiple ways
[17:53:41] <veverak> and in the end it will endup as one node only
[17:53:46] <veverak> :)
[17:54:15] <deshipu> by the way, have you seen that spring-based gait planning?
[17:54:35] <veverak> I have paper on that
[17:54:40] <veverak> afaik
[17:54:42] <veverak> :D
[17:54:48] <anonnumberanon> what is a node?
[17:54:48] <veverak> deshipu: spring-based like... ?
[17:55:06] <veverak> anonnumberanon: ehmm, algo/way of moving in terms of algo
[17:55:08] <deshipu> https://hackaday.io/project/3229-pengu-q1-quadruped/log/10754-virtual-spring-based-gaitgeneration-v01
[17:55:18] * veverak switches term because practically, it will be node in ROS
[17:55:19] <veverak> :)
[17:56:03] <veverak> deshipu: interesting
[17:56:37] <deshipu> step planning is actually a big problem
[17:56:44] <veverak> btw
[17:56:46] <deshipu> you can use feedback from sensors to do it
[17:57:12] <veverak> in one paper, they suggested that it can be improved greatly if there are mechanicall springs/dumpers on the legs
[17:57:23] <deshipu> yes
[17:57:25] <veverak> but nah, not sure which paper that was ...
[17:57:30] <deshipu> the cheetah cub one
[17:57:35] * veverak is still in phase when he reads a lot
[17:57:58] <veverak> only paper that is processed is about using evolution algorithm to figure out ebst parameters for walking algo
[17:58:00] <veverak> :)
[17:58:07] <deshipu> but that only works when the gait is synchronized with the harmonic of those springs
[17:59:12] <veverak> (and I want to try that way of getting parameters one day0
[18:01:53] <veverak> deshipu: well, I was thinking that giving tote some way to absorb some force on legs
[18:01:57] <veverak> or, how to tell it...
[18:02:01] <veverak> nothing drasticall
[18:02:19] <veverak> but that's maybe because my tote got 3d printed tibia parts
[18:02:24] <veverak> which are maybe too sturdy
[18:02:26] <veverak> :0
[18:02:27] <veverak> :)
[18:03:18] <veverak> deshipu: also, been thinking about sensors to detect if leg is touching ground or not
[18:03:29] <veverak> it really seems like measuring servo current is best way
[18:04:14] <veverak> or something like that
[18:04:41] <veverak> nah, need more reading
[18:04:43] <veverak> many papers to go
[18:04:46] <veverak> :)
[18:15:48] <jhylands> veverak - I have spring-loaded feet with a tiny rare earth magnet and an analog hall effect sensor
[18:16:02] <veverak> pics?
[18:17:02] <jhylands> hang on
[18:17:25] <jhylands> http://huv.com/Roz-CompliantLegs-02.jpg
[18:17:38] <jhylands> http://huv.com/Roz-CompliantLegs-01.jpg
[18:20:30] <jhylands> Here's a close up:
https://app.box.com/s/r1vy1aa2ovxmsvil2ont75bg9kim21ro
[18:21:09] <jhylands> you can see the tiny hall effect sensor (SOT-23 surface mount, hand-soldered to the end of the ribbon cable)
[18:21:25] <jhylands> and the tiny cylinder magnet, 1/16" diameter, 1/4" long
[18:21:56] <jhylands> I have to rebuild them, because the 3D printed part that the sensor is against is too weak
[18:21:59] <jhylands> and it broke
[18:22:08] <jhylands> so I'm going to machine that piece out of aluminum
[18:22:13] <jhylands> and 3D print the rest of it
[18:22:52] <jhylands> I also got new hall effect sensors, because those ones are 5 volts, and with ARM boards you can only handle 3.3 volts on analog inputs
[18:23:01] <z64555> huh? constom made suspension
[18:23:04] <z64555> *custom
[18:23:11] <jhylands> yeah, basically
[18:23:29] <veverak> I see
[18:23:33] <veverak> jhylands: interesting!
[18:23:36] <veverak> :D
[19:14:01] <anonnumberanon> rue_bed, sup, got non-arduino serial to computer to work (just chars for now)
[19:14:05] <anonnumberanon> like, fuck yeah
[19:14:24] <anonnumberanon> serial to computer or to chip, whatever
[19:15:54] <veverak> daaamn
[19:15:58] <veverak> those hall effect sensors are cheap
[19:16:01] <veverak> :)
[19:17:25] <myself> I was thinking barometric might be fun too but hall is definitely cheaper
[19:53:29] <anonnumberanon> rue_bed, when we talked about packing bits with serial, how does it work literally speaking? 1 start bit, the data bits (let's say 16 bits) then parity then stop bit?
[21:00:54] <rue_shop3> you need to frame your bytes?
[21:01:14] <rue_shop3> wireless link?
[21:01:21] <rue_shop3> what are you up to
[21:01:25] <rue_shop3> yes I'm takling to you
[21:01:28] <rue_shop3> and your not there
[21:01:31] <rue_shop3> and when you come back
[21:01:37] <rue_shop3> guess who isnt' gonna be here??
[21:01:39] <rue_shop3> its me!
[21:01:43] <rue_shop3> :P
[21:03:55] <anonnumberanon> damn
[21:04:01] <rue_shop3> your so far behind your in frone
[21:04:05] <anonnumberanon> i missed this crazy old fool by two minutes
[21:04:08] <anonnumberanon> oh, you're there
[21:04:23] <rue_shop3> how amny bits you need to transfer?
[21:04:44] <anonnumberanon> like we said last time, so 17 numbers of say, 12 bits
[21:04:47] <anonnumberanon> or was it 10
[21:04:49] <anonnumberanon> or 11
[21:04:52] <anonnumberanon> yeah 12
[21:04:59] <anonnumberanon> cause servo
[21:05:17] <anonnumberanon> turns out there is low byte and high byte
[21:05:21] <rue_shop3> so you need to send 12 bit?
[21:05:22] <rue_shop3> ?
[21:05:53] <anonnumberanon> well not only 12, 12 times 17 servos, and add the parities and start/stop bits.
[21:06:15] <rue_shop3> so how many address bits do you need and how many data bits do you need?
[21:07:27] <rue_shop3> how about an 5 bit servo address, and 16 bits of servo position
[21:07:30] <anonnumberanon> #define address bits
[21:07:32] <anonnumberanon> please
[21:07:44] <rue_shop3> ok so you mak a header byte
[21:07:48] <rue_shop3> lets use 255
[21:07:55] <anonnumberanon> no man that was a joke
[21:08:04] <rue_shop3> so you send that first, to basically flag the start of a packet
[21:08:07] <anonnumberanon> I talked to you about something, but using header language.
[21:08:16] <anonnumberanon> I mean defines language.
[21:08:25] <rue_shop3> then lets send the servo address byte, lets just use 8 bits
[21:08:37] <rue_shop3> then send the MSB of the 16 bit position
[21:08:45] <rue_shop3> then send the LSB of the 16 bit position
[21:08:48] <rue_shop3> 4 bytes
[21:08:54] <rue_shop3> [255][servo #][MSB][LSB]
[21:09:05] <rue_shop3> where servo number is broken up like this
[21:09:09] <rue_shop3> [ AAAB BCZZ ]
[21:09:11] <anonnumberanon> Why send the addresses instead of just all the servos in order?
[21:09:15] <rue_shop3> its 8 bits
[21:09:23] <rue_shop3> A = servo address, 0-7
[21:09:28] <rue_shop3> B = servo board, 0-3
[21:09:41] <rue_shop3> but that works as a unified 5 bit address
[21:10:03] <rue_shop3> C can be a cache flag, to say that you dont want the position to be acted on immediatly
[21:10:10] <rue_shop3> Z is just unused bits
[21:10:39] <rue_shop3> using a servo address means that you only have to update the servos that acutlly changed position values
[21:10:49] <rue_shop3> whcih is like RLE compression
[21:10:59] <rue_shop3> which will speed things up a lot
[21:11:14] <rue_shop3> you would be surprised how often servo positons dotn change between update cycles
[21:11:24] <rue_shop3> the cache flag means that you can sync all the axies
[21:11:52] <rue_shop3> you can write a state machine that reads the packets
[21:12:13] <rue_shop3> it could look something like this
[21:12:15] <rue_shop3> data = USART_Receive();
[21:12:15] <rue_shop3> if (0) {
[21:12:15] <rue_shop3> } else if (ptr == 0) {
[21:12:15] <rue_shop3> if (data == 255) ptr++;
[21:12:15] <rue_shop3> } else if (ptr == 1) {
[21:12:16] <rue_shop3> pkt[0] = data;
[21:12:18] <rue_shop3> if (InBoundsI((data & 31), BASEADDRESS, (BASEADDRESS+7)) || (data == 0xFF) ){ // if this is for us, carry on
[21:12:21] <rue_shop3> ptr++;
[21:12:23] <rue_shop3> } else {
[21:12:27] <rue_shop3> ptr = 20; // otherwise, ignore the rest of the packet
[21:12:29] <rue_shop3> }
[21:12:31] <rue_shop3> } else if (ptr == 2) {
[21:12:33] <rue_shop3> pkt[1] = data;
[21:12:35] <rue_shop3> ptr++;
[21:12:37] <rue_shop3> } else if (ptr == 3) {
[21:12:39] <rue_shop3> ptr = 0;
[21:12:41] <rue_shop3> temp = pkt[1];
[21:12:43] <rue_shop3> temp = (temp<<8);
[21:12:45] <rue_shop3> temp = temp | data;
[21:12:47] <rue_shop3> if (temp > 31000) temp = 31000;
[21:12:49] <rue_shop3> if (pkt[0] < 32) {
[21:12:51] <rue_shop3> // immediate move
[21:12:53] <rue_shop3> position[(pkt[0] & 0x07)] = temp;
[21:12:57] <rue_shop3> } else if ( pkt[0] < 64) {
[21:12:59] <rue_shop3> // cache position
[21:13:01] <rue_shop3> cache[(pkt[0] & 0x07)] = temp;
[21:13:03] <rue_shop3> } else if (pkt[0] == 0xFF) {
[21:13:05] <rue_shop3> // enguage cached positions
[21:13:07] <rue_shop3> position[0] = cache[0];
[21:13:09] <rue_shop3> position[1] = cache[1];
[21:13:11] <rue_shop3> position[2] = cache[2];
[21:13:13] <rue_shop3> position[3] = cache[3];
[21:13:15] <rue_shop3> position[4] = cache[4];
[21:13:17] <rue_shop3> position[5] = cache[5];
[21:13:19] <rue_shop3> position[6] = cache[6];
[21:13:21] <rue_shop3> position[7] = cache[7];
[21:13:23] <rue_shop3> }
[21:13:27] <anonnumberanon> exit(0);
[21:13:27] <rue_shop3> } else if (ptr == 20) { // ignoring data
[21:13:29] <rue_shop3> ptr++;
[21:13:31] <rue_shop3> } else if (ptr == 21) { // ignoring data
[21:13:33] <rue_shop3> ptr = 0;
[21:13:35] <rue_shop3> }
[21:13:44] <rue_shop3> where the various functions and macros are defined as required
[21:14:59] <rue_shop3> you would, of course, want to put that in main and have it run interruptable so that the interrupt system could keep the pwm pulses going properly
[21:15:35] <anonnumberanon> still working on pwm generation, now that i have serial without arduino im closer to goal
[21:16:08] <anonnumberanon> still using the method of polling micros() though, to have all pwm made within 3 milliseconds
[21:16:15] <rue_shop3> you could use two timers, a low resolution one (8 bit would do ) to start the pulses and a high resolution one (16 bits) to time the pulses themselvs
[21:16:45] <rue_shop3> your low resolution timer could be initialized something like...
[21:16:49] <rue_shop3> / 8 bit T/C
[21:16:50] <rue_shop3> / every 2.5ms counter 2
[21:16:50] <rue_shop3> ISR( TIMER0_COMPA_vect) {
[21:16:50] <rue_shop3>
[21:16:50] <rue_shop3> idx++;
[21:16:50] <rue_shop3> if (idx == 8) idx = 0;
[21:16:52] <rue_shop3>
[21:16:53] <anonnumberanon> working on making my own micros() maybe at 62.5 nanoseconds precision, I have to make sure adjusting the prescaler that way does not make the chip too busy or something like that
[21:16:54] <rue_shop3> OCR1A = 8000 + position[idx];
[21:16:58] <rue_shop3>
[21:17:00] <rue_shop3> TCNT1 = 0;
[21:17:02] <rue_shop3>
[21:17:04] <rue_shop3> if (idx < 2) {
[21:17:06] <rue_shop3> SetBit(idx, PORTB);
[21:17:08] <rue_shop3> } else {
[21:17:10] <rue_shop3> SetBit(idx, PORTD);
[21:17:12] <rue_shop3> }
[21:17:14] <rue_shop3>
[21:17:16] <rue_shop3> startCounter();
[21:17:18] <rue_shop3> }
[21:17:37] <rue_shop3> er no wait, that would be how you would handle the low resolution timer overflow...
[21:17:43] <rue_shop3> so your timer init would look like...
[21:17:49] <rue_shop3> void countersInit() {
[21:17:49] <rue_shop3> // counter 1A is used to time out the pwm pulse, a count of 8000 produces the min pulse duration.
[21:17:49] <rue_shop3> // counter 1A ( 16 bit) to fast pwm, no output control, interrupt enabled, clock source off.
[21:17:49] <rue_shop3> //
[21:17:49] <rue_shop3> // fast pwm: WGM = 1111 cs off: CS = 000
[21:17:49] <rue_shop3>
[21:17:51] <rue_shop3> TCCR1A = b00000000; // [ COM1A1 | COM1A0 | COM1B1 | COM1B0 | | | WGM11 | WGM10 ]
[21:17:53] <rue_shop3> TCCR1B = b00001000; // [ ICNC1 | ICES1 | | WGM13 | WGM12 | CS12 | CS11 | CS10 ]
[21:17:57] <rue_shop3> TIMSK1 = b00000010; // [ | | ICIE1 | | | OCIE1B | OCIE1A | TOIE1 ]
[21:17:59] <rue_shop3>
[21:18:01] <rue_shop3>
[21:18:03] <rue_shop3>
[21:18:05] <rue_shop3> // counter 0A is used to start pwm cycles
[21:18:07] <rue_shop3> // counter 0A ( 8 bit ) to CTC cdiv=256 ocr0A = 156, interrupt enabled, clock source on.
[21:18:09] <rue_shop3> //
[21:18:11] <rue_shop3> // CTC: WGM = 010 cdiv=256: CS=100
[21:18:13] <rue_shop3>
[21:18:15] <rue_shop3> TCCR0A = b00000010; // [ COM0A1 | COM0A0 | COM0B1 | COM0B0 | | | WGM01 | WGM00 ]
[21:18:17] <rue_shop3> TCCR0B = b00000100; // [ FOC0A | FOC0B | | | WGM02 | CS02 | CS01 | CS00 ]
[21:18:19] <rue_shop3>
[21:18:21] <rue_shop3> OCR0A = 156;
[21:18:23] <rue_shop3> TIMSK0 = b00000010; // [ | | | | | OCIE0B | OCIE0A | TOIE0 ]
[21:18:25] <rue_shop3> }
[21:18:29] <anonnumberanon> is it bad to poll the timer with prescaler 1?
[21:18:34] <rue_shop3> yup
[21:18:36] <anonnumberanon> why
[21:18:40] <rue_shop3> you dont poll timers, you use the interrupts
[21:18:55] <rue_shop3> the interrupts make things happen with consistant timing
[21:19:28] <rue_shop3> it takes the processor the same (+-1) number of cycles to execute
[21:19:48] <rue_shop3> your loop can miss the timing by as many cycles as it takes to execute the loop
[21:19:52] <rue_shop3> use the hardware timers
[21:20:46] <anonnumberanon> you mean, not some register, the timers' registers?
[21:21:12] <rue_shop3> the high res timer wouldn't ahve to do much if the system is set up right,
[21:21:17] <rue_shop3> / 16 bit T/C 0
[21:21:17] <rue_shop3> / variable .5ms to 2ms counter 1
[21:21:17] <rue_shop3> ISR( TIMER1_COMPA_vect ) {
[21:21:17] <rue_shop3> PORTB = 0x00;
[21:21:17] <rue_shop3> PORTD = 0x00;
[21:21:18] <rue_shop3> stopCounter();
[21:21:20] <rue_shop3>
[21:21:22] <rue_shop3> }
[21:21:46] <rue_shop3> timers are a hardware system that works off the system clock to generate events at set timers of intervals
[21:27:27] <rue_shop3> usefull macros could be
[21:27:33] <rue_shop3> #define stopCounter() TCCR1B = b00011000;
[21:27:34] <rue_shop3> #define startCounter() TCCR1B = b00011001;
[21:29:28] <anonnumberanon> how much time to do a >= operation on two unsigned long?
[21:30:28] <rue_shop3> about 6 cycles
[21:30:47] <anonnumberanon> why doesn't it depend on size of data being compared?
[21:31:03] <rue_shop3> it does, char would be about 4 cycles
[21:33:54] <anonnumberanon> I think i may be able to get a bit less than half a microsecond of jitter on each pulse.
[21:34:12] <mrdata> how
[21:34:32] <anonnumberanon> mrdata, it's magic
[21:37:02] <mrdata> bring me the magic
[21:37:44] <anonnumberanon> nice bit-length message match
[21:39:02] <anonnumberanon> ((62.5 ns * 7) * (17 servos)) / 17
[21:39:11] <anonnumberanon> is like 400 nanoseconds
[21:40:15] <anonnumberanon> 1 / 16M = 62.5 ns
[21:40:44] <anonnumberanon> or 6.25
[21:41:01] <anonnumberanon> maybe reduce my last proposal by a factor of 10
[21:41:11] <anonnumberanon> so 40 nanosecond jitter
[21:41:17] <anonnumberanon> but I'm sure all this is wrong
[21:41:29] <anonnumberanon> must put fingers into the gears and bits to check
[21:41:37] <anonnumberanon> MUST
[21:41:45] <anonnumberanon> ACCOMPLISH
[21:41:47] <anonnumberanon> THE MISSION
[21:42:11] <anonnumberanon> bbl working on car
[21:52:05] <anonnumberanon> 62.5 it is
[21:52:13] <anonnumberanon> potential jitter 437 ns
[21:55:04] <rue_shop3> well if you dont want help, dont ask...
[21:56:01] <anonnumberanon> thanks rue_shop3
[21:56:22] <anonnumberanon> im going to attempt your way and my way because i understand neither of them fully yet
[21:57:02] <anonnumberanon> now really gotta go do an hour on my car, ive been in electronics for a while today plus have to look for jobs for 3 hours more
[21:57:14] <anonnumberanon> life sucks right now it's not like 2 months ago =)
[21:57:28] <anonnumberanon> America hates its engineers.
[21:58:43] <rue_shop3> I love this spring strap I made for my goggles
[23:19:10] <flyback> eadthem, ltns
[23:19:22] <eadthem> hey
[23:21:37] <flyback> rue_shop3, BMCC
