#robotics Logs

Apr 14 2014

#robotics Calendar


01:37 the_drizzle Hi there, new here. I'm having trouble accessing a research paper and was hoping somebody here may be able to help...
01:37 rue_more ok tell us more
01:37 the_drizzle http://hip.sagepub.com/content/early/2013/12/03/0954008313513915.abstract
01:38 the_drizzle my institute does not seem to have a subscription...
01:45 GargantuaSauce i suspect that paper can be summarized with "they all failed"
01:56 the_drizzle I suspect you're correct,
02:08 password2 goodday
02:11 password2 would 3 H-bridge arrangements be enough to drive most steppers?
02:11 GargantuaSauce why 3?
02:12 password2 such that it has 6 outputs
02:12 password2 i want to build a generic driver
02:13 GargantuaSauce the center taps of unipolar steppers are not driven by h-bridges, but rather the high side of the power supply
02:13 GargantuaSauce you just need 2 h bridges
02:13 password2 ah
02:13 password2 ok , thats good
02:15 password2 and i assume 12v 10W would be enough for most steppers
02:16 rue_more I need a binary strdup
02:18 GargantuaSauce 24V might be a good idea
02:18 password2 ok
02:18 GargantuaSauce what does that even mean rue_more
02:18 GargantuaSauce memcpy?!
02:19 rue_more no it needs to alloc the memory for me first
02:20 GargantuaSauce sooo a function that calls malloc and memcpy....
02:21 rue_more yup
02:37 password2 ok last qeustion , what is the maximun rate i need to be able to switch?
07:40 -verne.freenode.net:#robotics- [freenode-info] if you're at a conference and other people are having trouble connecting, please mention it to staff: http://freenode.net/faq.shtml#gettinghelp
18:45 robotustra_ http://friends.kz/uploads/posts/2012-02/thumbs/1330259132_34.jpg
18:48 robotustra_ http://friends.kz/uploads/posts/2012-02/thumbs/1330259160_59.jpg
18:51 robotustra_ http://www.nkj.ru/upload/iblock/f6b/f6b6791c02ab0ae24d2009c849390b29.jpg
20:15 rue_more while(1) {
20:15 rue_more data = USART_Receive();
20:15 rue_more if (0) {
20:15 rue_more } else if (ptr == 0) {
20:15 rue_more if (data == 255) ptr++;
20:15 rue_more } else if (ptr == 1) {
20:15 rue_more pkt[0] = data;
20:15 rue_more ptr++;
20:15 rue_more } else if (ptr == 2) {
20:15 rue_more pkt[1] = data;
20:15 rue_more ptr++;
20:15 rue_more } else if (ptr == 3) {
20:15 rue_more ptr = 0;
20:15 rue_more temp = (pkt[1]<<8)|data;
20:16 rue_more if (temp > 24000) temp = 24000;
20:16 rue_more position[pkt[0] & 0x07] = temp;
20:16 rue_more }
20:16 rue_more }
20:16 rue_more who can spot the error
20:17 armyofevilrobots So, not an error, but if 0, srsly?
20:17 armyofevilrobots are you meaning to || data in the temp assignment?
20:18 rue_more the if(0) makes all the rest } else if () {
20:18 rue_more bitwise did I mix up my bitwise?
20:18 armyofevilrobots I know.
20:18 armyofevilrobots are you trying to make temp = (pkt[1] shift_left 8) binary_or data ?
20:19 rue_more 8 to 16 bit conversion
20:19 rue_more msb first
20:19 rue_more I wonder if it keep it 8 bits when it shifts it
20:20 armyofevilrobots Ah, OK, I didn't get what you were trying to do there.
20:20 rue_more wh I shoudl do is make sure the serial data is getting there properly...
20:22 rue_more ooo
20:22 rue_more I think that was it
20:22 rue_more I'll find out soon
20:23 rue_more no
20:23 robotustra_ rue
20:23 rue_more its operating channel 2, it should be operating 1
20:23 robotustra_ what you was goint to do with this code?
20:24 rue_more this code is the serial data reciever for my 8 servo controller
20:24 robotustra_ what do you mean under "if (0)"
20:25 robotustra_ this is an empty branch, what is it for?
20:25 rue_more by writing if (0) {
20:25 rue_more every other condition can be written as
20:25 rue_more } else if ( ) {
20:25 GargantuaSauce yeah that totally makes it cleaner
20:25 rue_more which makes them all the same, hence I can re-arrange them or drop in ones from other code
20:25 robotustra_ do you know "switch(){case:}"
20:25 rue_more its like a switch statement where you can do anything you want
20:26 rue_more technically, that shoudl probably BE a switch statement, wont go there
20:26 robotustra_ IMHO it's very bad style of programming
20:26 rue_more nom, its more universal
20:26 GargantuaSauce this is rue-code were talking about
20:26 robotustra_ I would prefer not to create dummy branches
20:27 rue_more if(0) is disolved by the compiler
20:28 rue_more it might be fun to see how much non-code a source file could be stuffed with
20:30 robotustra_ if (ptr == 0)
20:30 robotustra_ {
20:30 robotustra_ if (data == 255) ptr++;
20:30 robotustra_ }
20:30 Tom_itx mother nature sure can play tricks
20:30 rue_more robotustra, thats stupid code
20:30 Tom_itx it was 82F yesterday, snowed today and the low in the 20's tonight
20:30 rue_more its a waste of vertical space
20:30 robotustra_ if (ptr == 0 && data == 255) prt++;
20:31 rue_more no function should be longer than 1 screen at a reasonable font size
20:31 Tom_itx 4pt?
20:31 rue_more robotustra, no, if data is a pointer that is null that will segfault
20:31 rue_more so, you cant always do that
20:31 rue_more and you should ()() to make sure the compiler dosn't get creative
20:32 GargantuaSauce >segfault
20:32 GargantuaSauce arent we talking about embedded?
20:32 rue_more cause cause a uc cant TELL you it segfaulted, dosn't mean it dosn't
20:33 GargantuaSauce and if 0 is a perfectly valid address, what then?
20:33 rue_more its not even valid on a stupid motorola chi\
20:33 robotustra_ I suspect that he wanted to get into the next "if" condition
20:34 robotustra_ but put "else"
20:34 robotustra_ after increment of ptr
20:34 rue_more idea
20:34 robotustra_ while(1) {
20:34 robotustra_ data = USART_Receive();
20:34 robotustra_ if (0) { }
20:34 robotustra_ else
20:34 robotustra_ if (ptr == 0)
20:35 rue_more thats, again, a waste of verticle space
20:35 robotustra_ bljad'
20:35 armyofevilrobots Null doesn't always equal zero: http://c-faq.com/null/machexamp.html
20:35 rue_more tahts a good point too
20:36 armyofevilrobots but for a given arch, it either does or doesn't (unless a maintainer for your compiler is being a jerk).
20:36 robotustra_ did you want to get into each next "if" condition after incrementing of ptr?
20:37 armyofevilrobots Oh yeah, good point; may want a switch/case
20:37 robotustra_ and remove the stupid "if(0)"
20:37 robotustra_ or never show me such #$%@ code
20:37 rue_more int eh particaular case here, switch would work
20:37 rue_more but the code problem is different
20:38 robotustra_ explain
20:38 robotustra_ you didn't tell what code SHOULD do
20:38 rue_more well, somehow I'm changing the wrong channels bit, thats one problem
20:39 rue_more the code should take the packet [255] [channel] [msB] [lsB] and make it into channel, position where position is 16 bits
20:40 GargantuaSauce wait didnt you already make the issue explicit?
20:40 GargantuaSauce the shift resulting in 0
20:40 rue_more its not 0
20:40 rue_more I dont thin
20:40 rue_more k
20:40 rue_more maybe it is
20:40 GargantuaSauce is pkt a char*?
20:41 rue_more unsigned char pkt[2]; unsigned char ptr; unsigned int temp; unsigned char data;
20:42 robotustra_ what does USART_Receive() returns?
20:42 GargantuaSauce sooo try it on a real platform where you can debug or just printf
20:42 rue_more oops, I'm melting a servo
20:42 GargantuaSauce what happens with operator<< with operands char and 8
20:43 rue_more robotustra, the character last recieved
20:43 rue_more I changed that bit
20:43 rue_more ptr = 0;
20:43 rue_more temp = pkt[1];
20:43 rue_more temp = (temp<<8);
20:43 rue_more temp = temp | data;
20:43 rue_more if (temp > 24000) temp = 24000;
20:43 rue_more // position[pkt[0] & 0x07] = temp;
20:43 rue_more position[0] = temp;
20:43 robotustra_ why do you use [255] as a "start condition"?
20:43 rue_more but, I have another problem right now
20:43 rue_more its a 'sync' 0xFF
20:44 rue_more it can also be looked at as "go to position" command
20:44 rue_more maybe 0xFE will be a 'sync' for turning servos on and off later
20:44 robotustra_ use this one http://pastebin.com/
20:44 rue_more http://paste.debian.net/93764/
20:44 rue_more :P
20:45 GargantuaSauce why are you not just reading 4 bytes or whatever to a buffer and then accessing it with a struct?
20:46 rue_more there is an id10T error in the two interrupt handlers, the values are going to the port 1 higher than they shoudl be
20:46 rue_more I'm waiting for my brain to kick in
20:46 robotustra_ rue, Why are you not checking "data" first?
20:46 rue_more GargantuaSauce, you dont do that on a microcontroller where ram is limited
20:46 GargantuaSauce that is bullshit
20:46 robotustra_ is your ptr is ==0?
20:47 rue_more I dont need to put 0xFF into a buffer if I dont know ehre the start of the buffer is in the serial data stream
20:47 GargantuaSauce so you'll write 3x as much code to save one byte?
20:47 GargantuaSauce totally saves resources.
20:47 rue_more duh, yea
20:47 GargantuaSauce i think you need to rethink your approach.
20:48 GargantuaSauce either use an explicit state machine (ie one with enumerated named states)
20:48 GargantuaSauce or...well just do that
20:49 GargantuaSauce and if you're going to hand-wring over storing a single byte, don't include it in the struct...
20:50 rue_more if I ask you to write you code suggestion, you gonna submit me soemthing in java?
20:50 GargantuaSauce no, haskell
20:50 rue_more I'm refocused
20:51 armyofevilrobots Hahaha.
20:51 rue_more the position value for channel 0 comes out on channel 1
20:51 rue_more I dont see how
20:51 rue_more the first interrupt will be a mess, thats ok
20:52 rue_more timer2 starts the process, turns on a bit
20:52 rue_more timer1 fires max 2ms later, turns the bit off, sets up the next one
20:54 robotustra_ try this: http://paste.debian.net/93765/
20:55 rue_more well, it clobbers the loop for doing anything else between data bytyes,but
20:56 robotustra_ put delays if you wish
21:04 robotustra_ and?
21:05 robotustra_ rue dissapear
21:06 rue_more no
21:06 rue_more I'm trying to fix the irq
21:06 GargantuaSauce i am not familiar with the avr timers
21:06 GargantuaSauce is there a preload register?
21:07 rue_more but as I can find nothing logically wrong with it, I ahve to assume that somehow there is a temporal inflection in my code
21:07 GargantuaSauce or can writing a new value cause an immediate retriggering
21:07 rue_more it can cause, but I have .5ms avoiding it
21:08 Tom_itx GargantuaSauce, have a look: http://tom-itx.dyndns.org:81/~webpage/abcminiuser/articles/avr_timers_index.php
21:09 GargantuaSauce i'd rather just read the datasheet, not a fan of that sort of exposition
21:09 Tom_itx well dean's pretty sharp on avrs
21:09 Tom_itx and yes you can reset them
21:10 Tom_itx TCNTx = newvalue;
21:10 rue_more yea that fixed it, now [0] is going to [7]
21:11 e_more puts on a blindfold, "time for ninja cod
21:12 robotustra_ if you will spend like a day for such piece of code you will never finish your project
21:13 rue_more wrong way, now it goes to 6
21:13 e_more puts the blindfold back on and mashes the keyboard
21:18 Tom_itx robotustra, that's how rue_more flies
21:18 robotustra_ not professional
21:19 GargantuaSauce lol
21:19 rue_more oh yea, and building robots from photocopiers is
21:21 robotustra_ of cause it is
21:21 robotustra_ real pro does robots from everything
21:24 rue_more too many rules make things not run
21:24 rue_more cant make a living off robots here, so I do it for play
21:28 rue_more (char)1 << 8 == 0, am I crazy?
21:29 GargantuaSauce that is correct
21:29 GargantuaSauce on both counts!
21:34 robotustra_ 8====0
21:40 robotustra_ (0||0)<<8==0
21:45 robotustra_ GargantuaSauce
21:46 robotustra_ so we didn't finish yesterday
21:46 GargantuaSauce that's what she said
21:46 robotustra_ your gurl?
21:46 GargantuaSauce just she.
21:46 robotustra_ :)
21:46 robotustra_ what power do you have?
21:47 GargantuaSauce ten thousand men ready to march
21:48 GargantuaSauce i have 3-cell lipos, 3300mAh
21:48 robotustra_ what weight?
21:49 robotustra_ and what is the weight of your robot?
21:49 GargantuaSauce they're like 400g or something, cant remember
21:49 GargantuaSauce robot is about 3-4kg
21:49 robotustra_ http://www.ebay.com/itm/Digital-LCD-Display-DC-0-60V-0-100A-power-watt-meter-battery-checker-V-A-W-Wh-Ah-/171070595491?pt=LH_DefaultDomain_2&hash=item27d49a21a3
21:50 robotustra_ I bought this power meter
21:50 robotustra_ good thing
21:50 GargantuaSauce i have one that is not dissimilar, no Wh counter though
21:50 robotustra_ to measure power of robot eyes
21:50 GargantuaSauce http://workman-industries.net/images/hexapod/4dof-2.jpg
21:51 robotustra_ 12 watts
21:52 robotustra_ do you use DC-DC step-down there?
21:52 GargantuaSauce yes
21:52 robotustra_ 12-5v?
21:52 GargantuaSauce running at about 7V at the moment
21:52 robotustra_ what efficiency?
21:53 GargantuaSauce haven't measured but i think it's pretty good, probably 80-90
21:53 robotustra_ probably or good? ^)
21:53 robotustra_ what chips are on DC-DC stepdown?
21:54 GargantuaSauce not sure, the controller's top is wiped
21:54 robotustra_ the most efficient DC-DC is about 97%
21:54 GargantuaSauce yeah and they're only there for a tiny range of current
21:54 robotustra_ I use LM7805 now but they are hot as hell
21:55 robotustra_ I'll replace them
21:55 GargantuaSauce heh yeah unsuitable for motor driving
21:55 GargantuaSauce linear regs can go quite unstable with inductive loads too
21:55 GargantuaSauce lose regulation, oscillate, etc
21:55 robotustra_ for my motors they are ok
21:56 GargantuaSauce but yeah, lm2596 modules are super cheap
21:56 robotustra_ my motors are behind TC4424
21:56 robotustra_ so regs are far from them
21:57 robotustra_ they just work close to their limit
21:57 robotustra_ 500 mA
21:57 GargantuaSauce heatsinked?
21:57 robotustra_ no
21:57 GargantuaSauce you can pull well over an A with heatsinking
21:58 robotustra_ hearsink == extra weight
21:58 GargantuaSauce this is true
21:58 robotustra_ extra weight -> extra power
21:58 GargantuaSauce yeah get a switcher module, they are too cheap not to have a bunch kicking around!
21:58 robotustra_ and so on
21:58 robotustra_ I bought 10, just in case
22:00 robotustra_ everything should be warm, not hot
22:00 robotustra_ and hydroisolated
22:00 rue_more icecream, check
22:00 robotustra_ you scream
22:03 robotustra_ MrSerious
22:04 MrCurious https://www.youtube.com/watch?v=9A8kq85Umco
22:04 robotustra_ I hope I will not go out of 40W for all the robot head
22:04 MrCurious best political comercial EVER
22:04 GargantuaSauce i sure hope not too :|
22:04 MrCurious sounds like it will be dim and not have a powerful brain
22:05 robotustra_ I bet your brain consume less :)
22:06 robotustra_ human body emit about 100W from the surface
22:06 robotustra_ normally
22:07 robotustra_ 40W for brain and 150W for the rest of the body
22:07 robotustra_ 200W is the upper limit
22:07 e_more sends robotustra back to math sc
22:08 robotustra_ rue_more: keep silence and I'll not send you to programmer's school
22:09 robotustra_ rue_more: I'm physicist, and I always do "approximate" calculations
22:09 robotustra_ 150W + 40W ~ 200W
22:09 rue_more http://paste.debian.net/93775/
22:09 rue_more thoguhts
22:10 rue_more robotustra, 1+1=3 for large values of 1?
22:11 robotustra_ idx--;
22:11 robotustra_ or even --idx;
22:11 rue_more dosn't change it
22:11 robotustra_ is ir volatile?
22:12 robotustra_ is it
22:12 rue_more yes
22:12 robotustra_ so what's your problem?
22:12 rue_more idx is never 0
22:12 robotustra_ because you stop the timer
22:13 rue_more timer2 starts the cycle
22:13 rue_more the value for timer 1 should already be loaded from last cycle
22:13 rue_more timer 1 ends it
22:13 robotustra_ it will never be 0
22:14 rue_more then a half ms rest, then timer2 starts it again
22:14 rue_more it should be 0 for one cycle thru the process
22:14 robotustra_ you should uncomment upper string
22:14 robotustra_ and comment below
22:14 rue_more if it goes into timer 1 isr with 1, it should load 0
22:14 MrCurious whats the lower limit
22:14 rue_more that makes it WORSE
22:14 rue_more then it never hits 1
22:14 Curious swivels his hip
22:16 robotustra_ I don't beleive you
22:16 rue_more I cant understand why either
22:17 rue_more making the problem worse is being easy
22:18 robotustra_ what is the frequency of time 1
22:18 robotustra_ and timer 2
22:18 rue_more timer 2 is 2.5ms regular
22:19 rue_more timer 1 goes from .5ms to 2ms
22:19 robotustra_ and why do you use 2 interrupts where you need only 1 interrupt?
22:20 rue_more I think its legacy from the last method I was using
22:20 robotustra_ so, you should increment idx in the timer2 routing
22:20 rue_more ah, it makes it easy to make the pulses for a single channel happen 20ms apart nomatter what the timing of any 1 channels pulse is
22:21 robotustra_ there is no logic in your code
22:21 robotustra_ one timer shoud do the DURATION of the pulse
22:22 rue_more timer 1 does that
22:22 robotustra_ ok and it does
22:22 robotustra_ ok
22:22 rue_more and timer 2 ensures that the pulse repetition rate is 20ms (2.5ms*8)
22:22 rue_more and timer 2 ensures that the pulse repetition rate is 20ms (2.5ms*8 channels)
22:22 robotustra_ but then you have to remove index incrementing from it
22:23 robotustra_ index increment should be in the timer2
22:23 robotustra_ before you set the bit
22:24 rue_more ok eat this, this code has the same problem, it writes position[0] to port bit 1, not 0...
22:24 rue_more http://paste.debian.net/93778/
22:24 robotustra_ how do you check?
22:25 rue_more the servo on bit 1, not bit 0 moves to the new position
22:25 rue_more (in main: position[0] = 6000;)
22:27 rue_more I think your as stumped as I am
22:28 robotustra_ thank you
22:28 robotustra_ I can give you a knife to stuck it in my back
22:29 rue_more its like setbit isnt' working right
22:29 rue_more I'v never used it with a variable before
22:29 robotustra_ don't use macro if you are not sure
22:30 robotustra_ put the C expression in the code
22:31 rue_more well lets try it...
22:33 rue_more hahahaha
22:33 rue_more still broken....
22:33 rue_more http://paste.debian.net/93779/
22:33 rue_more I'm gonna look at the assembler listing
22:34 rue_more this has to be a compilerism
22:36 GargantuaSauce full pastebin?
22:36 rue_more foo = 0x01 << idx;
22:36 rue_more c4: 20 91 70 00 lds r18, 0x0070
22:36 rue_more c8: 81 e0 ldi r24, 0x01 ; 1
22:36 rue_more ca: 90 e0 ldi r25, 0x00 ; 0
22:36 rue_more cc: 01 c0 rjmp .+2 ; 0xd0 <__vector_4+0x54>
22:36 rue_more ce: 88 0f add r24, r24
22:36 rue_more d0: 2a 95 dec r18
22:36 rue_more d2: ea f7 brpl .-6
22:37 rue_more ...
22:37 rue_more wtf
22:37 GargantuaSauce avr's shift instruction does not have an operand
22:37 GargantuaSauce so << makes a lop
22:37 rue_more 0070 is the idx location
22:37 GargantuaSauce paste the whole thing
22:37 rue_more yea, but there IS NO ROL INSTRUCTION IN THAT
22:38 GargantuaSauce all the c i mean
22:38 rue_more http://paste.debian.net/93780/
22:39 rue_more http://paste.debian.net/93781/
22:40 rue_more oh by adding it to itself, its a *2
22:41 rue_more but if
22:41 rue_more it goes into this assember code with 0
22:41 Tom_itx rue_more, you've been spending more time playing lately
22:41 rue_more spring
22:42 Tom_itx full moon too
22:42 GargantuaSauce lunar eclipse!
22:43 GargantuaSauce should be visible by now
22:43 GargantuaSauce time for a stroll
22:43 rue_more brpl branch ...
22:44 Tom_itx visible where?
22:44 GargantuaSauce in the sky
22:44 Tom_itx i don't see no stinkin eclipse
22:44 rue_more branch if plus
22:44 Tom_itx carry if minus
22:44 GargantuaSauce oh guess there's another 90 mins till it starts
22:44 Tom_itx hell, i'll be asleep by then
22:45 GargantuaSauce i should be also but probably won't
22:45 GargantuaSauce peaks at like 5 am here which sucks
22:46 Tom_itx GMT +- ?
22:46 GargantuaSauce -4
22:46 rue_more idea
22:46 e_more comments out i
22:46 rue_more now its only ever 0
22:46 GargantuaSauce no
22:46 GargantuaSauce now it's only ever 7
22:47 rue_more I changed the init in main
22:47 rue_more it worked
22:51 rue_more foo = position[idx];
22:51 rue_more OCR1A = foo + 8000;
22:51 rue_more this change just broke it all
22:53 GargantuaSauce is foo still a char?
22:53 rue_more unsigned int
22:55 GargantuaSauce seems to me writing to a 16 bit register is a bit wonky
22:56 GargantuaSauce especially in an interrupt
22:57 GargantuaSauce i'd start by making position and foo shorts
22:57 GargantuaSauce and maybe try writing to the high and low bytes manually? i dunno
22:58 GargantuaSauce nevermind cant do that
23:02 rue_more its reading the position fine
23:03 rue_more its setting and clearning the wrong bit in relation
23:03 rue_more hmm
23:03 rue_more position isn't volatile
23:04 rue_more but it shouldn't need to be, its only read by the interrupt
23:04 GargantuaSauce shouldn't need to be since you aren't writing it yeah
23:05 rue_more erp, ok goofed a change
23:06 rue_more position[0] still being written to bit 1
23:06 rue_more still.
23:08 rue_more ooomgod
23:09 rue_more I dont think timer1 loads the ocr1a register till its next cycle
23:09 rue_more whcih is why the error didn't move when I cahnged from inc idx to dec idx
23:10 GargantuaSauce didn't i mention that hours ago
23:10 rue_more when you said you dont know how the timer works?
23:11 rue_more mode mode mode ...
23:11 GargantuaSauce yeah guess it preloads when it's in "fast pwm mode"?
23:12 GargantuaSauce they call it double buffering in the doc
23:12 GargantuaSauce womp womp.
23:12 GargantuaSauce you didn't entertain my question so i assumed i was wrong
23:12 rue_more "Update of 0CR1x = TOP"
23:13 rue_more not immediate
23:13 rue_more ugh
23:13 GargantuaSauce timers are weird
23:13 rue_more I think I want mode 4, not 15
23:15 rue_more 0hahahahahahhahahahahahahahaha
23:15 rue_more hashahahahahahaha
23:15 rue_more hahahaha
23:15 e_more falls dead on the f
23:16 rue_more GargantuaSauce, thankyou for you help
23:17 rue_more now to see if the packet reassembler code works
23:18 GargantuaSauce in every architecture i've looked at they're super complicated
23:18 GargantuaSauce feels like they could be a lot simpler
23:18 GargantuaSauce without sacrificing functionality
23:18 GargantuaSauce one more reason to start dicking with fpgas and define your own functionality entirely i guess
23:18 rgantuaSauce stares at his lonely dev bo
23:18 rue_more whats 6000 in hex?
23:18 GargantuaSauce i don't see anything wrong with it other than the fact that it's dumb
23:18 GargantuaSauce i'm assuming your usart rx function blocks until a byte comes in
23:18 GargantuaSauce google
23:19 rue_more 1770
23:21 rue_more its working
23:22 GargantuaSauce https://www.youtube.com/watch?v=AXwGVXD7qEQ
23:26 rue_more ok next problem
23:26 rgantuaSauce runs
23:26 rue_more linux cant *finish* a blocking write to a usb serial port
23:27 GargantuaSauce hahah have fun
23:27 rue_more I remember this problem, I dont know if I ever solved it
23:28 GargantuaSauce i've had similar issues
23:28 GargantuaSauce i dealt with it by switching to a different machine with a different usb chipset.
23:33 rue_more I know there are different issues with different usb to serial drivers
23:33 rue_more pl2303 converter now attached to ttyUSB0
23:37 GargantuaSauce i need to start messing with usb properly
23:38 GargantuaSauce i think exposing device functions as usb endpoints would make for much simpler end-to-end operation
23:38 GargantuaSauce ie not having to worry about some dumb serial protocol
23:41 rue_more I cant remmeber which of all these flags makes it do blocking write in the first place
23:45 GargantuaSauce i think write() is blocking by default
23:45 rue_more ugh, I hate usb
23:52 GargantuaSauce it is kinda gross but eh
23:54 rue_more I went to lots of work to make this code block
23:54 GargantuaSauce okay time to go see if the moon is getting shadowed at all yet
23:56 rue_more do {
23:56 rue_more ioctl(this->fd, TIOCSERGETLSR, &lsr);
23:56 rue_more } while (!(lsr & TIOCSER_TEMT)); // transmitter empty
23:56 rue_more this is the code its hanging on
23:57 rue_more GargantuaSauce, your using serial comms with your robot yes?
23:58 GargantuaSauce https://bitbucket.org/Ultrasauce/robots/src/149d2b91944ae2d4f30394af04199c36192eed71/pc/sim_old/IKWalker.cpp?at=master
23:58 GargantuaSauce lines 93-107, 257
23:59 GargantuaSauce it's overcast :(
23:59 rue_more is how you make sure not to flood the micro?
23:59 GargantuaSauce no flow control
23:59 rue_more what if the computer starts buffering up your commands?
23:59 GargantuaSauce line 224 was how i limited the rate