redstarcomrade has quit [Read error: Connection reset by peer]
mal has quit [Server closed connection]
mal has joined #glasgow
bvernoux has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
redstarcomrade has joined #glasgow
m42uko_ has quit [Server closed connection]
m42uko has joined #glasgow
itsmk has quit [Server closed connection]
itsmk has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
leper has quit [Server closed connection]
leper has joined #glasgow
ar-jan has joined #glasgow
<tpw_rules>
whitequark[cis]: are you around?
<tpw_rules>
i'm seeing bizarre things with the servo applet and i think it's a misunderstanding in how the repl works
sknebel has quit [Server closed connection]
sknebel has joined #glasgow
<whitequark[cis]>
tpw_rules: I think I can push a fix for these things
<whitequark[cis]>
one sec
<whitequark[cis]>
try this
<_whitenotifier-f>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<tpw_rules>
ah, that sounds about right
<whitequark[cis]>
(added two flush calls)
<whitequark[cis]>
I tried to use it on my ICE, which is assembled
<whitequark[cis]>
start, 2s, stop
<whitequark[cis]>
and it did not work as expected.
<tpw_rules>
it seems to flush when the >>> returns
<whitequark[cis]>
yes
<whitequark[cis]>
that is explicit behavior of the REPL
<whitequark[cis]>
because otherwise shit's a little too annoying
<tpw_rules>
there we go
<whitequark[cis]>
:3
<tpw_rules>
do you want to squash and i'll leave a formal review
<whitequark[cis]>
in the end it seems like 12A@24V isn't enough to start an ICE
<whitequark[cis]>
oh yeah one sec
<_whitenotifier-f>
[glasgow] whitequark synchronize pull request #486: applet.control.servo: an applet for controlling servomotors and brushless ESC modules - https://github.com/GlasgowEmbedded/glasgow/pull/486
<whitequark[cis]>
done
<tpw_rules>
how big is it? is it a little nitro thing?
<whitequark[cis]>
yes, 3.5cc
<tpw_rules>
i didn't think they required that much torque
<tpw_rules>
but like i said earlier i've never worked with em
<whitequark[cis]>
it rotates like 2-3 times and then maxes out the PSU
<tpw_rules>
so set_value shouldn't need to flush if it always enables
<tpw_rules>
alternately keep track of the enabled state and only enable when necessary?
<tpw_rules>
(should be safe to always assume enabled on init)
<whitequark[cis]>
could do, though I did the current code because it's simplest and most resistant to thoughtlessupdates later
<whitequark[cis]>
* could do, though I did the current code because it's simplest and most resistant to thoughtless updates later
<tpw_rules>
fair
<tpw_rules>
idk how much penalty there is in a flush and i don't think anybody is doing hi speed robots
<whitequark[cis]>
very little
<tpw_rules>
leading question: how does the e-stop circuit work
<tpw_rules>
cause every time i press it the servo moves, which isn't excellent for a stop button
<tpw_rules>
it looks like the power supply gets stopped substantially before the FPGA and there's some sort of RC decay on the output pulse which the servo thinks is a short pulse and moves to
<tpw_rules>
i get some movement maybe 1 out of 10 times if i unplug the signal wire bc i guess i truncate a pulse, not every time like the estop button
<tpw_rules>
well i'm done playing with it. that e-stop thing might deserve follow up