ikarso has quit [Quit: Connection closed for inactivity]
mattb0ne has quit [Ping timeout: 256 seconds]
set_ has joined #beagle
<zmatt>
you can't slow down the loop, since it is synchronized to the fixed-rate measurements from the load cell
<zmatt>
oh he left
<set_>
I am here!
mattb0ne has joined #beagle
<mattb0ne>
back
thinkfat_ has quit [Ping timeout: 240 seconds]
thinkfat_ has joined #beagle
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #beagle
mattb0ne has quit [Quit: Leaving]
ikarso has joined #beagle
akaWolf has quit [Ping timeout: 240 seconds]
akaWolf has joined #beagle
Posterdati has quit [Read error: Connection reset by peer]
Posterdati has joined #beagle
Guest72 has joined #beagle
florian has joined #beagle
otisolsen70 has joined #beagle
wonko-the-sane has quit [Ping timeout: 240 seconds]
wonko-the-sane has joined #beagle
mattb0ne has joined #beagle
<mattb0ne>
Friday!!!!
<mattb0ne>
soooo zmatt here?
<mattb0ne>
we got wee bit of a problem with this dumb pin
wonko-the-sane has quit [Remote host closed the connection]
mattb0ne has quit [Ping timeout: 256 seconds]
<zmatt>
mattb0ne: the overlay you showed doesn't include P9.13 / gpio 0.31 ?
<zmatt>
what does show-pins | grep P9.13 show?
<zmatt>
aaaand gone again
akaWolf has quit [Ping timeout: 240 seconds]
mattb0ne has joined #beagle
<mattb0ne>
the bealge does not have unistd.h?
<mattb0ne>
i need a delay
<zmatt>
23:37 <@zmatt> mattb0ne: there shouldn't be any __delay_cycles at all since your code is synchronized to the measurement rate of the load cell
<zmatt>
23:38 <@zmatt> i.e. adding __delay_cycles() does not change the rate at which your loop runs, it just reduces the time available per loop iteration until it fails to process the load cell data and faults
<mattb0ne>
right
<mattb0ne>
i took that out but my code is still running too fast
<zmatt>
how is it "too fast" ?
<zmatt>
the way your program currently works means it will inherently operate at the sample rate of the load cell
<zmatt>
and the only way to change that is by changing the sample rate of the load cell
<zmatt>
not by adding a delay
<zmatt>
(or _completely_ redesigning how the program works, changing the structure into something way more complicated than it currently is)
akaWolf has joined #beagle
<zmatt>
my suggestion would be to just run the PID loop at whatever rate you're currently getting, instead of deciding it is "too fast"
<zmatt>
generally spaeking, running a loop faster is a good thing and makes it easier to tune
<mattb0ne>
but I am not tracking time elapsed so I tick through the points on each loop pass
<mattb0ne>
the core check is breaking at like 134 which is asserting the message sizee
<mattb0ne>
never seen that before
<mattb0ne>
I wanted to add the input and output signals to the message
<zmatt>
ehh, why did you put the PID parameter calculation *inside* the loop ?!
<mattb0ne>
oh crap
<mattb0ne>
I was cutting and pasting
<zmatt>
Message must be a multiple of the max alignment, i.e. 4 bytes
<mattb0ne>
did not meat to do that
<zmatt>
otherwise if you have two adjacent messages, the second one would be misaligned
<mattb0ne>
I will add another int16
<zmatt>
the assert is a sanity-check I added exactly to catch mistakes like this :)
<mattb0ne>
so the 16 bit alignment is for python and the 4 byte is for C
<mattb0ne>
just so I have this clear
<zmatt>
??!?
<zmatt>
no, all of the alignment requirements are to ensure structure compatibility between PRU and ARM
<mattb0ne>
<zmatt> no, multiple of 2 bytes (16 bits)
<mattb0ne>
<zmatt> not multiple of 16 bytes
<zmatt>
the alignment requirement is exactly the same in all cases: fields need to be naturally aligned, i.e. a 4-byte (32-bit) integer needs to be 4-byte aligned, a 2-byte (16-bit) integer needs to be 2-byte aligned
<zmatt>
this also implies a structure needs to be aligned in memory to whatever is the largest alignemnt required by any of its members
<zmatt>
which also implies that if you have an array of some structure (e.g. Message), the size of the structure needs to be a multiple of its alignment
<mattb0ne>
ok
<mattb0ne>
and if I have a mix
<mattb0ne>
just align to the biggest one so 4 byte since I have uint32?
<zmatt>
hopefully this clarifies the issue... this is two consecutive Messages with the structure you were using: https://pastebin.com/raw/bMnN6NkX
<zmatt>
I don't see gpio0.31 in your overlay
<zmatt>
the gpio will need to be configured as output, whether by overlay or by software (e.g. python), before using PRU to control the output
<zmatt>
also your logic doesn't make sense... you're setting direction based on whether the control_signal is negative or positive, yet you're limiting the control signal to range 600..4000 which is never negative
<zmatt>
also, you seem to have forgotten about the right-shifting
<zmatt>
I'm also confused why you're checking the raw position (not relative to the reference position) for something
<zmatt>
also, why is your indentation such a terrible mess? :/
<mattb0ne>
lol
<mattb0ne>
good point on the direction
<zmatt>
btw, does https://pastebin.com/raw/bMnN6NkX actually make it clear why your version of struct Message was a problem and why adding another 16-bit field to it fixes the problem?
<mattb0ne>
yes it does
<mattb0ne>
thanks
<zmatt>
because I feel like I've had to explain alignment way too make times already
<mattb0ne>
this one has the motor pin I am interested in
<zmatt>
if show-pins confirms the gpio is configured as output, pru *should* be able to change it just fine... but if it doesn't I can't diagnose that right now, gotto go to work
<mattb0ne>
ok
<mattb0ne>
np
<mattb0ne>
thanks for the lesson
<mattb0ne>
i ditched the bit shifting in favor of just the raw counts btw
<mattb0ne>
so I am working with integers
<mattb0ne>
basically the same thing
<mattb0ne>
i just do it on my input file
mattb0ne has quit [Ping timeout: 276 seconds]
mattb0ne has joined #beagle
<zmatt>
mattb0ne: ehh, that doesn't change that you currently have very little resolution in your coefficients and way more range in your output value than you need
<zmatt>
the input value has no relevance here, that uses the same scale as the measured value (i.e. the encoder position), while I'm talking about the output value and coefficients
Guest72 has quit [Quit: Client closed]
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
<mattb0ne>
so I should still shift
<mattb0ne>
ok
<zmatt>
well, it'll increase the resolution available for your coefficients
akaWolf has quit [Ping timeout: 240 seconds]
<mattb0ne>
is this a formal technique?
akaWolf has joined #beagle
buckket has quit [Remote host closed the connection]
buckket has joined #beagle
akaWolf has quit [Ping timeout: 272 seconds]
lucascastro has quit [Ping timeout: 246 seconds]
akaWolf has joined #beagle
<zmatt>
uhh, yeah? effectively it's using fixed-point arithmetic
<mattb0ne>
hahaha
<zmatt>
?
<mattb0ne>
i am just imagined you saying that
<mattb0ne>
and the incredulous look on your face when you typed it
<mattb0ne>
just funny
<mattb0ne>
that is all
<zmatt>
basically, if you'd want to know the integer part of 12.345 * 120 you can calculate 12345 * 120 and then drop the last three digits, i.e. right-shift by three digits
<zmatt>
this is the same, except of course using bits rather than digits
<zmatt>
so if you right-shift your output value by 16 before using it as pwm value, you effectively give your coefficients 16 bits after the decimal point
lucascastro has joined #beagle
<mattb0ne>
I see but I would need to scale it back to fit the PWM requirements
<zmatt>
and of course then your coefficients need to be much larger, but you presumably still need to tune those anyway
<zmatt>
and you'll generally want to start with small values
<zmatt>
instead of using a periodic signal it would also be sensible to start with just following a single value that you read from shared memory (i.e. a signal of length 1) so you can see how the control loop responds to manual changes of the input value
<mattb0ne>
good idea!
alan_o has quit [Ping timeout: 250 seconds]
fakuivan has quit [Read error: Connection reset by peer]
fakuivan has joined #beagle
alan_o has joined #beagle
mattb0ne has quit [Remote host closed the connection]
NishanthMenon[m] has quit [Quit: You have been kicked for being idle]
zjason has left #beagle [ERC (IRC client for Emacs 28.0.50)]
zjason has joined #beagle
Shadyman has quit [Quit: Leaving.]
florian has quit [Quit: Ex-Chat]
ikarso has quit [Quit: Connection closed for inactivity]
mattb00ne has joined #beagle
mattb000ne has joined #beagle
mattb0ne has quit [Ping timeout: 256 seconds]
mattb00ne has quit [Ping timeout: 240 seconds]
xet7 has quit [Remote host closed the connection]
ikarso has joined #beagle
Guest51 has joined #beagle
Guest51 has quit [Client Quit]
set_ has quit [Ping timeout: 276 seconds]
xet7 has joined #beagle
Posterdati has quit [Ping timeout: 276 seconds]
Posterdati has joined #beagle
buzzmarshall has joined #beagle
lucascastro has quit [Ping timeout: 276 seconds]
vagrantc has quit [Quit: leaving]
<mattb000ne>
ok the motor almost chopped my fingers
<mattb000ne>
I need to figure out this timing thing
<mattb000ne>
the motor just sits there until i nudge it forward then it takes off
<mattb000ne>
I also think it is blowing through my checks as it seems to be runnning at rated speed. The cap I have should block that
<mattb000ne>
not sure what is going on
<mattb000ne>
need some food
<mattb000ne>
also that pin is still not switching
<mattb000ne>
as a stop gap I will control from python but it will be slower
<mattb000ne>
break time!
mattb000ne has quit [Ping timeout: 272 seconds]
otisolsen70 has quit [Quit: Leaving]
Guest67 has joined #beagle
<Guest67>
Too much trial and error in google answers on Debian and BBB. I want to hire $$ someone to give me a head start on configuring the BBB. Staff augmentation for my computer engineering dept, we do not have the right experience to jumpstart the BBB in a new project. Where does one go to hire a consultant?