crazyswarm build on windows

[knmcguire]

Honored to present the first issue to this repo :)

surprise surprise... the windows build of crazyswarm doesn't work right from the start.

This is the error I'm getting:

Starting >>> crazyswarm2_interfaces
--- stderr: crazyswarm2
CMake Error at C:/Program Files/CMake/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Boost (missing: Boost_INCLUDE_DIR program_options)

This seems to be an limitation of Cmake in windows, so currently investigating what the right approach is here.

[knmcguire]

that was fixed by installing boost by chocolatey, what the install of ROS didn't mention.

The problem now is the folowing:

  Checking Build System
  Building Custom Rule C:/Users/kimbe/Documents/Development/ROS/ros2_ws/src/crazyswarm2/crazyswarm2/deps/crazyflie_tools/crazyflie_cpp/crazyflie-link-cpp/CMakeLists.txt
cl : command line error D8021: invalid numeric argument '/Wextra' [C:\Users\kimbe\Documents\Development\ROS\ros2_ws\build\crazyswarm2\deps\crazyflie_tools\crazyflie_cpp\crazyflie-link-cpp\libusb.vcxproj]

there is probably some kind of if statement that we need to put in the cmakelist.txt file to not use -wextra when building for the windows. Found something on stackoverflow about this

[knmcguire]

The cmakelist.txt in crazyflie_cpp was that problem. Which is solved by replacing add_compile_options(-Wall -Wextra) with

if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  add_compile_options(-Wall -Wextra)
endif()

Now I'm getting the next wave of errors: error C2065: 'packed': undeclared identifier which seems to be compiler related.

[whoenig]

Those packed things are not crossplatform (gcc/clang specific) and the goal is to get rid of them entirely. I guess I missed a bunch of them:-/

[whoenig]

Should be fixed in the latest version

[knmcguire]

Great, thanks! We are one step closer, namely the linking errors.

Just a slice of the errors, but I've got the log file attached to this on the bottom. Seems that somebody had a similar issue a while ago but that person question was never resolved.

full_state__functions.obj : error LNK2019: unresolved external symbol __imp_geometry_msgs__msg__Twist__init referenced in function crazyswarm2_interfaces__msg__FullState__init [C:\Users\kimbe\Documents\Development\ROS\ros2_ws\build\crazyswarm2_interfaces\crazyswarm2_interfaces__rosidl_generator_c.vcxproj]

stdout_stderr.log

[whoenig]

Hopefully those are fixed now (by following https://github.com/ros2/common_interfaces/tree/master/std_msgs as an example, rather than the official tutorials...)

[knmcguire]

got the latest changes but no cigar yet!

Let me first try the write msg and srv tutorial on windows again just to make sure that it's not something at fault in my own configuration. I'll update soon

[knmcguire]

It was because that package was missing dependencies for some extra packages. See this PR https://github.com/IMRCLab/crazyswarm2/pull/4

[knmcguire]

Not there yet. Crazyswarm2 package build now says:

CMake Error in CMakeLists.txt:
  Imported target "rclcpp::rclcpp" includes non-existent path

    "C:/ci/ws/install/include"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.

Seems to be CI related, but can't really see in cmakelists.txt what the problem is...

stdout_stderr.log

[whoenig]

Did you try one of the C++ examples that uses rclcpp from the docs, e.g., https://docs.ros.org/en/galactic/Tutorials/Writing-A-Simple-Cpp-Publisher-And-Subscriber.html?

[knmcguire]

good one, not on windows yet. Trying it now

[knmcguire]

same problem.. and it's due to this issue: https://github.com/ros2/rclcpp/issues/1688#issuecomment-858467147

I'll try the workaround what they are suggesting

[knmcguire]

So making a dummy folder as they suggested is doing the trick.

Now it is something within crazyflie_tools. But first I'll go for lunch

C:\Users\kimbe\Documents\Development\ROS\ros2_ws\src\crazyswarm2\crazyswarm2\deps\crazyflie_tools\src\listLogVariables.cpp(3,10): fatal error C1083: Cannot open include file: 'boost/program_options.hpp': No such file or directory [C:\Users\kimbe\Documents\Development\ROS\ros2_ws\build\crazyswarm2\deps\crazyflie_tools\listLogVariables.vcxproj]
  Building Custom Rule C:/Users/kimbe/Documents/Development/ROS/ros2_ws/src/crazyswarm2/crazyswarm2/deps/crazyflie_tools/CMakeLists.txt

stdout_stderr.log

[whoenig]

I think in https://github.com/whoenig/crazyflie_tools/blob/7737af88b0e3af267f5f8f4589b42b71edbf87b4/CMakeLists.txt#L18, you'll need to add ${Boost_INCLUDE_DIRS}.

[knmcguire]

Yeah indeed, that works thanks! Now I'm trying to deal with this error: LINK : fatal error LNK1104: cannot open file 'libboost_program_options-vc142-mt-x64-1_74.lib'

Seems to be python version related, but I've just updated that exactly to this boost version and nothing yet. Continuing to investigate!

[knmcguire]

Really strange... so it is able to find the write boos library component

-- Found Boost: C:/local/boost_1_74_0 (found suitable version "1.74.0", minimum required is "1.74.0") found components: program_options

but... is still gives the cannot open file. I've checked windows process explorer but nothing is blocking these library files.

Tomorrow I'm going to work on the simulator again and presentations prep, so I'll leave this on ice for now.

[whoenig]

You likely need

link_directories(${Boost_LIBRARY_DIRS})

in your CMakeLists.txt (after include_directories).

[knmcguire]

Thanks fort the suggestion. I did already tried that but the same error unfortunately...

This is how the cmakelist.txt (crazyflie_tools) looks like for the boost part:

find_package(Boost 1.74.0 REQUIRED COMPONENTS program_options REQUIRED)
add_subdirectory(crazyflie_cpp)

include_directories(
  crazyflie_cpp/include
  ${Boost_INCLUDE_DIRS}
)

link_directories(${Boost_LIBRARY_DIRS})

[knmcguire]

btw, seems that we are not the only one with boost and windows problems: https://answers.ros.org/question/390446/could-not-find-boost-missing-python3-found-version-1760-windows-10/ I'm following that question so hopefully somebody will give some pointers on it.

[knmcguire]

ahh wait.... I know what is going on. Cmake is trying to find libboost_program_options-vc142-mt-x64-1_74.lib but I only have libboost_program_options-vc141-mt-x64-1_74.lib. only one number difference.

The error handling should be better... it should indicate that they are not able to find it.

Let me see if I can disable the automatic boost library find and set it directly in cmakelist.txt

[whoenig]

This magic number is the compiler version I think. So boost was built and installed for a slightly different compiler (Visual Studio) version than what you are currently using.

[knmcguire]

You might be right. I installed unity on my computer that came with a trail of visual studio paid version, which I unselected, but perhaps it still installed the boost libraries that came with that... I'll remove the libraries and reinstall Visual Studio 2019 community edition

[knmcguire]

I removed the boost libraries and reinstalled c++ visual studio 2019, but those boost libraries don't reappear. What might have happened, is that the ros install instructions installed them but the wrong version

I just went straight to the boost binaries itself and I'm currently installing the exact boost library cmake was asking for. Fingers crossed!

[knmcguire]

Alright! So its able to find boost now. Now the next part of errors are emerging:

libboost_program_options-vc142-mt-x64-1_74.lib(value_semantic.obj) : error LNK2005: "void __cdecl boost::program_options::validators::check_first_occurrence(class boost::any const &)" (?check_first_occurrence@validators@program_options@boost@@YAXAEBVany@3@@Z) already defined in boost_program_options-vc142-mt-x64-1_74.lib(boost_program_options-vc142-mt-x64-1_74.dll) [C:\Users\kimbe\Documents\Development\ROS\build\crazyswarm2\deps\crazyflie_tools\log.vcxproj

...

C:\Users\kimbe\Documents\Development\ROS\build\crazyswarm2\deps\crazyflie_tools\Release\log.exe : fatal error LNK1169: one or more multiply defined symbols found [C:\Users\kimbe\Documents\Development\ROS\build\crazyswarm2\deps\crazyflie_tools\log.vcxproj]

Thought first that this was due to me not unselecting cmake for visual studio according to the ROS instructions, (forgot to do that during reinstall), but unfortunately that's not it. So we are handling with double definitions now.

stdout_stderr.log

[whoenig]

Is your CMakeLists still like in https://github.com/IMRCLab/crazyswarm2/issues/1#issuecomment-964280456? It does look like it is now trying to link against the same library twice.

[knmcguire]

yeah it still similar and I tried to remove link_directories(${Boost_LIBRARY_DIRS}) and see what happens but then I get the LNK1104 error again.

I've now also removed the version and one extra REQUIRED of the boost library, as it is now able to find the libraries by itself. Still with the duplication errors though:

CMakeLists.txt

[whoenig]

You could add a "message(${Boost_LIBRARIES})" somewhere in the CMakeLists.txt. In the log, it should print what this variable is set to. Perhaps it somehow includes the same entries twice.

[knmcguire]

Yeah true I'll try that in the coming days. I switched now to Ubuntu for some ignition :)

[knmcguire]

So this is the output that message gives: OptimizedC:/local/boost_1_74_0/lib64-msvc-14.2/boost_program_options-vc142-mt-x64-1_74.libdebugC:/local/boost_1_74_0/lib64-msvc-14.2/boost_program_options-vc142-mt-gd-x64-1_74.lib

I'll remove the boost library from path and see what happens

[knmcguire]

nope, no difference in if I remove the boost library from path...

An closer look to the error message: libboost_program_options-vc142-mt-x64-1_74.lib(options_description.obj) : error LNK2005: "public: class boost::program_options::options_description_easy_init & __cdecl boost::program_options::options_description_easy_init::operator()(char const *,class boost::program_options::value_semantic const *,char const *)" (??Roptions_description_easy_init@program_options@boost@@QEAAAEAV012@PEBDPEBVvalue_semantic@12@0@Z) already defined in boost_program_options-vc142-mt-x64-1_74.lib(boost_program_options-vc142-mt-x64-1_74.dll) [C:\Users\kimbe\Documents\Development\ROS\ros2_ws\build\crazyswarm2\deps\crazyflie_tools\battery.vcxproj]

the .lib are conflicting with the .dll in the same folder... either I'll remove one of those types from the folder itself or we tell cmake to only use dll

[knmcguire]

Success!! It finally builds!

This is what I added to the cmake so far. Might be overkill but apparently that is what is required:

set(Boost_USE_STATIC_LIBS OFF)
set(Boost_USE_MULTITHREADED ON)
set(Boost_USE_STATIC_RUNTIME OFF)
set(Boost_DEBUG ON)
unset(Boost_INCLUDE_DIR CACHE)
unset(Boost_LIBRARY_DIRS CACHE)

add_definitions(-DBOOST_ALL_NO_LIB) 
add_definitions(-DBOOST_ALL_DYN_LINK) 

find_package(Boost REQUIRED COMPONENTS program_options)

INCLUDE_DIRECTORIES(${Boost_INCLUDE_DIR})
LINK_DIRECTORIES(${Boost_LIBRARY_DIRS})

[whoenig]

Cool!!! Can it connect to a Crazyflie on Windows (e.g., ros2 run crazyswarm2 console)?

[knmcguire]

I haven't got it to work yet.... do you know how to give a ros2 nodes arguments like a uri?

[knmcguire]

It might be that it's crashing because I use the wrong usb library for crazyradio but not sure about that.

[whoenig]

Those are actually not ROS nodes, but simple executables. So ros2 run crazyswarm2 console --uri <...> should work (haven't tested that myself). Alternatively, you can also find those binaries in the install folder and run without the use of ros2 run.

[knmcguire]

ah oke. that argument works!

But the console program immediately closes. I also don't see any leds one on the crazyradio pa...

I've also installed libusb on zadig but no change. so perhaps we need more debugging for that. Let's start a new issue:)

[knmcguire]

I guess we can close this one the crazyflie tools submodule has been updated, . I made another issue about the failure of the console on windows. #5