-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix override command timeouts #110
Conversation
Signed-off-by: Michael Anderson <[email protected]>
Working nicely now, providing quite realistic behaviors compared to the real system (running with the tweak branch of buoy_msgs of course). I was able to get pc_WindCurr to crash however, output below. I was issuing the command over and over and eventually this happened. So I was probably hitting return on the next command before the first returned. I'm fast, years of centipede in the arcade... :) I was able to recreate, and it doesn't spit the Traceback and all of that until I ctrl-c'd after it hung on the "^[[A" output. Takes down the simulator as well... Possibly related, I am working on my office linux machine over a questionable remote desktop link, so it doesn't feel like a great typing experience in the best of times...
|
Looks like 8-bit assembly language programming. Not bad. |
I suspect the crash was on the simulator end and hung the service call awaiting a response on the pbcmd side. Do you have output from the sim? |
I love Centipede, too :) I'm also a big fan of Ambrosia Software's now obsolete "modernization": https://en.wikipedia.org/wiki/Apeiron_(video_game) |
Oh yes, of course. I didn't look at that, it was behind a bunch of windows... Pasted below, you can see the WindCurr over-rides followed by trouble...
|
Looking at the previous current-command time-stamps, the one that failed was the fastest iteration I can find, at 414ms, FWIW.
|
@mjcarroll, anything that concerns you here at a glance? I'm guessing it's just something gone wrong in my callback lamda, though. |
@hamilton8415, @mjcarroll , I can get the issue to happen by rapidly hitting
|
Yep, up-arrow enter, centipede style. I certainly wasn't typing the command in 400ms, that'd be impressive I think. |
Is there something in the service response that is not re-entrant? My guess would be that we are using the multithreaded executor and a second (or third) service response is clobbering the first. |
@mjcarroll, I am using a multithreaded executor with a spin_once loop:
the class members in the service callback are all protected by mutexes (in a low/high priority lock pattern):
|
I ran another test from within in |
@hamilton8415, since the crash issue doesn't happen programmatically and only when the user is "playing centipede" with pbcmd, I might just call it ok for now, thoughts? |
Yeah, for now I can see that. But, I think this one will turn back up so will need to be addressed eventually is my guess. Tough to have it crash from monkeys poking at the keyboard... |
FYI, to reproduce: it doesn't seem to crash if I use |
@hamilton8415, in attempting to solve the problem by making it go away... I wonder if we could just have the user provide an optional argument for rate or duration of the override if they want more than just one call? This would avoid the centipede typing and crash since it works fine sending fast programmatically. |
@hamilton8415 @mjcarroll, was as simple as putting a rate limit on the executor spin_once loop in the controller plugin. |
Signed-off-by: Michael Anderson <[email protected]>
…rf/buoy_sim into andermi/fix_override_timeouts
Signed-off-by: Michael Anderson <[email protected]>
@hamilton8415 I dare you to break it again! |
Oh man, I am sure I can! I'm talented that way.. :). |
I am back in California and back in the game. I was not however able to make this crash again as before, so that looks fixed. I did notice a surprising behavior in which the winding current timeout length seems to depend on the size of the winding current over-ride. A pc_WindCurr 10 (or 15) set's it at the value for the 2 second timeout. Larger settings (i.e. pc_WindCurr 20 (or 25) sets the value for a longer time, depending as I have seen it on the size of the setting. There's some interplay here so perhaps there's an explanation, but I can't think of it at the moment. See the plot... |
I'm not able to reproduce that. What I am seeing (after printing times) is that 2 seconds always passes in sim time (both from the ros clock and from the gazebo clock) but real time (wall time) taken increases (more than 2 seconds) as the magnitude of winding current override increases. This means the real-time factor of the sim is bogging down during the override presumably because it takes the solver longer to converge? What I am seeing is that the winding current is not remaining constant during the command. But maybe this is because the piston hasn't settled yet when I'm trying this... |
OK, that's interesting. I think you're supposition that the electro-hydraulic solution is taking longer makes sense. Also, I can't quite imagine a bug that would cause the timeout to be specific to the size of the command. My bad for mis-interpeting the plot-juggler time axis. I say merge and move on with our weekends! :) |
@hamilton8415 Putting my controls hat on and looking at my plot above, it looks like we've introduced an unstable zero somewhere in the winding current. Is that realistic? Or, do we need to get that out of the sim? |
@hamilton8415 specifically here... I commanded |
@hamilton8415 well... those spikes only seem to happen when the piston isn't quite settled yet at the beginning I suppose. So, maybe false alarm? Here it is after 600 seconds... |
Yeah, I believe the oscillations are due to the simulated pressure relief valve and speed limiter. It's a bit hard to visualize, but remember that when the motor hits >5000RPM the commanded motor torque will be reduced to keep it from over-spinning. I think you'll see a correlation between those winding current reductions form the target and a large RPM value. It's not super physical though as we don't model the inertia of the motor rotor, so I don't have a great interpretation. |
Another detail is that when the simulation currently starts the buoy is hovering above the water, this dumps a ton of power into the PTO and we see very large RPM's and powers for that first moment. I am not sure how faithful that representation is to reality, and so far have chosen to worry about that later, so I've been concentrating on examining the behaviors after those transients go away. For better or worse... |
Sending commands mid-override did not extend timeout.
Discovered when testing osrf/mbari_wec_utils#37