RobotLocomotion / drake

Model-based design and verification for robotics.
https://drake.mit.edu
Other
3.24k stars 1.25k forks source link

maxROAFeedback does not allow to change options or include saturation #1107

Closed ghost closed 9 years ago

ghost commented 9 years ago

Dear Russ!

I have watched your lectures on "underactuated robotics" some time ago and I have recently found this great toolbox. I was really happy to see some implementations. I want to use it in my Phd thesis. I need to learn a lot in the topic and about this code but I think I have found some glitches....

My system is similar to the Acrobot so I tried running the examples to understand the concepts and I was especially interested in the nonlinear feedback controllers calculated by SOS optimization (I have read the article you're referring to) and this is what I found:

  1. Everything run ok but something was strange - there was no change in results although I was changing the options in "runMaxROA.m". After a small investigation I have found that there is a small mistake in the code (at least I think it is a mistake). In line 33 of "maxROAFeedback.m" there is: if (nargin<5) options = struct(); which effectively overwrites any options set by user because options is the 4th argument to this function. I have just changed it to nargin<4 and it started working ok.
  2. After some time I have noticed another thing - the input limits did not seem to change anything although the file says that the saturation is implemented. I have found out what happens. Line 54 says: sys = sys.inStateFrame(Vframe), and it effectively removes the input limits set in the system. I checked it by displaying umin/umax before and after this function and it always changed the values to infinity. I have very little experience with this toolbox but it doesn't seem right, because the whole saturation part just never runs. I have tried setting the limits again after this line but It caused some dimension errors in calculations. Maybe this code is just not finished yet and you blocked it on purpose(?)...

Regards, Patryk

RussTedrake commented 9 years ago

Excellent. It looks like you've found some bugs. This particular code has not been tested nearly as thoroughly as most of the rest of the codebase.

We'll update it soon (we're busy preparing for a robotics competition right now). Thanks!

On May 14, 2015, at 7:31 PM, zbuffer86 notifications@github.com wrote:

Dear Russ!

I have watched your lectures on "underactuated robotics" some time ago and I have recently found this great toolbox. I was really happy to see some implementations. I want to use it in my Phd thesis. I need to learn a lot in the topic and about this code but I think I have found some glitches....

My system is similar to the Acrobot so I tried running the examples to understand the concepts and I was especially interested in the nonlinear feedback controllers calculated by SOS optimization (I have read the article you're referring to) and this is what I found:

Everything run ok but something was strange - there was no change in results although I was changing the options in "runMaxROA.m". After a small investigation I have found that there is a small mistake in the code (at least I think it is a mistake). In line 33 of "maxROAFeedback.m" there is: if (nargin<5) options = struct(); which effectively overwrites any options set by user because options is the 4th argument to this function. I have just changed it to nargin<4 and it started working ok.

After some time I have noticed another thing - the input limits did not seem to change anything although the file says that the saturation is implemented. I have found out what happens. Line 54 says: sys = sys.inStateFrame(Vframe), and it effectively removes the input limits set in the system. I checked it by displaying umin/umax before and after this function and it always changed the values to infinity. I have very little experience with this toolbox but it doesn't seem right, because the whole saturation part just never runs. I have tried setting the limits again after this line but It caused some dimension errors in calculations. Maybe this code is just not finished yet and you blocked it on purpose(?)...

Regards, Patryk

— Reply to this email directly or view it on GitHub.