#robotics Logs
Feb 18 2019
#robotics Calendar
01:03 AM rue_mohr: have you done hardware before?
02:28 AM veverak: rue_mohr: pca9685
04:10 AM amenji: i have a question about particle filter localization: when should we do the resampling? do you start out at timestep=1 where the map is barely mapped?
04:10 AM amenji: or should we wait until majority of the map is known (mapped), then we can start particle filter localization
10:58 AM rue_bed: dunno--
10:58 AM veverak: fu me
10:58 AM veverak: stm32 does not like me
10:58 AM veverak: I mean, what thell
10:58 AM veverak: after I write something to i2c in setup phase, UART stops working
10:58 AM veverak: :/
10:58 AM veverak: so, I have blocking uart read
10:58 AM veverak: than cycle of interrupt based uart reads / i2c writes
10:58 AM veverak: when I add blocking/interrupt based i2c com at the setup phase, the 'interrupt based uard read' stops working
10:58 AM veverak: wtf
10:58 AM veverak: HAL why you suck so bad
11:01 AM rue_bed: why are you using a hal
11:01 AM rue_bed: thats prolly more code overhead
11:01 AM rue_bed: and like you say, hardware conflict
11:02 AM rue_bed: write it direct, what you trying to do
11:02 AM rue_bed: I should look at the i2c system ... no, wait I did
11:03 AM rue_bed: after looking at the i2c on stm32, I ported flurrys bit-banged library from avr, cause its faster and takes less overhead memory and cycle wise
11:03 AM rue_bed: I'll share if you want
11:06 AM rue_bed: funny tho, I remember bit-banged is WAY better for attiny, which requires you to run an instruction to send every bit anyhow, but I cant remember the details for the stm32
11:06 AM rue_bed: and why I ported it
11:09 AM rue_bed: everyone is dead rue
11:10 AM rue_bed: I know, I just....
11:10 AM rue_bed: you need to leave the planet rue
11:10 AM rue_bed: but its so nice and warm
11:13 AM veverak: nobody got time for that
11:13 AM veverak: expect... that he does
11:13 AM veverak: ok
11:13 AM veverak: reading UART fixed
11:13 AM veverak: now why the fuckt the pca does not respond
11:14 AM deshipu: maybe you need to provide power :P
11:14 AM veverak: got logic analyzer hooked on it
11:14 AM veverak: :)
11:14 AM deshipu: rue_bed: you don't program stm32s much, do you?
11:15 AM deshipu: or 32 bit microcontrollers in general, for that matter
11:21 AM rue_mohr: stm32 a bit yea
11:21 AM rue_mohr: I done about 21 hardware tests and small things
11:22 AM deshipu: the thing is, most people can't afford to spend all day just to get their i2c working on a particular model
11:22 AM rue_mohr: I didn't
11:23 AM rue_mohr: flurrys software bit-banged library worked right away
11:23 AM deshipu: and still not be sure if they didn't miss some documented hardware bugs or erratas, or corner cases
11:23 AM veverak: it used to work before ;)
11:23 AM rue_mohr: (after a quick port from assember to C)
11:23 AM rue_mohr: and it works on any pin
11:23 AM rue_mohr: I THINK the code is actaully smaller
11:24 AM deshipu: you should run in in java on a raspberry pi, to make it even more portable
11:24 AM rue_mohr: and iirc, beacuse you need to manually clock out the bits thru the hardware interface anyhow, its just as fast
11:25 AM deshipu: rue_bed: nope, stm32s tend to have a lot of timers you can use, almost on every pin
11:25 AM deshipu: you don't need to manuall clock out the bits
11:25 AM deshipu: (for the servos)
11:25 AM deshipu: and for i2c, you have several sercoms
11:26 AM deshipu: no bit-banging either
11:26 AM deshipu: of course that would require either figuring out how to use sercoms, or using a HAL
11:29 AM rue_mohr: you have looked at the hardware registers? the attiny definitly requires manual i2c bit transmission when using the hardware, you have to repeatedly set a flag for it to send the next bit.
11:29 AM rue_mohr: I thought I recall stm32 being the same stupidity, or maybe is was something to do with having to twiddle a bunch of registers every time you want to send a start or stop bit
11:30 AM rue_mohr: OR, for some reason I neded an i2c channel on a pin that couldn't do it
11:31 AM veverak: so
11:31 AM veverak: i2c packets are accepted by the slave
11:31 AM veverak: the code sends same bytes as different code I wrote for the device (which worked)
11:31 AM veverak: and now
11:31 AM veverak: nothing
11:31 AM deshipu: the attiny has a USI, which does require a little bit of manual work, but still doesn't force you to clock out the bits manually
11:31 AM veverak: no PWM
11:31 AM veverak: :/
11:31 AM deshipu: I have several projects that use i2c on attiny with the USI
11:32 AM rue_mohr: deshipu, the usi does
11:32 AM veverak: and I switched to different PCA
11:32 AM deshipu: rue_mohr: the USI is a separate peripheral
11:32 AM rue_mohr: you have to repeatedly set a flag in a register for every bit to be sent
11:32 AM deshipu: rue_mohr: but that's only on the most primitive AVR 8-bit chips
11:32 AM rue_mohr: and then the start and stop stuff is where they take on SO MUCH code that its less space to bit-bang it
11:33 AM deshipu: rue_mohr: even atmegas have a proper TWI peripheral
11:33 AM rue_mohr: deshipu, attiny w/ usi
11:33 AM rue_mohr: veverak, want to TRY the flurry port I did?
11:33 AM veverak: nope
11:33 AM deshipu: and STM32s are a looong way from that
11:33 AM veverak: I can see that i2c packets are sent
11:33 AM veverak: and accepted by the device
11:33 AM rue_mohr: wait wait
11:33 AM veverak: I don't think it's problem of the lib
11:33 AM rue_mohr: its that 12 bit pwm chip, right?
11:33 AM veverak: pca9685
11:34 AM rue_mohr: I think I have one
11:34 AM veverak: yes
11:34 AM rue_mohr: yea
11:34 AM veverak: it's nice
11:34 AM deshipu: rue_mohr: even modern 8-bit chips (not 20yo AVRs) have a separate i2c peripheral
11:34 AM veverak: rue_mohr: how do you init it?
11:34 AM rue_mohr: what cha bet, I can get one working beofre you can
11:34 AM rue_mohr: w/ stm32
11:34 AM deshipu: for some definition of "working"
11:34 AM rue_mohr: I'll pwm some leds in some kinda wave across the channels
11:35 AM deshipu: you can brute-force bit-bang anything, but that's not the point
11:36 AM rue_mohr: I'll use the flurry library port
11:36 AM deshipu: as soon as your i2c communication is not the only thing that your MCU is supposed to do, you are in trouble
11:36 AM deshipu: veverak: does it even ack the communication?
11:37 AM deshipu: veverak: have you tried to scan the i2c bus?
11:37 AM rue_mohr: its flurrys master library
11:37 AM veverak: deshipu: yeah, that's what I am saying
11:37 AM veverak: it accepted the packets
11:37 AM veverak: but I know the error!
11:37 AM veverak: MY MATH
11:37 AM * veverak calculated the address register address wrong
11:37 AM veverak: so
11:38 AM veverak: now it works
11:38 AM deshipu: :D
11:38 AM veverak: or
11:38 AM veverak: used the wrong constant
11:38 AM veverak: :)
11:39 AM veverak: hmm
11:39 AM veverak: 208hz PWM
11:40 AM deshipu: veverak: you want to take a look at my µp liprary?
11:40 AM deshipu: library?
11:41 AM deshipu: it's basically just one page
11:41 AM deshipu: https://bitbucket.org/thesheep/micropyhton-d1-tote/src/00679908d3fbaf3779fe0c9e90438c7ac531ed28/pca/pca9685.py?at=default&fileviewer=file-view-default
11:42 AM rue_mohr: he doesn't want a library, he wants more abstraction layers
11:42 AM veverak: wat
11:42 AM rue_mohr: give him an OS on a HAL with a SAL on it
11:42 AM veverak: how did you figured that out?
11:42 AM veverak: deshipu: same as here
11:45 AM veverak: ok
11:45 AM veverak: I cheat a bit
11:45 AM veverak: I've got precalculated pre_scale value (101 is for 60Hz)
11:45 AM rue_mohr: no you need to abstract that...
11:46 AM rue_mohr: my_freq
11:46 AM deshipu: veverak: then why are you getting 208Hz? :)
11:46 AM rue_mohr: then it'll work in EU and the USA
11:46 AM veverak: deshipu: the value is not the problem
11:46 AM veverak: it gives 208Hz for 101 too
11:46 AM veverak: :)
11:47 AM veverak: or, for 200 too
11:47 AM deshipu: rue_mohr: bit-banging in assembly will not help when your register address or value you are writing to it are wrong
11:47 AM veverak: deshipu: come one, i wanted rue_mohr to figure that out...
11:48 AM rue_mohr: I'd just said I could make it do my bidding before you could, but ya went and won..
11:48 AM deshipu: veverak: I remember I had to change modes before changing the prescaler
11:48 AM veverak: you could not
11:48 AM veverak: (as you do not know what exactly I am doing....)
11:48 AM veverak: deshipu: I do that
11:49 AM veverak: put to sleep, set prescale, let it wake up
11:50 AM deshipu: maybe that part has a mistake somewhere?
11:52 AM veverak: !!!
11:52 AM veverak: wrong bit changed in the MODE1 reg
11:53 AM veverak: IT WOOOOOOOOOOOOORKS
11:54 AM veverak: https://i.imgur.com/7EOY6Hf.png
11:54 AM veverak: and I am happy
11:54 AM veverak: because top line is packet from the FrSky receiver
11:54 AM veverak: SDA/SCL commands are send to the PCA _as_ the packet is received
11:54 AM veverak: :)
11:55 AM veverak: I hope that PCA9685 changes the PWM pulse length at next cycle
11:55 AM veverak: this way, delay of my thing is minimal
11:55 AM deshipu: iirc it does
11:56 AM veverak: well
11:56 AM veverak: this was supposed to be 2 days ob
11:56 AM veverak: job
11:56 AM veverak: 3 days is good enugh
11:56 AM veverak: only thing I do not like is that it has 295 steps
11:57 AM veverak: (PCA is limiting the resolution)
11:59 AM veverak: ok
11:59 AM veverak: for some reason
11:59 AM veverak: when I move with the joystick too much
11:59 AM veverak: it misses some packets
12:03 PM veverak: aaaaand fixed
12:04 PM veverak: so
12:04 PM veverak: I think I will move debug uart to DMA
12:04 PM veverak: aaaaand make no -O0 build
12:06 PM veverak: O3
12:06 PM veverak: :0
12:06 PM veverak: :)
12:11 PM veverak: LOL
12:11 PM veverak: deshipu: USB can't handle sg9
12:11 PM veverak: or, it can
12:11 PM veverak: but the RC Receiver does not like the voltage drop
12:11 PM veverak: :)
12:12 PM deshipu: veverak: it can't, it's 100mA without a negotition, formally
12:12 PM deshipu: negotiation
12:12 PM deshipu: most usb sources give you 500mA without negotiation, but that's against the spec
12:13 PM veverak: wow
12:13 PM veverak: did not know that 100mA is in spec
12:13 PM veverak: anyway
12:13 PM veverak: the ship I wanted this for
12:13 PM veverak: has some LEDS which I want to control
12:13 PM veverak: but the PWM for servo sucks for that
12:13 PM veverak: I am thinking about making 1/2 of the channels going full PWM range
12:17 PM deshipu: it is a led driver chip, after all
12:18 PM deshipu: though 60Hz is a bit low
12:18 PM veverak: well
12:18 PM deshipu: you might want a low pass filter to avoid flicker
12:18 PM veverak: hmm
12:19 PM deshipu: just a cap would be enough, probably
12:19 PM veverak: yeah, was thinking about that
12:19 PM veverak: also thinking about ordering F103
12:19 PM veverak: L432kc is overkill
12:19 PM veverak: (but it's easier to develop it)
12:19 PM deshipu: I really like samd21 :)
12:20 PM veverak: but truth to be told
12:20 PM deshipu: (or samd11)
12:20 PM veverak: it only reads UART and sends stuff to i2c
12:20 PM veverak: with some data processing
12:20 PM deshipu: samd11 comes in a tsop14 package
12:20 PM veverak: I can do my own pcb with some easy to solder STM32 version
12:20 PM deshipu: same as attiny44
12:21 PM veverak: https://i.stack.imgur.com/g7DO3.jpg
12:21 PM veverak: by the looks of it
12:21 PM veverak: I feel cheeky enough to solder the f103
12:21 PM veverak: now
12:21 PM veverak: the problematic part
12:21 PM deshipu: it's pretty much the same as atmega328p
12:21 PM veverak: veverak: you know that a lot of people would enjoy this code?
12:21 PM veverak: veverak: yes
12:21 PM veverak: veverak: do oyu know that the codestyle you used is bad as hell?
12:21 PM veverak: veverak: yes
12:22 PM veverak: veverak: are you feeling bad for writing such a code?
12:22 PM veverak: veverak: yes
12:22 PM veverak: ...
12:22 PM deshipu: have you heard about linters?
12:22 PM deshipu: or automatic code formatters?
12:22 PM veverak: won't help
12:22 PM veverak: :)
12:22 PM veverak: usign that
12:22 PM veverak: not the problem
12:22 PM veverak: deshipu: a lot of random global variables with not a good name
12:22 PM deshipu: PEBKAC
12:23 PM deshipu: it's fixable
12:23 PM veverak: https://paste.vpsfree.cz/T2Y-T86I/
12:23 PM veverak: this reads the pack and sends i2c commands to pca during that process
12:23 PM veverak: I like some details
12:24 PM veverak: like I switched the order of uart/i2c/packet between parsePacket and afterChannel
12:25 PM veverak: fu
12:25 PM veverak: the flags loading is bullshit
12:26 PM veverak: or, wait, it's ok
12:26 PM veverak: nevermind
12:26 PM deshipu: have you heard about for loops?
12:27 PM veverak: how exactly does that help?
12:27 PM veverak: you still have to parse each channel separatedly
12:28 PM veverak: and given how the channel overlaps in the incoming packet, you can't simply 'forloop' the channels either
12:28 PM deshipu: well, instead of copy-pasting the same code 100 times, and changing some constants, you put it in a for loop that iterates about const array of the constants
12:29 PM veverak: struct array could be ok
12:29 PM veverak: array of struct, that is
12:29 PM deshipu: or five const arrays of ints
12:29 PM deshipu: whatever is convenient
12:29 PM veverak: however
12:29 PM veverak: the parsing of channels from packet would get much more complicated because of that
12:30 PM deshipu: why do you have that nop in line 82?
12:30 PM deshipu: you know you can just have an empty while
12:31 PM veverak: did not feel right
12:31 PM veverak: but I wanted to check something, forgot about it
12:31 PM veverak: I KNOW!
12:31 PM veverak: this is practically prototype
12:31 PM veverak: prototypes can be bad...
12:31 PM deshipu: no code is perfect
12:31 PM deshipu: it's a process
12:32 PM deshipu: every time you change something, you improve it a little bit
12:33 PM veverak: burn it to hell and write again propably
12:33 PM * veverak is literally too lazy to do something about it this time
12:35 PM veverak: or, maybe later
12:36 PM Tom_L: lazy bum
12:39 PM veverak: ok
12:39 PM veverak: so
12:39 PM veverak: I do not want to insert it itno a ship with dupon cbales
12:39 PM veverak: *cables
12:40 PM veverak: deshipu: https://share.icloud.com/photos/0zNw4l_R9j1L3atZIY3wVxXyQ
12:41 PM veverak: I wonder
12:41 PM veverak: 'VIN" pin when connected to the USB is simply the 5V USB voltage, yeah?
12:42 PM Mikeee: there may be a diode in the way
12:43 PM veverak: hmm
12:43 PM veverak: the STM32 board has only one 5V pin
01:07 PM veverak: so
01:07 PM veverak: question is
01:07 PM veverak: what to do with the dupon cables
01:07 PM veverak: I think I can make connection PCB with CNC at hackerspace, between the PCA breakout board and stm32l432
01:07 PM veverak: I think that the RC receiver should be on the cables anyway
01:09 PM veverak: but I don't feel like soldering the boards together
01:09 PM veverak: and two levels of pin header connectors are too much
01:09 PM veverak: hmm, custom board for F103 would be best
01:13 PM veverak: but
01:13 PM veverak: that loses flexibility
01:13 PM veverak: veverak: what do you want?
01:13 PM veverak: veverak: don't know
01:13 PM veverak: veverak: stick to what you got than, it works
06:27 PM rue_mohr: https://www.youtube.com/watch?time_continue=2&v=vMY41LFRpXs
09:29 PM SpeedEvil is now known as Guest78679
10:37 PM pokmo: are there self-defending robots? given how they are increasingly roaming down the streets, surely they're prone to theft
10:50 PM rue_mohr: is a pingpong robot defending itself?
11:00 PM pokmo: heh