Problems trying to switch from default datatypes to floats #1162
Labels
Comments
|
Hi @will-gerard, This seems to be a bug in Pinocchio. Thanks |
|
Thank you for the quick fix! Building pinocchio with this change does in fact fix the issue, now I am successfully able to instantiate my state multibody object with However there appears to still be something strange going on when I try to use floats. I am trying to create several residual models to use as part of my cost function. These two both appear to be working correctly: However, the residual model state of the exact same form causes issues: This leads to compilation errors like: When I prototype in python this construction seems fine, i.e. this: Works correctly, and when I switch back to doubles from floats, this is also working: So it does seem like this issue is specific to the ResidualModelStateTpl object, with float specifically as the template parameter. This time the errors look like they are coming from Eigen - maybe there could be a similar cast fix I need to apply somewhere in that library? Thank you so much for your help with this! |
|
Please share the entire code in |
|
The full file looks like this at the moment: Trying to compile this leads to the errors I mention above, but if I comment out the first line in the else statement, the Then it compiles successfully. |
|
I don't understand the issue yet, but I see you didn't forward Pinocchio first. Could you include it as the first line? i.e., your first code line should be |
|
I added that line, still encountering the same issue though it looks like. In case useful, I will attach the full error log here: |
|
Issue no longer experienced after the fix in this PR, compiling Crocoddyl from the devel branch, including this change, fixed the initial issue. My full test with floats is now very close working, I have one other question, I hope I am not missing anything obvious. For completeness, here is my full example, it is very similar to what I shared above, with the file uncommented and one or two small tweaks: It all works correctly up until the creation of the solver itself. I pass in the pointer to the shooting problem, but encounter a type mismatch error, when I include this line: The error trace is: Unlike with the other objects, I don't see a templated version of the solver classes in the docs, and indeed if I try to use a template parameter and declare this as |
|
@will-gerard -- As you said, our solvers are not templatized. To support codegen, we templatized the action models only. However, I could enable this feature ASAP. Is this critical for you now? |
|
I see, thanks for the explanation @cmastalli. We don't need this critically in order to keep going, we just thought it may increase performance. I'm trying to benchmark the solver running in an MPC loop and wanted to try to do what I can to make it as fast as possible. If you do make that update I will try with it, but if not I will go back to using doubles, not an issue. |
|
Thanks for all your help with this @cmastalli. More generally, I am using Crocoddyl with the IIWA manipulator, and so to get a sense of the performance I should be expecting, I have been referencing this paper. It is reported that on a 30 knot point problem the authors are able to achieve a 1kHz control frequency, which I haven't quite been able to replicate. I thought using floats might increase the performance somewhat, which motivated my original question on this thread. When I warm start the solver with a good solution, and time with a monotonic timer around the call to ddp.solve: it still seems to take close to 2 ms (~1.8), even if it only takes 1 ddp iteration. I am running on a 24 core processor at 3.4GHz, so a little slower than the one they are using in that paper, with multithreading enabled. I have not been able to get vectorization to work correctly yet, which I just asked about in 1166. But I'm curious if this is surprising to you, or if this is within the range of performance you would expect? Are there things I should be sure I'm doing in order to get the best performance I can? Thank you in advance for you time. If you would prefer to close this out and open a new issue for this, I am happy to, please let me know! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks for all your work creating and open sourcing such a great trajopt library. I have gone through the tutorials and have been experimenting with it, and have been finding it to work very smoothly. I am able to get a DDP solve working correctly for a Kuka arm, both in python via the bindings and in the c++ directly. However I also want to test with floats, rather than with doubles, and when I try to switch to the templated versions of the functions and pass float as the template parameter, I am running into issues. I saw from this github issue that for parsing a URDF only doubles are supported, but that they can then be cast to floats, which is what I am doing for the robot model I create, and this part seems to work:
However, I am unable to create a state multibody object using the float robot model, and I am not sure why. What I was doing before, and which works correctly, is:
And so what I want to do now is something like:
But this results in the following errors:
The output is large so I have truncated it and provided what seem like the most relevant snippets.
I have tried various versions of this, without success. This construction I included above is the same thing I see done in the arm.hpp benchmark here. And to be sure I was doing the same thing, I tried calling this build_arm_action_models function directly in an extremely simple program:
This compiles and runs successfully. However, when I try to change the template parameter to float, I get the following errors:
And also:
And also:
So there are more errors here, but at least many of them appear to be of the same form, and I am wondering if this is my issue. I am running on Ubuntu 22.04, and installed crocoddyl via conda. I have version 2.0.0 of Crocoddyl, version 2.6.18 of Pinocchio, and version 3.4.0 of Eigen. Any support or suggestions you can provide would be very much appreciated, and if there is any other additional information which would be helpful, please let me know! Also tagging @plancherb1 for visibility.
The text was updated successfully, but these errors were encountered: