lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
mattb0ne has quit [Ping timeout: 256 seconds]
thinkfat has quit [Ping timeout: 248 seconds]
thinkfat has joined #beagle
Shadyman has joined #beagle
vagrantc has joined #beagle
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #beagle
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 276 seconds]
vagrantc has quit [Quit: leaving]
ikarso has joined #beagle
wonko-the-sane has quit [Quit: leaving]
dinuxbg has quit [Ping timeout: 240 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
otisolsen70 has joined #beagle
dinuxbg has joined #beagle
wonko-the-sane has joined #beagle
otisolsen70 has quit [Quit: Leaving]
mag has quit [Ping timeout: 246 seconds]
mag has joined #beagle
florian has joined #beagle
mattb0ne has joined #beagle
zjason``` has joined #beagle
zjason`` has quit [Ping timeout: 246 seconds]
otisolsen70 has joined #beagle
Shadyman has quit [Remote host closed the connection]
jiande2022 has joined #beagle
mattb0ne has quit [Ping timeout: 256 seconds]
mattb0ne has joined #beagle
lucascastro has quit [Ping timeout: 276 seconds]
lucascastro has joined #beagle
XoUoX has joined #beagle
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 260 seconds]
otisolsen70_ has quit [Quit: Leaving]
buzzmarshall has joined #beagle
Stanto has joined #beagle
florian has quit [Quit: Ex-Chat]
Stanto has quit [Read error: Connection reset by peer]
mattb0ne has quit [Ping timeout: 240 seconds]
Siegurd has joined #beagle
<Siegurd>
Hi! I flash am335x-debian-11.3-minimal-armhf-2022-04-01-2gb.img.xz from https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots/31280 for pocketbeagle. Everything seems to work fine except spidev2.1. There is no spidev2.1 in /dev. I try to use "spidev1.0" name instead of "spidev2.1" in my C++ program, but it hangs on. I have a
<Siegurd>
Winbond memory connected to P2_25(MOSI) P2_27(MISO) P2_29(CLK) and P2_31(CS) and there are no signals on them measuring with oscilloscope.
mattb0ne has joined #beagle
XoUoX has quit [Ping timeout: 250 seconds]
mattb0ne has quit [Ping timeout: 246 seconds]
mattb0ne has joined #beagle
mattb0ne has quit [Remote host closed the connection]
mattb0ne has joined #beagle
Siegurd has quit [Quit: Client closed]
mattb0ne has quit [Ping timeout: 276 seconds]
set_ has quit [Ping timeout: 240 seconds]
ikarso has joined #beagle
<zmatt>
those pins are for spi1, and specifically that chipselect is spi1 cs1, so that would be /dev/spidev1.1
<zmatt>
oh he left
mattb0ne has joined #beagle
lucascastro has quit [Remote host closed the connection]
<mattb0ne>
so for the PRU i must always be in blocks of 32 would an array of float not violate that
<zmatt>
mattb0ne: ????
<mattb0ne>
let me post my new strcture
<zmatt>
pru does not support floats
<mattb0ne>
dang
<mattb0ne>
onlt int stuff
<mattb0ne>
hmmm
<zmatt>
only unsigned integer arithmetic, everything else the C compiler pretends to support is entirely emulated in software
<mattb0ne>
does it chew up a lot of memory faking it ?
<zmatt>
it'll cost you a big chunk of program memory no doubt, and be incredibly slow
<zmatt>
why do you think you need floats?
<mattb0ne>
I was making a PID loop
<zmatt>
okay, so why do you think you need floats?
<mattb0ne>
well the derivative component i would need to divide
<mattb0ne>
and would generate a float
<zmatt>
also I have no idea what you were talking about "for the PRU" something (?) would need to be a multiple of 32 (bits? bytes?)
<mattb0ne>
i remember you said something along the lines that the either the pru or py-uio needs things in blocks of 32 when you are putting stuff in shared memory
<zmatt>
a PID controller does not require a divide (by a non-constant) nor does it require floats
<zmatt>
you should make sure 16/32-bit elements are naturally aligned
<mattb0ne>
i that was it
<mattb0ne>
alignment
<mattb0ne>
ok not blocks of 3d
<mattb0ne>
32
<zmatt>
which is for the ARM core's benefit, PRU doesn't care
<mattb0ne>
so what I am trying to do is take a periodic signal of 1000 points 1 per msec and use that as an input signal to this PID loop and have the motor follow it
<mattb0ne>
so to save space I Was going to represent the points as a fourier series since it is arbitrary
<mattb0ne>
so I would need floats and trig functions
<mattb0ne>
to represent the inputs and then do the PID to calc the error
<zmatt>
???
<mattb0ne>
I have a angle vs time function
<mattb0ne>
that is an input signal and I would like my DC motor to spin to follow that
<zmatt>
trig is incredibly expensive, it basically requires big lookup tables
<zmatt>
just store the 1000 points of your periodic signal directly in pru memory
<mattb0ne>
ok
<mattb0ne>
as an array?
<zmatt>
yes? with the lowest precision suitable for the purpose
<zmatt>
the second version of a PID loop shown in this section: https://en.wikipedia.org/wiki/PID_controller#Pseudocode shows that other than for precomputing the constants you basically just compute a dot product between three constants and the last three error values... you can do that in fixed-point by using constants scaled by some power of two and then finally scaled the output value at the end by ...
<zmatt>
...shifting right
<zmatt>
just choose your scale appropriately to provide both sufficient range and accuracy. use 64-bit integers for the intermediate product if need be
<zmatt>
and of course as always with a PID control loop, make sure it's properly tuned for the application
<mattb0ne>
right I am looking to just get it coded tonight and tune tomorrow
<mattb0ne>
i guess it makes sense to work in decoder counts instead of angle
<mattb0ne>
i guess my concern with that would be incrementing so I can repeat. would it be too clunky to add to a reference count for each iteration
<zmatt>
??
<mattb0ne>
let me code it up one second i will paste it will be clear that way
<mattb0ne>
clearer
<zmatt>
ew trying to use a 32-bit multiply with 64-bit accumulator causes the C compiler to produce a hot mess
<zmatt>
lol wtf is the pru compiler completely braindead....
<zmatt>
god, clpru is so awful
<zmatt>
it emits a 5-instruction sequence (including a branch) to sign-extend a 32-bit integer to 64-bit
<zmatt>
(it can be done branch-free using two instructions)
<mattb0ne>
this is half pseudo code from the link and my stuff but it conveys the idea
<mattb0ne>
i repeat my function every second
<mattb0ne>
if I represent the rotation angle as counts
<mattb0ne>
as I repeat the counts would need to increase since it wont wrap after 1440 pulses from my encoder
<mattb0ne>
so I would store a running tally of how many pulses have elapsed and just use the function to add to that amount to keep track of where I am
<mattb0ne>
does that make sense
<zmatt>
your code made sense to me until lines 25-27 where you overwrite your reference position
<zmatt>
(also, I'd recommend putting some range limiting on the final output value to ensure it can't increase/decrease without bounds and eventually wrap)
<zmatt>
also, don't use unsigned arithmetic, your error values are most definitely signed
<zmatt>
as will your constants be
<zmatt>
and make sure that A0, A1, A2 are compile-time constants
<mattb0ne>
my function wraps though
<zmatt>
?
<mattb0ne>
after the 1st pass it starts at zero
<zmatt>
??
<mattb0ne>
so I would have to increment to keep up with the raw counts coming from the encoder.
<zmatt>
???
<mattb0ne>
my function only goes from 0-1second
<zmatt>
???????
<zmatt>
I have absolutely no idea what you're saying
<mattb0ne>
my function which is steps(time in msec) has a domain of [0-1]
<zmatt>
I'm assuming dt is a constant and the absolute time isn't relevant in any way?
<mattb0ne>
right it is not
<zmatt>
eventually you'll be synchronized to your load cell measurements anyway rather than having an explicit sleep
<zmatt>
(though that doesn't really make much of a difference)
<zmatt>
so what's this "period" ? and why are you messing with your reference position? I'm assuming you're simply using that as zero-position for the encoder
<mattb0ne>
right
<zmatt>
so why are you overwriting it?
<mattb0ne>
though now that i think about it
<mattb0ne>
i am not going to accumulate counts
<zmatt>
???
<mattb0ne>
if I do not end back where I started
<mattb0ne>
over time i would accummulate counts and my reference would have to change. So If my function was just to rotate 20 counts
<mattb0ne>
after one pass since I am not going back to start my reference would have to change so I can rotate 20 counts
<zmatt>
I don't understand what you're saying, at all
<mattb0ne>
hmmm
<mattb0ne>
ok let me try this
<mattb0ne>
one second
<zmatt>
like, if the motor position is at its "zero" position when your code starts, and your want to position the motor relative to that start position, then the correct thing to do is to take one snapshot of the position (at the start) as the encoder value corresponding to the zero-position, and do everything relative to that
<zmatt>
your error value would be setpoint + reference_position - position where reference_position is that position snapshot taken at the start and never touched afterwards
<zmatt>
or equivalently setpoint - measured_value where measured_value = position - reference_position (i.e. the position, in encoder pulses, relative to the "zero" position)
<mattb0ne>
i think this is what would happen if I never adjust my reference. This is only in the case where my periodic function does not return to zero
<zmatt>
relative time? wtf? why is time showing up here? relative to what?
<zmatt>
and why?
<zmatt>
oh, relative to your period
<zmatt>
I still don't get it
<zmatt>
unless your control loop is broken, the position (relative to the fixed reference) would converge to the function value
<zmatt>
and the error would continuously converge to zero
<zmatt>
that's the whole point of a control loop
<zmatt>
resetting the reference point would break the control loop
<zmatt>
and cause the position to drift
<mattb0ne>
well my input signal function runs only for 1 second but I plan to run for like 20 minutes
<mattb0ne>
just repeating
<zmatt>
right, which is why you presumably wouldn't want drift
<mattb0ne>
i guess your right
<zmatt>
otherwise I don't understand what you're trying to achieve at all
<mattb0ne>
i just want to repeat an input signal
<mattb0ne>
i think i am confusing my self
<mattb0ne>
let me inplement what we discussed and worry about hypotheticals later
<mattb0ne>
any reason why the decoder is unsigned vs signed
<mattb0ne>
also I am not sure where to put the points
<mattb0ne>
so I am declaring an array of uint8_t
<mattb0ne>
but I dont want that in the message that I send to the program in the ring buffer
<mattb0ne>
i guess I still have PRU1 private memory
ikarso has quit [Quit: Connection closed for inactivity]
<tenchiro>
Good morning. I am trying to build px4 for beaglebone blue. I am having trouble finding an appropriate toolchain. I wish to build on Ubuntu (or debian) RPI machine. However, the oldest version of the toolchain that works on AARCH64 seems to be 11. But the Beaglebone Blue seems to be at 8. I can complete the build according to the instructions on
<tenchiro>
the PX4 website for beaglebone blue, but it won't run because the math library (libm) is one dot version lower than the build. I cannot upgrade the beaglebone, because it says there is no later versions. i cannot downgrade the toolchain because the aarch64 versions don't appear. Any advice is appreciated. Thank you.