<zmatt>
mattb0ne: that question has no meaningful answer
brook has joined #beagle
brook has quit [Remote host closed the connection]
<zmatt>
open loop control works if you can reliably predict the appropriate control output value that will achieve the desired system state
<zmatt>
without feedback from the system state
brook has joined #beagle
<mattb0ne>
i guess I am trying to undestand why I feel the load cell singal feels sluggish
<mattb0ne>
like everything is delayed
<zmatt>
delayed how much?
<mattb0ne>
to sanity check I did real time monitoring with the vendor app and it is snappier
<zmatt>
what filter do you have selected in the load cell?
<mattb0ne>
it is running at the same baudrate and filter level
<zmatt>
uhh
<mattb0ne>
so I think it is my loop
<zmatt>
wait how exactly did you compare these?
<mattb0ne>
nothing scientific but I can get data to plot
<zmatt>
like, how do you "feel" the "snappiness" with the app vs with your code?
<mattb0ne>
was just eyeballing the response to a step input
brook has quit [Ping timeout: 268 seconds]
<zmatt>
a step input to what?
<zmatt>
if you're comparing the signal into your pid loop with the measurements from your load cell then you're likely to indeed see a slower step response than if you just step the control value of the electromagnet and observe the load cell response from that
<zmatt>
what I don't understand is why you're getting the vendor app involved instead of your own code, since that just makes things harder to compare and doesn't make sense unless you're suspecting an issue with your load cell measurement code
<zmatt>
how fast or slow the response will be with your PID loop depends entirely on how it's tuned
<zmatt>
in some cases a PID loop may actually achieve a _faster_ system response than simply stepping the control value, depending on the system response (from control output to received load cell values) and of course again PID loop tuning
<zmatt>
in general you'd use open-loop control if it's too hard to obtain useful feedback values or the system is so simple that it's easy to control open-loop
<zmatt>
closed-loop control will generally always yield better results
<zmatt>
if you're considering open-loop control then step one would be to make sure you thoroughly understand the system you're controlling and how it responds to control inputs under all conditions in which it will be used
<zmatt>
of course, understanding the system you're controlling is also a good idea when using closed-loop control, but with closed-loop you may be able to get away with treating the system as a black box
<zmatt>
open-loop is harder, it requires you can fully model your system mathematically
<mattb0ne>
I was just looking at the vendor stuff just to see if I was correct
<mattb0ne>
I am not going to use it going forward
<mattb0ne>
I just know it is slow
<zmatt>
no but I don't even see what information you think you're getting from it
<mattb0ne>
I did the extreme case of disabling the loop and directly toggling the ehrpwm1
<mattb0ne>
and it is still really slow
<mattb0ne>
what would be most informative?
<zmatt>
right, so why did you do that with the vendor app instead of having PRU do that (bypass the control loop and use the input value directly as output value)
<mattb0ne>
I did both
<mattb0ne>
that is how I know it is slow
<zmatt>
what is "it" ?
<mattb0ne>
so in my code I deleted the PID logic and sent a step input to the pwm my top out is 10000 so I did 0 to 6000
<mattb0ne>
and had that loop
<mattb0ne>
so I recorded that for a few cycles plotted
<mattb0ne>
and it looks sluggish
<mattb0ne>
I can paste bing that stuff
<zmatt>
go ahead
<mattb0ne>
ok one moment
<zmatt>
but that would imply the problem isn't in your control loop
<zmatt>
but in how you're configuring the load cell
<mattb0ne>
but the vendor app would not look correct
<zmatt>
?
<mattb0ne>
that is why I think it is loop
<mattb0ne>
sorry
<zmatt>
but you _removed_ your control loop
<zmatt>
the PID code
<mattb0ne>
rigth
<mattb0ne>
so I am not sure what it could be
<mattb0ne>
let me pastebin
brook has joined #beagle
mattb00ne has joined #beagle
mattb000ne has joined #beagle
<zmatt>
also pastebin the pru code you used
<mattb000ne>
here is the plot https://ibb.co/5MkD3bq green equals control signal going directly into the pwm, blue is load cell signal
<zmatt>
btw it would be nice to have higher resolution timestamps than ms just to be able to check the jitter in the load cell measurements
<mattb000ne>
how do i convert cycles to microseconds
<mattb000ne>
timestamp_cycles // 200
<mattb000ne>
?
<zmatt>
yeah
brook has quit [Remote host closed the connection]
<mattb000ne>
i do that on the python side how does that improve the resolution
brook has joined #beagle
<mattb000ne>
i do not have any signal coming in that falls on the same millisecond
brook has quit [Remote host closed the connection]
<zmatt>
it's not super relevant for what you're asking, I just wanted to do a quick check on the timestamps to make sure they're evenly spaced and there's none missing or whatever, but I realized the timestamps don't actually have enough resolution to check that
doppo has quit [Remote host closed the connection]
<mattb000ne>
do you agree the response seems slow?
<mattb000ne>
let me test with a weight
<mattb000ne>
cut the magnet out compeltely
<mattb000ne>
if that looks better it could be something about the speed of the coil charging up
<mattb000ne>
i think that maybe what I am seeing it
<mattb000ne>
i would be surprised if that is it you figure anything running on current would be much faster than my equipment
<zmatt>
I mean, that depends on a lot of details of your setup
<zmatt>
but you were claiming you saw different results when using the vendor app
<mattb0ne>
my method of loading was different
<mattb0ne>
so was not apples to apples
<zmatt>
and that's how you make data useless ;)
<mattb0ne>
I see what you mean
<mattb0ne>
so if I do a test with the code with the controls turned off and putting a weight on and taking it off
<mattb0ne>
you see the sharp response
<mattb0ne>
i am surprised the electro magnet is this slow
<zmatt>
does the weight result in a comparable amount of force? i.e. is it making a step of a similar size than you previously tested?
mattb000ne has quit [Ping timeout: 276 seconds]
mattb00ne has quit [Ping timeout: 276 seconds]
<mattb0ne>
I was having problems tuning where I even with really high Kp it would be slow but I guess there is an inherent time lag
<mattb0ne>
yes
<mattb0ne>
I need to read up on time constants
<zmatt>
I don't suppose you know the inductance of the electromagnet?
<mattb0ne>
no it is a piece of crap from amazon
<mattb0ne>
I am sure I could buy one that is better suited for this
<zmatt>
what exactly do you mean by "electromagnet" anyway? because I assume you actually mean some sort of solenoid-based actuator?
<mattb0ne>
apparently I would need a higher voltage
<zmatt>
so you're using it to put force on some metallic surface which presumably doesn't actually move much in response to the force?
<zmatt>
since there's of course the headache that a magnet will attract something but as the thing attracted gets closer it will also experience more force, presumably drawing it even closer
brook has joined #beagle
<mattb0ne>
right why I wanted the PID
<mattb0ne>
so it could maybe hold a constant force by adjusting for that
<mattb0ne>
seems like I need an AC version of what I have
<zmatt>
yep, closer-loop control seems like a good idea
<zmatt>
also, I just realized it would actually be useful if you could disable load cell filtering for this measurement
<mattb0ne>
I think once I get something that can manifest a field
<mattb0ne>
you think so
<mattb0ne>
i would double my sample rate
<mattb0ne>
but gets noisy
<mattb0ne>
it would be more responsive though
<mattb0ne>
i guess the PRU could average faster than the EM100 right
<zmatt>
yeah noisy is fine, it's just so we can more clearly see the response of the system without the filtering adding its own response to it
<mattb0ne>
i can do that
<zmatt>
filtering in the PRU would certainly be an option
<zmatt>
another good reason for closed-loop control: temperature-dependence
<zmatt>
which is nice since it implies (almost) linear behaviour
<zmatt>
mattb0ne: if you do end up doing that measurement without load cell filter, it would be nice to also have more measurement cycles... both to give the temperature the chance to stabilize and to allow for filtering out noise by averaging cycles together
<zmatt>
and I think you can omit the intermediate step, just make it a square wave (0.5s high, 0.5s low)
<mattb0ne>
I will try and set that up
buzzmarshall has quit [Quit: Konversation terminated!]
Shadyman has joined #beagle
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 255 seconds]
vagrantc has quit [Quit: leaving]
ikarso has joined #beagle
AKN has joined #beagle
Steve_ has joined #beagle
SJFriedl has quit [Ping timeout: 248 seconds]
mattb0ne has quit [Ping timeout: 265 seconds]
mattb0ne has joined #beagle
Guest18 has joined #beagle
indigaz has quit [Quit: Ping timeout (120 seconds)]
indigaz has joined #beagle
AKN has quit [Ping timeout: 240 seconds]
AKN has joined #beagle
mattb0ne has quit [Ping timeout: 240 seconds]
ft has quit [Quit: leaving]
florian_kc has joined #beagle
mattb0ne has joined #beagle
Parduz has joined #beagle
<Parduz>
I have two USB dongles that i attach to a BBB: one is seen as /dev/sda1 and the other one as /dev/sda. so my FSTAB rule to automount sda1 in /media/usb fails.
<Parduz>
The only difference (vendor apart) between the two dongles that i can see from dmesg is the bcdDevice: https://pastebin.com/LDPxPCJj
<Parduz>
I has a fstab rule to automount sda1... i'd like to know why there's a difference so i can try to be able to catch whatever USB dongle the user will put in the BBB
Parduz has quit [Quit: Client closed]
Parduz has joined #beagle
Steve_ has quit [Ping timeout: 250 seconds]
SJFriedl has joined #beagle
mattb0ne has quit [Ping timeout: 246 seconds]
Steve_ has joined #beagle
SJFriedl has quit [Ping timeout: 246 seconds]
Shadyman has quit [Quit: Leaving.]
rob_w has joined #beagle
mattb0ne has joined #beagle
Stat_headcrabed has joined #beagle
Stat_headcrabed has quit [Client Quit]
balrog has quit [Quit: Bye]
AKN has quit [Ping timeout: 276 seconds]
AKN has joined #beagle
balrog has joined #beagle
Guest18 has quit [Ping timeout: 260 seconds]
AKN has quit [Ping timeout: 246 seconds]
<jfsimon1981_c>
Hi Matt
<jfsimon1981_c>
Have you still considered design a board for your product or th BB is still running core application ?