-
Notifications
You must be signed in to change notification settings - Fork 42
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
Automatic data processing and plotting of whole-body datasets #20
Comments
In view of robotology/wb-toolbox#160, it seems that having a way to process the data from Matlab without the need of opening the Simulink gui may become important soon. @diegoferigo I think we should discuss if the |
We never cared too much about real-time performance of our models because most times everything worked fine but probably they suffer of similar issues. At the current stage the only limitation of the autogenerated code is gain tuning, it would require work about we store parameters in the autogenerated class and it will take some time to implement something intuitive enough. However, we should start testing the C++ code of current model with hardcoded gains coming from the Matlab workspace from the external pc, and then move to the robot head. |
@Yeshasvitvs suggested a possible workflow in order to be able to see run time plots with Simulink. The idea is to stream the Simulink data in a |
For reference check the yarpscope xml we have now for visualizing FTShoe data. I encoded the color scheme similar to matlab for the plots with in a scope. |
For data naming convention in |
with this commit I've added a Matlab script that automatically locates and processes the data coming from Simulink. I will therefore close this issue, and I will open a new issue specifically for having runtime plots with yarpscope, as detailed in this comment, that anyways will be implemented in a future release. |
Following #13, it would be really nice having a matlab class or script that automatically processes data logged from Simulink (initial idea here). This would require introducing a generic structure for storing whole-body data.
In this way, if the visualization section of all controllers is the same (better if shared), creating plots for publications and documentation would become trivial. We know well how much time we spend on this.
cc @gabrielenava @S-Dafarra
The text was updated successfully, but these errors were encountered: