#robotics | Logs for 2016-09-17

Back
[07:00:12] <robopal> myrobots.com is working for you?
[07:01:06] <theBear> loooks like name isn't being server to me
[07:01:10] <robopal> I get "non-existent domain"
[07:02:56] <theBear> try http://pastebin.com/8Vi1fKnN
[07:04:43] <theBear> hmmm
[07:04:55] <theBear> i suspect dnsmadeeasy.com is bodged
[07:05:18] <theBear> which is the company/servers responsible for attaching a sensible number/webserver to myrobots.com
[11:55:03] <rue_house> CLICK I know why a 36V 2A motor blew a 50A 600V IGBT
[11:55:11] <rue_house> I didn't put the flyback diode in the right place
[11:55:13] <rue_house> hahaha
[12:19:06] <rue_shop3> no more hunting down and cutting up little peices of pipe for spacing circuit baords for me, I'm aparently just printing them now
[12:27:02] <SpeedEvil> yay
[12:34:53] <mrdata> printing little pieces of pipe?
[13:24:42] <rue_house> yea
[13:24:51] <rue_house> gonna build a library
[13:24:59] <rue_house> 4-40 M3 6-32 M4
[13:32:52] <robopal> for the screws?
[13:33:50] <robopal> "no for me, you imbecile!" "screws can't read!"
[14:47:00] <z64555> ugh, I wish I knew where my controls book ran off to
[14:48:15] <SpeedEvil> The circus?
[14:48:32] <z64555> nah, probably the college bookstore
[14:48:38] <z64555> I can't remember if I sold it or not
[15:03:30] <rue_house> I'm sure its hurt by you not remembering
[15:57:01] <anonnumberanon> I've been thinking of making a 1 microsecond delay function by calling NOP in assembly 16 times.
[15:57:54] <anonnumberanon> Each takes one instruction cycle and each cycle is ~62.5 nanoseconds...
[15:57:57] <anonnumberanon> Thoughts.
[15:58:02] <anonnumberanon> ?
[16:01:06] <theBear> anonnumberanon, fine assuming nothing messes with it or it ain't critical (nothing may include interrupts or err, pfft, i dunno, something else :] )
[16:01:37] <anonnumberanon> yeah interrupts would hurt it
[16:01:43] <anonnumberanon> ofc
[16:01:52] <theBear> oh, and people that know about that kinda thing might say it's very poor with power usage/wastage, but i got no idea without some paperwork and mathamagickery
[16:02:08] <anonnumberanon> this done in a synchronized manner, only once every 20 milliseconds
[16:02:25] <theBear> ooh, also need a few unusual choices or some trickery to make it not get compiled/optimized outy
[16:03:07] <theBear> synchronized with it's own program or something like a timer or external thing
[16:03:09] <theBear> ?
[16:03:31] <anonnumberanon> Currently I synchronize my timing with micros().
[16:03:41] <anonnumberanon> Still working on something better than it.
[16:04:19] <anonnumberanon> Using timer interrupts. sigh, that makes it hard to use other things that use the timer facility.
[16:04:47] <anonnumberanon> spi or i2c for a RF module for communication
[16:04:56] <anonnumberanon> I can't recall if it uses spi or i2c.
[16:06:24] <anonnumberanon> The way I had it one day when I was doing timer interrupt things to get a 1 microsecond clock would give me a resolution of about 2 microseconds, which was not optimal.
[16:06:50] <anonnumberanon> I will try to get back into it but it's very autistic work :)
[16:07:55] <anonnumberanon> Nothing against autism of course, I probably have it.
[16:08:40] <z64555> anonnumberanon: y u no use timer
[16:09:08] * z64555 reads further down
[16:09:14] <anonnumberanon> :)
[16:09:21] <anonnumberanon> "<anonnumberanon> The way I had it one day when I was doing timer interrupt things to get a 1 microsecond clock would give me a resolution of about 2 microseconds, which was not optimal."
[16:10:07] <z64555> can you use interrupts on the comms module to get the correct synch?
[16:10:19] <z64555> instead of waiting an arbitrary amount of time
[16:10:27] <anonnumberanon> yes I'd like to try and do something like that z64555
[16:11:07] <z64555> bah, I need to clean my glasses
[16:11:31] <theBear> you can always count something external on a regular input pin, or maybe have a discrete external osc/delay that hits an interrupt-trigger pin, tho that starts to feel like stupid next to a micro with multiple internal timers
[16:11:41] <theBear> what you need 2 or 3 other timers for anwyay ?
[16:13:34] <anonnumberanon> what do you mean theBear ?
[16:14:00] <anonnumberanon> I just need to be careful about overlapping interrupt service routines.
[16:15:13] <theBear> are they all doing completely unrelated things ?
[16:15:38] <theBear> and re timers question, i mean, if you ain't able to spare one, they must already be doing something important
[16:16:37] <anonnumberanon> http://forum.arduino.cc/index.php?topic=92111.0
[16:16:58] <anonnumberanon> all i need then i guess is SPI and one of the timers for timing my loop
[16:17:11] <anonnumberanon> trying to find out whether or not spi uses a timer and if so which one
[16:17:40] <anonnumberanon> I should probably be looking in avrfreaks instead of arduino forums but that's what google returns.
[16:18:57] <theBear> wtf ? i can't comprehend that retard nonsense ! i hope you didn't write that
[16:19:58] <theBear> also the only remotely likely sounding actual-issues involved conceptually involved stupid things only done by stupiduino libraries, as usual, mostly cos of how they abstract things excessively even if not needed, and keep the details either way far from the user
[16:20:17] <anonnumberanon> i also can't read that thread for anything useful
[16:20:23] <anonnumberanon> nah I didn't start it
[16:21:13] <anonnumberanon> let's read the SPI bit of the atmega328 datashit
[16:21:55] <theBear> memory tells me spi steals the uart in avr (assuming hw-assisted/non-softbanged)
[16:22:18] <z64555> yup. that's how its done on motorola chips
[16:22:26] <theBear> tho i suppose a soft/bangey spi lib obscured by stupidness could well expect to have a timer all to itself
[16:22:32] * z64555 tries to read the article
[16:22:37] <anonnumberanon> I've been thinking of rewriting the RF24 library that arduino people use, just C and give it a powerful API.
[16:23:58] <theBear> not much api is usually needed for single-purpose libs like that i found traditionally, it's when they get all sneaky and try to abstract stuff excessively and juggle ports and pins for no apparent reason (at great cost to code size, at least unless you really sneaky about things) that it appears that way :)
[16:24:40] <theBear> also most everything already has a handful of sensible avr-gcc written/working libs from the decade or so we had avrs before duinos came and got me down
[16:25:53] <anonnumberanon> I brought back my oscilloscope from storage and a atmega328 on breadboards. I can actually do work again.
[16:26:52] <theBear> huzzah !
[16:30:31] <anonnumberanon> p215 http://www.atmel.com/Images/Atmel-42735-8-bit-AVR-Microcontroller-ATmega328-328P_datasheet.pdf
[16:30:37] <anonnumberanon> SPI
[16:34:02] <anonnumberanon> huh read up to 225 and it doesn't mention any timers, just an SPI interrupt pin which should, not be related to any timers?
[16:34:20] <anonnumberanon> z64555, how is your quad coming along?
[16:34:42] <anonnumberanon> did you get the mains power supply to bench test it without a battery?
[16:38:24] <theBear> 21.8.4 UCSRnC – USART MSPIM Control and Status Register n C p204 in my 650page version of mega4x/8x/168?/328? (register tables/defs section, uart region for other datasheets) pretty much sums it up in my eyes, which don't feel like making 100% sure that DOES sum it up completely
[16:42:20] <anonnumberanon> I guess what I could do is whenever I'm in the non-critical part of my loop, I send an request from the receiving end to the sending end and tell it to send a packet. Then the sender sends only one packet and that's the only time it is allowed to transmit.
[16:43:26] <anonnumberanon> And by packet I mean however packets I need to send in order to communicate 17 servo positions. So like many many packets :)
[16:44:08] <anonnumberanon> s/however/however many
[16:44:29] <anonnumberanon> 9 bits per servo times 17
[16:44:45] <theBear> mmm, yer'd probly call that requested-polling or something along those lines, and not only has rue implemented it at least once for personal use in the last few years, but , wait, i think you saying it backwards
[16:44:59] <anonnumberanon> so 153 bits or 20 bytes
[16:45:04] <theBear> i spose knowing ANY details like which end the loop runs on would help me be sure
[16:45:37] <anonnumberanon> theBear, I'll just draw it, can't really explain in words
[16:45:46] <anonnumberanon> quick, a drawpad online?
[16:45:47] <theBear> oh, i see, loop is servo driving loop at servo-driver board/micro
[16:46:13] <theBear> but, err, there is only one sender ?
[16:46:24] <theBear> i just talking broad strokes here, not too detailed
[16:47:34] <anonnumberanon> yeah one sender which is the "remote controller" of the board, so one RF module on the controller, one RF module on the servo driver board
[16:49:00] <theBear> you doing spi over one of those 410mhz modules ?
[16:49:16] <theBear> the dumb ones i mean]
[17:03:08] <anonnumberanon> me?
[17:03:14] <anonnumberanon> 2.4Ghz modules
[17:07:56] <anonnumberanon> https://imgur.com/a/3hXtK
[17:08:14] <anonnumberanon> here theBear this is what the loop looks like
[17:11:31] * anonnumberanon jumpstarts theBear
[17:13:18] <anonnumberanon> "The SPI module has its own baud rate generator so it does not consume any of the timers."
[17:13:20] <anonnumberanon> good
[17:13:26] <anonnumberanon> https://electronics.stackexchange.com/questions/90778/does-arduino-spi-use-up-a-timer
[17:25:51] <z64555> no, I haven't gotten a power supply for it yet. was considering using a PC power supply since it's got a 12V rail
[17:28:22] <z64555> I've been looking over the code, tweaking things here and there to get it to fully compile. Eigen has a few static asserts that arn't exactly helpful
[17:31:54] <theBear> anonnumberanon, hmmmmmmmm..... i really wanna say you should be using a timer, but unlike most basic/non-many-servo libs, you wanna do a compare timer vs desired angle -> output pin, for each servo you wanna drive, get the timer prescaled and overflow/limit/whatever-fine-tuned just right for your servos max rotation (or a bit less for safety maybe) and bing bang bong, let it run.... means there is nearly zero time/thinking involved in converting
[17:31:54] <theBear> desired angle to something that actually makes a servo move, plus it /n-servos as far as efficiency of that part of the code goes, plus it doesn't change timing or anything much except a single compare if you add/remove a servo(s), and it gives you the HARD timer (and if you want int, but not essential if you careful at the time between min and max servo pulse) which you really really want to avoid jitter
[17:32:59] <theBear> also if long dusty memory serves ok today, you got a fair bit of leeway in the not-active-part-of-servo-drive-cycle if you want a little more time between runs
[17:33:44] <theBear> i wonder, might make more sense to reset the overflow/whatever-restart-mech on a single timer twice each loop, once for the big gap, and once for the bit it wants to accurately compare and flip servo output bits
[17:34:26] <theBear> 2.4ghz eh ? they specifically say they ok with (or specifically for) spi ?
[17:34:54] <theBear> 'cos a quick think tells me the dumb modules wouldn't do a great job getting it across the rf
[17:35:54] <theBear> sidenote: dumb/410ishMHz "serial modules" are pretty much just a dumb hi/lo from tx to rx, and handle NOTHING else, and have no idea if that hi/lo is messed up or not, outside of a simple squelch kinda approach
[17:36:07] <z64555> in the GHz range, everything is an antenna...
[17:39:50] <z64555> I don't remember if RF chips like that do AM or FM
[17:44:31] <anonnumberanon> theBear, what I do in my code iirc is first, to make the microsecond clock i use timer overflow interrupt and :3 reset the timer to 250 (out of 255). That operation refreshes a clock all of the time and thus lets me do tellTimeNow(). I poll that function until it returns a time exactly 20 ms after the last loop. I then turn onall pwm pins at the same time, and use that same function to stop the PWMs whenever their period is over.
[17:44:32] <anonnumberanon> After this is completed, I'm left with 17 ms to do whatever I want. This was working perfectly (albeit with non-optimal resolution but I have quite a few fixes for that issue) until I added the RF module communication.
[17:46:21] <anonnumberanon> This lib seems quite usable. https://github.com/kehribar/nrf24L01_plus
[17:46:36] <theBear> mmmmm, you saying your timer int's every ms ? cos instantly i wanna say that is 19 ints too many
[17:48:54] <z64555> this sounds more complex than it needs to be
[17:49:06] <z64555> anonnumberanon: what chip are you using, specifically?
[17:52:03] <anonnumberanon> theBear, I set up the timer to overflow every microsecond and fire an ISR which updates a time counter. The closes I got to a pure one microsecond function was about 2 microseconds. The ISR resets the timer's byte count to 250 or something like that, so it only counts to 5 and then immediately overflows again.
[17:52:22] <theBear> the umm, why you need to know "time"
[17:52:25] <anonnumberanon> z64555, using atmega328p and NRF24L01+
[17:52:42] <z64555> ok. Also, your control loop can be slower than your PWM. just so you know.
[17:52:42] <theBear> wait, nrf24 is wifi innit ?
[17:52:53] <anonnumberanon> theBear, it's like bluetooth
[17:52:59] * theBear sees little if any need for pwm to be involved at all
[17:53:01] <anonnumberanon> it don't have a wifi stack and all
[17:53:41] <theBear> anonnumberanon, err, umm, hmmmmmmm.... it's err, fits into wifi specs, or err, could have a stack jammed up it and do wifi ?
[17:54:40] <z64555> also 2.4GHz is the carrier frequency, not the data bandwidth
[17:55:10] <anonnumberanon> theBear, it just can't do wifi. I think the chip is too limited for that. I don't know the details. When I looked into it I made absolutely sure it couldn't do wifi and took it at face value without caring about the details.
[17:55:51] <anonnumberanon> <z64555> ok. Also, your control loop can be slower than your PWM. just so you know.
[17:55:54] <anonnumberanon> explain pls
[17:57:04] <anonnumberanon> z64555, the RF module does a few megabits per second
[17:58:09] <z64555> the PWM is just needed to transmit data to the servos. The control loop that adjusts the width of the PWM pulses can be slower.
[17:58:40] <z64555> and doesn't have to be even the same frequency or a harmonic of it
[17:59:16] <z64555> You won't get a 1:1 transmission rate through the PWM signal that way
[17:59:48] <z64555> but, you usually don't need it, especially for servos which are usually slow in response
[17:59:51] <anonnumberanon> z64555, that would be true for like 4 PWMs out of the micro, because I need to make 17 of them I use 17 gpio pins and bitbang it, which requires my own timing and I can't use the micro's PWM facilities.
[18:00:56] <anonnumberanon> theBear> the umm, why you need to know "time"
[18:01:09] <anonnumberanon> because that's the only way to time the PWMs
[18:01:11] <z64555> oh boy. you're bit-banging PWM
[18:01:19] <anonnumberanon> :3
[18:01:44] <z64555> make your life easier and get more micros
[18:01:45] <anonnumberanon> pretty much having rough sex with the microcontroller in other words, and it likes it :)
[18:01:56] <z64555> or a different micro that can handle all of the servos at once
[18:04:53] <theBear> mmmmmmmmm interesting, musta not looked closely at him before (eff knows what p/n i WAS thinkin bout) .... very interesting
[18:06:25] <anonnumberanon> theBear, all you need to know: $1 and it's a great way to do RF comm between micros
[18:06:35] <anonnumberanon> brb
[18:07:02] <theBear> so erm, umm, it is programmable to some extent, AND has default or hw maybe serial support, at least from a external pov ? is the modulation hard and fixed or if not, what kinda flexibility is in there, or what does it use and let you fiddle to some extent greater than not-at-all ?
[18:07:03] <z64555> NRF24L01+ is 250Kbaud to 2Mbaud in transmission rates
[18:07:16] <z64555> (baud = bits per second)
[18:07:21] <theBear> anonnumberanon, heh, you know me better than that, i need to know a ton more even if i never plan to use one :)
[18:08:57] <z64555> pretty sure you just treat the RF chip as a UART module. shove bits in to transmit, listen for an IRQ signal and process recieved bits in an ISR
[18:15:13] <anonnumberanon> theBear, fuck, okay let me make you an intro to it
[18:15:33] <anonnumberanon> datasheet and a video on some interesting tests
[18:16:17] <z64555> anonnumberanon: seriously though, get another micro or 4
[18:16:21] <anonnumberanon> theBear, first page covers it's most interesting uses: https://www.sparkfun.com/datasheets/Components/SMD/nRF24L01Pluss_Preliminary_Product_Specification_v1_0.pdf
[18:17:50] <anonnumberanon> theBear, and video: https://www.youtube.com/watch?v=lR60toEjHl8
[18:20:59] <DJuego> Bye!
[18:21:23] <theBear> toodle-oo
[18:23:20] <anonnumberanon> z64555, that would become very expensive in parts
[18:23:30] <anonnumberanon> I'm trying to do more with less.
[18:23:49] <z64555> no, you're trying to overburden the pack mule. :P
[18:24:10] <z64555> you can use something like an ATTiny for the PWM/servo drivers
[18:24:40] <z64555> program them to accept like an I2C signal train that has the %duty for each of the outputs
[18:25:16] <anonnumberanon> I'd need 9 attinies :)
[18:26:17] <z64555> there are larger tinies than the 6-pins
[18:37:36] <z64555> ATtiny25's might do the trick
[18:39:14] <z64555> power, ground, SCL, SDL, and 4 PWM's to play with
[18:39:19] <z64555> 8 pins
[18:41:25] <z64555> about 2 USD's each.
[18:43:16] <z64555> and about 0.25 to 0.75 USD's for each 1"x1" square PCB's to solder them onto. not exactly breaking the budget here :)
[18:45:13] <z64555> anonnumberanon: so you could like have 4 ATtiny's to get 16 PWM channels out of them, and use one of the PWM's off the atmega328p for the last servo
[18:51:15] * z64555 is somewhat amazed at how much he knows about microcontrollers
[18:53:27] <rue_house> or just use the software RUE already wrote
[18:54:06] <rue_house> rues m328 code runs 8 servos,
[18:54:23] <rue_house> and you can stack 8 of them on the same asynchronous bus
[18:54:36] <rue_house> with 1 wire
[18:54:52] <rue_house> 8 or 4... damn, cant remember
[18:55:18] <rue_house> high resolution, super stable signals
[18:55:43] <rue_house> arg, I need to do a lot of driving and I dont want to
[18:56:50] <z64555> eh, there's gotta be some kinda catch
[18:57:26] <z64555> you can't run multiple stock servos on a single line and expect different control angles on them
[18:58:51] <z64555> I can see an underactuated scheme where the servo's are modified to have an input signal and an output signal
[18:59:28] <z64555> and the output signal is scaled down by some factor, or otherwise has a transfer function on the input signal
[19:02:54] <rue_house> serial 9600 baud
[19:03:22] <rue_house> I wrote the software, I use it on my robot arms
[19:04:02] <rue_house> https://www.youtube.com/watch?v=j4uz_yha9uI
[19:05:44] <rue_house> 24000 counts from 0 to 300 degrees
[19:21:19] <rue_house> its amazing that I'v written one peice of code that to date, nobody can comprehend
[19:21:28] <z64555> oh, I misunderstood, I thought you meant stacking servos on the same line
[19:22:17] <z64555> rue_house: which code?
[19:22:34] <rue_house> my 8 servo controller code
[19:23:04] <z64555> may I have a look?
[19:24:04] <rue_house> http://ruemohr.org/~ircjunk/robots/arm9/hobbydriver.tgz
[19:25:20] <z64555> ty
[19:26:09] <rue_house> I really dont want to do an hour of driving
[19:28:12] <z64555> your compiler didn't support binary literals?
[19:28:28] <rue_house> not back when I started using it
[19:28:32] <rue_house> it might now
[19:28:32] <z64555> IIRC the 'b' postfix is all you need. for example, 1001b
[19:29:04] <z64555> timestamps say 2014
[19:29:17] <rue_house> back in the day I had an argument with the gcc people about binary and they told me that binary was obsolete and did not need to be used in C
[19:29:50] <rue_house> I started writing c a lot longer ago than that
[19:30:30] <z64555> "binary was obsolete" bull fucking shit
[19:30:42] <rue_house> I could not convince them
[19:31:05] <rue_house> anyhow, gcc did not support binary numbers
[19:31:39] <z64555> ugh.
[19:33:29] <anonnumberanon> Yeah I understand your main.c rue_house .
[19:33:48] <anonnumberanon> I've written something like this to build a microseconds clock function.
[19:34:19] <rue_house> wow, I cant find the source for the program I used to write binary.h
[19:34:20] <anonnumberanon> using two timers...huh..
[19:34:36] <rue_house> that file must be REALLY old
[19:36:02] <rue_house> aha 2009
[19:36:26] <z64555> looks fine to me, uses a state machine in a loop to parse incoming data from the usart
[19:37:28] <rue_house> yup, really good high rez timing for 8 servos
[19:37:54] <rue_house> it could be dialed up to 10, carefully, as you have to watch your instruction delays
[19:39:32] <rue_house> ah, gcc now also excepts 0bxxxxxxxx
[19:40:53] * rue_house is falling asleep
[19:41:04] <rue_house> this is not the 1 hour drive to go get bricks I need to be doing
[19:41:14] <z64555> not sure why you copied the lower byte into the higher byte
[19:42:49] <rue_house> its a compressed set of bytes
[19:43:02] <rue_house> fer 16 bit
[19:43:16] <rue_house> position can be from 0 to 31000
[19:43:23] <rue_house> I thought it was 24000
[19:43:31] <rue_house> remmebered wrong
[19:44:25] <anonnumberanon> I believe I have a binary maker if you want it rue_house.
[19:44:45] <rue_house> dont need it, I just wanted to find out when I made binary.h
[19:45:01] <z64555> oh now I see it
[19:45:04] <rue_house> suggestion shows it to be 2009
[20:03:14] <anonnumberanon> void printbinary(unsigned x, unsigned count){
[20:03:14] <anonnumberanon> printf("decimal is: %d\n",x);
[20:03:14] <anonnumberanon> printf("binary is: ");
[20:03:14] <anonnumberanon>
[20:03:15] <anonnumberanon> while (0 < count){
[20:03:16] <anonnumberanon> putchar(((x >> (count - 1u)) & 1u) + '0');
[20:03:17] <anonnumberanon> count--;
[20:03:20] <anonnumberanon> }
[20:03:22] <anonnumberanon> putchar('\n');
[20:03:24] <anonnumberanon> }
[20:05:44] <z64555> except that's not it
[20:05:59] <anonnumberanon> Prove it.
[20:06:56] <z64555> as your counter increments, the value, x, is shifted to the right
[20:07:44] <z64555> example; x = 0b1011; output would be 1101
[20:08:02] <z64555> since it's grabbing the LSB and printing it
[20:08:21] <z64555> but when it's printing, it goes left to right.
[20:08:34] <z64555> and when it's reading, it's effectively going right to left
[20:09:00] <anonnumberanon> https://ideone.com/siweAU
[20:09:26] <anonnumberanon> wait there is something I did not see here
[20:10:19] <z64555> get the MSB and then left shift it. easiest way.
[20:10:31] <anonnumberanon> What is your 0b notation now?
[20:10:48] <anonnumberanon> 0bxxxxxxxx
[20:11:44] <anonnumberanon> you can only put an int in my function
[20:11:55] <anonnumberanon> you can't input something like 0bxxxxxxxx
[20:12:36] <z64555> go with 0x0B, then
[20:12:46] <z64555> hex and octal are supported
[20:18:27] <anonnumberanon> https://ideone.com/i6btGY
[20:18:40] <anonnumberanon> this makes rue_house 's .h file
[20:19:02] <anonnumberanon> allright time to go experimenting
[20:20:51] <z64555> hm
[20:20:56] * z64555 rereads the code
[20:23:14] <z64555> huh.
[20:23:34] <z64555> I was thinking it operated on it directly, as with >>=
[20:23:52] <z64555> how inefficient
[20:23:55] <z64555> but it works
[20:31:48] <anonnumberanon> z64555, why inefficient?
[20:32:13] <z64555> well, chips I know take a clock cycle per bit shift
[20:32:34] <z64555> so an x << 8 would consume 8 cycles
[20:36:53] <z64555> seems to be specific to the chip archetecture. x86 machines, for example, do logical shifts in one clock
[21:01:45] <anonnumberanon> Sweet, ROBO-ONE 29 starts in 8 days
[22:12:16] <rue_house> I use bxxx because gcc did not support binary, and you cant start a constant with a number
[22:28:44] <z64555> logical.