thinkfat_ has quit [Ping timeout: 248 seconds]
thinkfat_ has joined #beagle
mattb0ne has quit [Ping timeout: 276 seconds]
Shadyman has joined #beagle
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
<set_> I know it is late but! Where are you guys? Where are you guys in building on 5.17.x and .dts education?
<set_> I know you guys/gals are helping as mentors this year w/ GSoC, i.e. so I am in no rush.
<set_> I was just wondering.
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 246 seconds]
mattb0ne has joined #beagle
<zmatt> mattb0ne: what does your python-side code looks like?
<zmatt> because my guess would be the issue is there, not on the pru side
<mattb0ne> i can paste bin
ketas has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
GenTooMan has quit [Quit: Leaving]
akaWolf has quit [Ping timeout: 246 seconds]
akaWolf has joined #beagle
mattb0ne has quit [Ping timeout: 240 seconds]
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 240 seconds]
vagrantc has quit [Quit: leaving]
wonko-the-sane has quit [Quit: leaving]
<zmatt> based on what are you saying the message numbers "jump" ? baesd on the log lines you're pending? but you're only printing one log message per batch of messages processed in python
<zmatt> (to minimize the amount of work done per message, since otherwise python can't keep up)
GenTooMan has joined #beagle
ikarso has joined #beagle
<zmatt> mattb0ne, if you read irclog later: see if you can toggle gpio0.31 from pru using these lines:
rob_w has joined #beagle
<set_> Python is s l o w.
foxhole has quit [Ping timeout: 250 seconds]
javaJake_ has joined #beagle
javaJake has quit [Ping timeout: 250 seconds]
javaJake_ is now known as javaJake
florian has joined #beagle
wonko-the-sane has joined #beagle
michaelo has joined #beagle
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 256 seconds]
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #beagle
mattb0ne has joined #beagle
<mattb0ne> back for another day of troubleshooting
<mattb0ne> seems like the transfer limit on passing messages to the python is 10-12 msec
<mattb0ne> i so the load cell is not limiting i think
<mattb0ne> the loadcell can out put 600 times a second
<mattb0ne> but I can only send at ~100 times a second
<mattb0ne> if the thing is truly moving at 5ns an instruction I would think I would get better performance
<mattb0ne> All I have my code doing is reading a value from shared memory and collecting the time stamp
<mattb0ne> reading the load cell does not change the performance so the bottleneck is elsewere. I am pretty sure it is the pru because the time stamp is set on the PRU side
<mattb0ne> is there a way to check where the PRU code is slow easily
Shadyman has quit [Remote host closed the connection]
<zmatt> mattb0ne: maybe make a habit of checking to see what replies you missed
<zmatt> mattb0ne: you're printing a log line per _batch_ of messages processed in python
<zmatt> and also, you have a 10ms sleep between processing batches of messages, which means you're going to see at most 100 log lines per second
<zmatt> you're likewise only writing one line to csv per batch of messages, instead of one line per message
<mattb0ne> oh ok
<zmatt> it probably should have been a good hint that the section of code labeled "update user interface" is not the right place to write data to file
<mattb0ne> lol
<mattb0ne> a file is not UI
<mattb0ne> kidding
<mattb0ne> do you think a file write is faster than output to the screen
<mattb0ne> i am wondering if I would have the same problem
<mattb0ne> in anyevent until I can change the motor direction on the PRU side the speed is sort of lost
<zmatt> doing any part of the real-time processing in python would make using PRU entirely pointless
<zmatt> PRU can control GPIO just fine, if it's not working then it simply needs to be debugged
<zmatt> like I said earlier, see if you can toggle gpio0.31 from pru using these lines:
<mattb0ne> ok
<mattb0ne> did you take a peak at my overlay
<mattb0ne> was that ok
<zmatt> don't remember, just use show-pins to confirm the pin is muxed as gpio and configured as output
<zmatt> hm, I just checked the compiler output for gpio_set_one_low( &GPIO0, 31 ); and gpio_set_one_high( &GPIO0, 31 ); and it seems to produce the correct output (equivalent to ) so I really don't see any reason for it to not work
<mattb0ne> ok I am going to make a simple program that sets a motor speed and runs those commands
<mattb0ne> my overlay
<zmatt> gpio 0.31 is P9.13 ... I don't see any pinmux declared for it?
<zmatt> never mind, I'm blind
<zmatt> then I guess it looks fine... maybe rename gpio_pins (both occurrences) to motor_gpio_pins to match your node name
<mattb0ne> using those lines worked
<zmatt> and I'm presonally add a comment to each pin (lines 95-100) to mention which gpio (name and number) it is
<zmatt> *personally
<zmatt> but gpio_set_one_high( &GPIO0, 31 ); and gpio_set_one_low( &GPIO0, 31 ); doesn't? as far as I can tell they produce the same code output
<mattb0ne> let me double check
<mattb0ne> side note is there a way to have a problem gracefully exit after ctrl-c
<mattb0ne> like a try catch wont fix a ctrl-c exit from python
<mattb0ne> when I break the code the motor will keep spinning
<mattb0ne> I want to put in a wind down
<mattb0ne> or somethign
<zmatt> then add code to your PRU program to gracefully turn off the motor when it hits an abort
<zmatt> or add a try-catch in python that stops the PRU and then manually turns off the motor or whatever
<zmatt> but I'd put more trust in PRU to do it
<mattb0ne> ok
<zmatt> (though if you're letting PRU do it you obviously shouldn't kill the PRU core on exiting)
<zmatt> having said that, it looks like you're already doing some cleanup in python now
<zmatt> so it would be easier to add your motor cleanup to that
<mattb0ne> ok
<mattb0ne> does ctrl-C go to the finally in a try catch
<zmatt> yes
<mattb0ne> ok the helper functions work
<mattb0ne> the issue was with the decoder wrapping sometimes so rather than being at 0 it is at 2^32 or something slightly less
<zmatt> that doesn't matter
<mattb0ne> also should I be shifting my coefficents as well
<mattb0ne> right now I only do the signal
<zmatt> that's the whole reason for doing the shifting, to get a large range to work with for your coefficients
<zmatt> oh right for some reason you're still doing some kind of weird test on the raw encoder position
<zmatt> the purpose of which is a complete mystery to me
<mattb0ne> working with the raw encoder
<zmatt> like, surely that should at the very least be done on the position relative to reference_count ? unless I completely misunderstand the point of this code
<zmatt> also, I just noticed you declared your counter as uint8_t yet you're trying to use it for range 0..999 ... newsflash, that range doesn't fit in an uint8_t :P
<zmatt> you'll also want your coefficients to be int32_t rather than int16_t
<zmatt> also, you need to take the absolute value of the control signal to set EPWM1A ... I had that in my original code fragment but you seemed to have removed that in editing it
<mattb0ne> crap
<mattb0ne> for some reason i had it in my mind that uint8 would do 32, something something
<mattb0ne> the raw signal was to get around the fact that the PRU does not have float support
<mattb0ne> now you said I can bit shift
<zmatt> ???
<mattb0ne> the int thing is just my dumbness
<mattb0ne> the raw counts comment
<mattb0ne> like I cannot put 112.25 in the PRU
<zmatt> I was talkihng about the weird "fault condition" check, which is using the "position", not relative to reference_count or anything
<mattb0ne> well my signal was not goign to accumulate counts if working correctly
<mattb0ne> so if it hit either number something went wrong
<zmatt> right, it won't accumulate counts... but it starts at reference_count
<mattb0ne> ahhhh
<mattb0ne> yes
<zmatt> also 42949000 seems like a weird arbitrary number
<zmatt> like, it's missing two zeros if it's supposed to be close to 2**32
<zmatt> if you want to limit the growth on the error value (to catch when the algorithm is seriously failing to converge), just put a test on abs(error[0])
<zmatt> using an assert() for that may be justified
<mattb0ne> yeah it was arbitrary
<mattb0ne> nature calls afk
mattb0ne has quit [Ping timeout: 240 seconds]
mattb0ne has joined #beagle
argonautx has joined #beagle
SJFriedl has joined #beagle
Guest34 has joined #beagle
Guest34 has quit [Client Quit]
Guest67 has joined #beagle
Guest67 has quit [Client Quit]
mattb0ne has quit [Ping timeout: 240 seconds]
wonko-the-sane has quit [Remote host closed the connection]
wonko-the-sane has joined #beagle
mattb0ne has joined #beagle
rob_w has quit [Remote host closed the connection]
mattb0ne has quit [Ping timeout: 276 seconds]
argonautx has quit [Quit: Leaving]
lucascastro has quit [Ping timeout: 272 seconds]
mattb0ne has joined #beagle
lucascastro has joined #beagle
lucascastro has quit [Ping timeout: 248 seconds]
florian has quit [Quit: Ex-Chat]
mattb0ne has quit [Ping timeout: 276 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
lucascastro has joined #beagle
xet7 has quit [Remote host closed the connection]
zjason has quit [Read error: Connection reset by peer]
zjason has joined #beagle
mattb0ne has joined #beagle
lucascastro has quit [Ping timeout: 240 seconds]
<mattb0ne> zmatt: any reasoning on the bit shift by 16? I ask because I wind up needing to make my Kp and everything very large to have a signal large enough to be non zero when i shift back
lucascastro has joined #beagle
<zmatt> mattb0ne: it's just the most obvious shift value for the range needed here, convenient for the compiler, and 16 fractional bits is hopefully more than plenty for your coefficients
<mattb0ne> so maybe something else is wrong
<zmatt> and yes your coefficients would get larger by a factor of 65536, but why does that matter?
<mattb0ne> i am just wondering why they are soo big
<mattb0ne> like I am trying to get the motor to move and I at kp = 1000000
<zmatt> because they now have 16 fractional bits, even though you don't write them as fractional
<mattb0ne> just seems odd but I also have no context for this stuff
<zmatt> also, Kp doesn't allow for the control value to grow as needed to get a response
<zmatt> Ki does
<zmatt> iirc
<mattb0ne> right but you suppose to start with kp and zero out everything else
<mattb0ne> I am will eventually auto tune it
<mattb0ne> in matlab but I need to get in the ball park
<mattb0ne> I am wondering if I am doing something wrong
<zmatt> well the problem is also that your motor probably won't move unless your output has a certain value... so yeah if you're using Kp only then it may need to be fairly substantial
<mattb0ne> if I strip out the shifting I can get the motor to move but I lose tha resolution as you say
<mattb0ne> I will keep messing with it
<zmatt> 1000000 is effectively 15.2587890625 if you take the shifting into account
<mattb0ne> which blows my mind I am still wrestling with that but I just got to stew on it
<mattb0ne> and jsut to be clear I am not shifting my coefficents so I have kp = 1000000 not kp = 1000000 <16
<zmatt> you scale down the final output value by 65536, therefore to get equivalent results you need coefficients scaled up by the same factor of 65536
<zmatt> yes correct
<zmatt> putting a literal left-shift on your coefficients would make it impossible to use the extra precision you have and make the whole shifting pointless
<mattb0ne> ok
<zmatt> though I guess you could do something like (int)( 15.25 * 0x10000 )
<zmatt> the floating-point compputation would in that case be evaluated entirely at compile-time which is fine
<zmatt> while allowing you to write coefficients of "normal" magnitude, with a fractional part if needed/desired
<zmatt> obviously you're free to not use shifting at all, but that would severely limit the precision available for tuning
<mattb0ne> yeah I need the precision
<zmatt> mattb0ne: all the shifting is doing is multiplying the coefficients by some constant scale-factor and then dividing the final result by that same scale factor... that scale factor being a power of two, specifically 0x10000, because dividing by this (using a right-shift) is extremely cheap, while division in general is not
<zmatt> and this gives you the extra precision, since now your coefficients don't need to be integer, they only need to be integer after scaling
mattb0ne has quit [Ping timeout: 246 seconds]
mattb0ne has joined #beagle
<mattb0ne> so I could do 1.5 << 16;
<mattb0ne> for a coefficent
Shadyman has joined #beagle
<zmatt> yes no sorta, you have to write it (int)( 1.5 * 0x10000 )
<zmatt> multiplying by 0x10000 is the same thing as left-shifting by 16, except multiplication also works for floats while left-shifting does not
<mattb0ne> ok I think I am going to do that
<zmatt> and of course the final cast to (int) to ensure we don't actually get floating-point arithmetic at runtime
<mattb0ne> would I need to change anything else down stream if that is how I define the coefficents?
<zmatt> this is assuming your have a final right-shift by 16, which you already have
<zmatt> on the control value
<mattb0ne> right
vagrantc has joined #beagle
<mattb0ne> so my control signal doesnt budget off zero
<mattb0ne> do I shift the error or something
<mattb0ne> something is up I have increased kP to the point that I get a truncation warning on a unint32
<mattb0ne> i can paste my code
<mattb0ne> one second
<zmatt> that would require an _enormous_ value of Kp
<zmatt> one that would cause the PID calculation to spit out complete garbage
<zmatt> I'm assuming you mean int32_t, not uint32_t
<mattb0ne> sorry signed int
<zmatt> yeah, int
<mattb0ne> I got to be making a bone head move somewhere if I strip out the shifting i get hte motor to move it is just I cannot adjust anything really because I have no precision
<zmatt> the problem is you're declaring your A[] array as int16_t
<mattb0ne> got it
<mattb0ne> must be wrapping or something if I lower the shifting to 4 and my scale factor to 0x00100 i get movement
<mattb0ne> but I would only get 0.25 resolution
<zmatt> no, 1/16 .... but there shouldn't be any wrapping going on here unless your coefficients are wildly too large
<zmatt> uhh, also, scale factor 0x100 corresponds to a shift of 8
<zmatt> not 4
<zmatt> i.e. you set a much larger value (16 times as large as previously)
<zmatt> and that's why you're getting a response
<zmatt> also, why are you resetting your reference_count again?
<zmatt> that will break your PID loop
<zmatt> by causing drift
<set_> Which side does GND go to on the BBB for the serial debug cable? Near the USB Port or the Ethernet Port?
<zmatt> near the ethernet port, the side marked with a white dot on the pcb
<set_> Thank you sir.
<zmatt> what did you do to your bbb to need a serial debug cable?
<set_> Built an image.
<set_> I am booting into it.
<set_> But for now, until I add the required dep, I am stuck w/ the UART0.
<zmatt> you know what, forget I asked
<set_> Otay! You have are having a nice day. I can tell.
<set_> Full of candy and licorice?
<mattb0ne> well my error is based on postion count vs my input signal which repeats
<zmatt> mattb0ne: error is the difference between desired position (input signal) and actual position
<mattb0ne> so I have a reference
<zmatt> in this case, actual position is being measured relative to reference_count
<mattb0ne> and I add my input signal to it
<mattb0ne> and that is my target
<zmatt> if you keep changing the reference, your position can drift unbounded
<mattb0ne> yeah your right I guess what I am finding is the motor keeps spining so my error just takes off
<mattb0ne> but resetting is not doing anything to fix the issue
<zmatt> no, it will make it worse
<zmatt> if the motor is running away then there's a problem with the control loop or coefficients
<zmatt> or motor direction
<mattb0ne> right
<zmatt> like I said previously, I'd suggest giving your signal a length of 1 for now.... i.e. have the algorithm try to keep a fixed position
<zmatt> and if it can do that successfully, try slowly changing that value from python
kveremitz has quit [Ping timeout: 248 seconds]
<mattb0ne> ok I will try that
<zmatt> and probably put an assert or something on abs(error[0]) ..., if it gets too big your control algorithm has failed
<mattb0ne> now i took some abs function from the internet
<mattb0ne> but shouldnt there be a abs function in the std header
<zmatt> make sure the motor direction is such that if control_signal is positive, your motor spins in the direction that increases position
<zmatt> yes, <stdlib.h>
<zmatt> also that abs function looks like garbage
<zmatt> not in the least because its argument is declared as int16_t
<zmatt> so you're turning your control value into garbage
<zmatt> also, it looks hideously expensive compared to the much simpler and faster return value < 0 ? -value : value;
<zmatt> but also, you don't need to define it yourself anyway, it's in #include <stdlib.h>
<zmatt> also, you're subtracting your reference_count twice now
<mattb0ne> ok
<mattb0ne> let me fix that
<mattb0ne> I think my first attemp at using the abs it said it was undefined
<zmatt> because your file doesn't #include <stdlib.h>
<mattb0ne> how am i subtracting reference_count twice
<zmatt> you've defined uint32_t current_position = *position_var - reference_count;
<zmatt> (a better name for that variable would be relative_position, also it should be signed rather than unsigned)
<zmatt> and then your error[0] definition is input_signal + reference_count - current_position
<zmatt> which is equivalent to input_signal - (current_position - reference_count)
<zmatt> which is input_signal - (position * 2 * reference_count) if position is the raw sampled position value (i.e. *position_var)
<mattb0ne> whats a cleaner way to label this I felt adding reference count to the input signal makes sense
<mattb0ne> i guess I would get rid of the reference adjustment on the position variable
<zmatt> mhh, I just realized a problem with the way this PID is expressed
<zmatt> ok yeah, and it's a big problem
<zmatt> I think
<zmatt> let me think for a bit
<zmatt> they're handling the P and D terms by differentiating and then integrating again... but I think that will interact poorly with the range-limiting
<zmatt> or it might anyway
<zmatt> I guess if you have a non-zero I term that should at least rectify the situation
<zmatt> what range are you expecting on the input signal?
<zmatt> (out of curiosity)
<zmatt> this alternative may be better behaved:
<zmatt> in that case you may want to monitor error_accum to ensure it doesn't grow excessively large.... though it will only do that if your PID loop is broken (e.g. due to wrong motor direction or very poorly chosen coefficients)
<jkridner> zmatt: have you done a uio instance on TDA4VM?
<jkridner> for PRUs.
<mattb0ne> input will always will be less than 1440
<zmatt> jkridner: given that I don't have a TDA4VM, ehh no? though I'm pretty sure it should Just Work
<mattb0ne> it seems to be working now
<jkridner> k.
<jkridner> I just need to track down the device-tree bindings.
<mattb0ne> thouhg I will try that other formulation in the paste bin
<mattb0ne> i think I have showcased my ineptitude enough today
<mattb0ne> lol
<jkridner> got a good link for them on am5729? I don't think it ever made it to our standard dt, but I'll look.
<mattb0ne> thanks zmatt
<jkridner> what are all those interrupts?
<zmatt> overlays for both pruss instances, for kernels 4.14/4.19 and 5.4/5.10
<zmatt> jkridner: those are the interrupts from pruss to arm... on kernel 5.x I need to redeclare those since they moved the original declaration to a child node
<jkridner> k.
<zmatt> they're not in the 4.x version of the overlay because it had them declared on the &pruss1/&pruss2 node itself in the base dts:
nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
<zmatt> a proper from-scratch declaration of the node (without reusing/patching the node declared for remoteproc) would have those interrupts, the reg-property, and the properties I declare in the overlay
<zmatt> i.e. the required properties are: reg compatible ti,pintc-offset interrupts
<zmatt> pretty simple
<jkridner> looks like they were broken down into ti,icssg-intc
<zmatt> yeah, which makes sense, but not in combination with uio-pruss
<jkridner> ah.
<zmatt> (the pruss-instance property I add on am57xx is just to identify the different pruss instances to userspace, for use by udev rules)
<jkridner> I'm trying to use remoteproc, but enable mmap of the shared memory.
<jkridner> so, not full-on uio.
<zmatt> ah that's a different story
mattb0ne has quit [Ping timeout: 272 seconds]
<zmatt> this is full-on uio
<jkridner> yeah, I don't want the whole thing mapped with uio, just the shared memories.
<zmatt> for shared memory regions, add child devices to the pruss (on 5.x) or pruss_soc_bus (on 4.x) node
<zmatt> using compatible = "uio"; and a reg property covering the range you want to be mappable
<jkridner> there is an iccsgX_mem entry as a subentry to ti,j721e-icssg without its own compatible line.
<zmatt> and a symlink property to have udev create a nice symlink, e.g. symlink = "uio/pruss1-shmem"; to create /dev/uio/pruss1-shmem
<zmatt> yeah, that's used by remoteproc no doubt
<jkridner> for loading?
<jkridner> can I have both?
<jkridner> or will it go boom?
<zmatt> you can have both, the extra uio device won't care about remoteproc or vice versa
<zmatt> you can in principle also have multiple named reg-ranges per uio device, though that's a bit annoying for userspace so I'd suggest to instead create multiple devices in that case
<jkridner> child off of icssg (ti,j721e-icssg)?
<jkridner> multiple devices?
<zmatt> it looks like it's a bus so that *should* be fine
<zmatt> if it's actually fussy about sub-devices that it may be necessary to interject a parent bus around the pruss device (i.e. resurrect the pruss_soc_bus present in 4.x)
<jkridner> &icssg0 { compatible = "uio"; symlink = "uio/icssg0-shmem"; }; ?
<jkridner> oh, plus the reg entries.
<jkridner> oh... I need to actually make the device!
<jkridner> not change the one that is there!
<zmatt> yeah
<zmatt> e.g. &icssg0 { uio@10000 { reg = <0x10000, 0x10000>; compatible = "uio"; symlink = "uio/icssg0/dram2"; }; };
<zmatt> or something
<zmatt> actually I'd lean towards calling it uio/pruss0/dram2 since "ICSSG" is really just a fancy version number for pruss :P
<jkridner> dram is always so confusing for me.... I have a hard time absorbing "data" vs. "dynamic".
<zmatt> hehe, yeah
<zmatt> in this case it's dram vs iram
<jkridner> yeah
<zmatt> jkridner: also, to do this on tda4vm you'll want to ask rcn-ee to apply to the ti-arm64 kernel, otherwise compatible="uio" will require a modprobe config file ( ) to work
<jkridner> k
<zmatt> (that patch is already in other kernels)
<zmatt> yes, by default it _requires_ using its module param to fill in the first (and only) match
<zmatt> which is... very convenient *cough*
<jkridner> hmmmm..... not sure where I've got a syntax error in my DT.
<jkridner> ah, missing semi