Over the summer, I decided I would try to figure out Odometry for next year. To aid in calculations, it would be nice to do matrix manipulations in VexCode, so I tried to add Eigen to aid in this. I added the library to the include directory and updated the makefile to search the directory. This worked, but generates a strange error. Can anyone tell me what this means, and if there is any sort of resolution to it?
int
and int32_t
are different sizes. You would have to cast const int32_t *
to const int *
Edit:
Yeah, for some reason VexCode’s int
and Eigen’s int
is different and causing a conflict.
You could attempt to go into the file and cast it to try to fix the issue.
However, given that you seem to know what you are doing with programming, I would recommend switching to PROS, which uses un-tampered C++ (gcc). You will find trying to use external libraries is easier, as well as using the software outside of the default config.
I know that BLRS used Eigen in their code this year, they made a reveal this week.
Why would you think VEXcode is tampering with C++ ?
VEXCode is using a standard compiler, in preview3 it’s currently clang 7.0, the next preview will be clang 8,0, It’s linking against essentially the same SDK using the same headers. There shouldn’t be any issue.
No, they are the same size on V5, both 32 bit. But they are different types and the compiler understands that.
Ok, sorry, was not sure why it gave that error and jumped to conclusions.
I guess the issue lies somewhere else.
What’s happening is that Eigen is using the optimized vector processing provided by the Neon processor that the V5 has, that’s part of a system header file, arm_neon.h. There’s a mismatch between what that header thinks is an int32_t and what the VEX sdk thinks is an int32_t, it may be a clang/gcc difference, not sure. Anyway, for now turn off Neon detection like this and it will build.
#include "vex.h"
#include <iostream>
#undef __ARM_NEON__
#undef __ARM_NEON
#include "Eigen/Dense"
@jpearman that worked perfectly, thank you! Do you expect this to cause any complications in the future?
The calculations will run slower than if they were executing on the neon fpu. I need to see why/where we have a mismatch, probably just a difference between the gcc and clang headers, we build the SDK with gcc but are using clang in VEXcode because of the improved error reporting and possibility to use on other platforms where we cannot use gcc.
Cool. Thanks for the help again. I look forward to further updates to VexCode.
Hi, how did you update the makefile to include eigen? Thanks!
I don’t have immediate access to this project at the moment and I never pursued it further after making it work. I ended up solving the linear algebra to make it work. However, the makefile is accessible in vexcode on the list to the left. Within the file, there is a line that states “# project header file locations”. This section contains the header files search directories.
When I get access to that file again, I’ll post what I changed.