**** BEGIN LOGGING AT Tue Apr 19 02:59:57 2022 Apr 19 17:58:28 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 Apr 19 17:58:28 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. Apr 19 21:39:04 those pins are for spi1, and specifically that chipselect is spi1 cs1, so that would be /dev/spidev1.1 Apr 19 21:39:10 oh he left Apr 19 21:55:36 so for the PRU i must always be in blocks of 32 would an array of float not violate that Apr 19 21:56:02 mattb0ne: ???? Apr 19 21:56:18 let me post my new strcture Apr 19 21:56:27 pru does not support floats Apr 19 21:57:30 dang Apr 19 21:57:42 onlt int stuff Apr 19 21:57:45 hmmm Apr 19 21:58:08 only unsigned integer arithmetic, everything else the C compiler pretends to support is entirely emulated in software Apr 19 21:58:45 does it chew up a lot of memory faking it ? Apr 19 21:59:13 it'll cost you a big chunk of program memory no doubt, and be incredibly slow Apr 19 21:59:39 why do you think you need floats? Apr 19 21:59:42 I was making a PID loop Apr 19 21:59:59 okay, so why do you think you need floats? Apr 19 22:01:25 well the derivative component i would need to divide Apr 19 22:01:35 and would generate a float Apr 19 22:01:51 also I have no idea what you were talking about "for the PRU" something (?) would need to be a multiple of 32 (bits? bytes?) Apr 19 22:02:33 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 Apr 19 22:03:06 a PID controller does not require a divide (by a non-constant) nor does it require floats Apr 19 22:03:26 you should make sure 16/32-bit elements are naturally aligned Apr 19 22:03:33 i that was it Apr 19 22:03:35 alignment Apr 19 22:03:48 ok not blocks of 3d Apr 19 22:03:49 32 Apr 19 22:03:58 which is for the ARM core's benefit, PRU doesn't care Apr 19 22:05:17 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 Apr 19 22:05:44 so to save space I Was going to represent the points as a fourier series since it is arbitrary Apr 19 22:05:57 so I would need floats and trig functions Apr 19 22:06:09 to represent the inputs and then do the PID to calc the error Apr 19 22:06:10 ??? Apr 19 22:06:32 I have a angle vs time function Apr 19 22:06:52 that is an input signal and I would like my DC motor to spin to follow that Apr 19 22:07:05 trig is incredibly expensive, it basically requires big lookup tables Apr 19 22:07:30 just store the 1000 points of your periodic signal directly in pru memory Apr 19 22:07:37 ok Apr 19 22:07:46 as an array? Apr 19 22:08:06 yes? with the lowest precision suitable for the purpose Apr 19 22:11:37 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 ... Apr 19 22:11:43 ...shifting right Apr 19 22:13:06 just choose your scale appropriately to provide both sufficient range and accuracy. use 64-bit integers for the intermediate product if need be Apr 19 22:16:45 and of course as always with a PID control loop, make sure it's properly tuned for the application Apr 19 22:17:53 right I am looking to just get it coded tonight and tune tomorrow Apr 19 22:23:28 i guess it makes sense to work in decoder counts instead of angle Apr 19 22:25:56 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 Apr 19 22:26:19 ?? Apr 19 22:26:37 let me code it up one second i will paste it will be clear that way Apr 19 22:26:45 clearer Apr 19 22:28:04 ew trying to use a 32-bit multiply with 64-bit accumulator causes the C compiler to produce a hot mess Apr 19 22:28:58 lol wtf is the pru compiler completely braindead.... Apr 19 22:29:31 god, clpru is so awful Apr 19 22:31:26 it emits a 5-instruction sequence (including a branch) to sign-extend a 32-bit integer to 64-bit Apr 19 22:32:02 (it can be done branch-free using two instructions) Apr 19 22:32:17 is that a texas instrument problem Apr 19 22:32:34 or beaglebone Apr 19 22:32:51 TI, the PRU C compiler just sucks Apr 19 22:41:15 https://pastebin.com/e07renhN Apr 19 22:41:31 this is half pseudo code from the link and my stuff but it conveys the idea Apr 19 22:41:45 i repeat my function every second Apr 19 22:42:07 if I represent the rotation angle as counts Apr 19 22:42:32 as I repeat the counts would need to increase since it wont wrap after 1440 pulses from my encoder Apr 19 22:43:06 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 Apr 19 22:43:10 does that make sense Apr 19 22:43:59 your code made sense to me until lines 25-27 where you overwrite your reference position Apr 19 22:45:35 (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) Apr 19 22:46:11 also, don't use unsigned arithmetic, your error values are most definitely signed Apr 19 22:46:35 as will your constants be Apr 19 22:47:20 and make sure that A0, A1, A2 are compile-time constants Apr 19 22:49:32 my function wraps though Apr 19 22:49:42 ? Apr 19 22:49:43 after the 1st pass it starts at zero Apr 19 22:49:57 ?? Apr 19 22:50:01 so I would have to increment to keep up with the raw counts coming from the encoder. Apr 19 22:50:09 ??? Apr 19 22:50:11 my function only goes from 0-1second Apr 19 22:50:22 ??????? Apr 19 22:50:58 I have absolutely no idea what you're saying Apr 19 22:51:08 my function which is steps(time in msec) has a domain of [0-1] Apr 19 22:51:24 I'm assuming dt is a constant and the absolute time isn't relevant in any way? Apr 19 22:51:37 right it is not Apr 19 22:51:40 eventually you'll be synchronized to your load cell measurements anyway rather than having an explicit sleep Apr 19 22:52:11 (though that doesn't really make much of a difference) Apr 19 22:53:01 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 Apr 19 22:53:11 right Apr 19 22:53:19 so why are you overwriting it? Apr 19 22:53:24 though now that i think about it Apr 19 22:53:32 i am not going to accumulate counts Apr 19 22:53:51 ??? Apr 19 22:54:05 if I do not end back where I started Apr 19 22:54:55 over time i would accummulate counts and my reference would have to change. So If my function was just to rotate 20 counts Apr 19 22:55:18 after one pass since I am not going back to start my reference would have to change so I can rotate 20 counts Apr 19 22:55:31 I don't understand what you're saying, at all Apr 19 22:55:37 hmmm Apr 19 22:55:54 ok let me try this Apr 19 22:55:56 one second Apr 19 22:57:03 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 Apr 19 22:58:21 your error value would be setpoint + reference_position - position where reference_position is that position snapshot taken at the start and never touched afterwards Apr 19 22:59:17 or equivalently setpoint - measured_value where measured_value = position - reference_position (i.e. the position, in encoder pulses, relative to the "zero" position) Apr 19 23:07:21 i think https://pastebin.com/74tyTpb3 Apr 19 23:07:57 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 Apr 19 23:08:51 relative time? wtf? why is time showing up here? relative to what? Apr 19 23:09:01 and why? Apr 19 23:09:25 oh, relative to your period Apr 19 23:09:44 I still don't get it Apr 19 23:10:17 unless your control loop is broken, the position (relative to the fixed reference) would converge to the function value Apr 19 23:10:38 and the error would continuously converge to zero Apr 19 23:10:49 that's the whole point of a control loop Apr 19 23:11:12 resetting the reference point would break the control loop Apr 19 23:11:25 and cause the position to drift Apr 19 23:12:29 well my input signal function runs only for 1 second but I plan to run for like 20 minutes Apr 19 23:12:33 just repeating Apr 19 23:12:46 right, which is why you presumably wouldn't want drift Apr 19 23:12:58 i guess your right Apr 19 23:12:58 otherwise I don't understand what you're trying to achieve at all Apr 19 23:13:21 i just want to repeat an input signal Apr 19 23:13:30 i think i am confusing my self Apr 19 23:13:44 let me inplement what we discussed and worry about hypotheticals later Apr 19 23:19:34 any reason why the decoder is unsigned vs signed Apr 19 23:20:17 also I am not sure where to put the points Apr 19 23:20:36 so I am declaring an array of uint8_t Apr 19 23:21:05 but I dont want that in the message that I send to the program in the ring buffer Apr 19 23:23:31 i guess I still have PRU1 private memory Apr 20 00:48:23 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 Apr 20 00:48:24 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. Apr 20 01:01:22 tenchiro: you can just run a more recent version of debian, e.g. there are debian buster images here: https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots/31280 Apr 20 01:01:35 *debian bullseye Apr 20 01:02:57 or run debian buster on the rpi, e.g. in a container, to get a similar toolchain Apr 20 01:03:35 bullseye (which is the latest stable release of debian) uses gcc 10 Apr 20 01:06:23 in general, when cross-building from one debian/ubuntu system (using the distro-provided toolchain and multiarch support) to another you'll want to use very similar versions on both Apr 20 01:07:55 mattb0ne: sorry, I fell asleep... and ehh, you can put it whereever convenient I guess? I don't quite remember where you're currently putting what Apr 20 01:08:50 mattb0ne: the decoder is declared as unsigned because that makes the most sense for a counter that wraps Apr 20 01:51:48 zmatt do you have that paste bin with the pru memory addresses Apr 20 02:08:11 Mo memory! Apr 20 02:08:25 Guys. Apr 20 02:09:02 I did not get the job on the motor enabled, infrared detection, gate thing. Apr 20 02:09:03 Boo. Apr 20 02:09:05 I know. Apr 20 02:09:17 But...I am going to keep trying. The more, the merrier. Apr 20 02:12:33 Go, go, gadget, GSoC. I hope everyone does well. I am still just building and learning. Mo enablement! Apr 20 02:28:07 zmatt thank you so much! Let me try upgrading the BBB to one of these newer version. I really appreciate that. Yes, there is a note about that in the PX4 docs to keep the versions similar, I just couldn't figure out how to do it. I didn't realize there are newer versions of debian I can use on the BBB. Thank you. Apr 20 02:28:56 Also, I am trying to follow these instructions, however after flashing the monthly, I get a 403 error when I try to access the card to configure the wifi. Apr 20 02:44:06 I have flashed the monthly build and rebooted my beaglebone, however I cannot seem to access it to configure the wifi. It does connect and I can see the files in the local drive. However when I try to follow the instructions, it says "access forbidden 403". I am able to connect through wifi, but I get the same error when I try to access the Apr 20 02:44:07 ipaddress 192.168.8.1. And advice would be appreciated. Thank you. Apr 20 02:56:12 Hello! Apr 20 02:56:15 Dang it. Apr 20 02:57:17 Hello...this is catch up period! What did I miss? Apr 20 02:57:37 And why are people not in school? Apr 20 02:58:00 Where are the books, the people, and the BBBs? Apr 20 02:58:12 Nothing anymore, anymore nothing ever? Apr 20 02:58:17 Argh. Apr 20 02:58:44 Anyway, times are tough but it must be tougher than expected for some. Apr 20 02:59:05 So, I will retreat to la-la-land once more (since I am perfect). Ha. Apr 20 02:59:53 * set_ must be goodie-two-shoes! **** ENDING LOGGING AT Wed Apr 20 02:59:56 2022