RobWork issueshttps://gitlab.com/sdurobotics/RobWork/-/issues2023-04-13T09:07:27Zhttps://gitlab.com/sdurobotics/RobWork/-/issues/108Include paths to rwyaobi set incorrectly after ppa install2023-04-13T09:07:27ZGudmundur SerpinaInclude paths to rwyaobi set incorrectly after ppa installRobwork seems to export the path
`
"/usr/share/robwork-2.4/cmake/../../../include/robwork-2.4/ext/rwyaobi/include"
`
for the rwyaobi header files after a ppa install. This folder does not exist, currently the include files are placed i...Robwork seems to export the path
`
"/usr/share/robwork-2.4/cmake/../../../include/robwork-2.4/ext/rwyaobi/include"
`
for the rwyaobi header files after a ppa install. This folder does not exist, currently the include files are placed in
`
"/usr/share/robwork-2.4/cmake/../../../include/robwork-2.4/ext/rwyaobi"
`Kasper Høj Lorenzenkalor@mmmi.sdu.dkKasper Høj Lorenzenkalor@mmmi.sdu.dkhttps://gitlab.com/sdurobotics/RobWork/-/issues/107Using Robwork when installed from ppa does not work2022-01-24T08:21:31ZGudmundur SerpinaUsing Robwork when installed from ppa does not workWhen using finding robwork in cmake after installing from ppa (apt install libsdurw-all-dev) I get the following error:
![error_message](/uploads/c1f3f1bd3a93cc20efdb627504996f11/error_message.png)
Contents of CMakeLists.txt:
```
cmake...When using finding robwork in cmake after installing from ppa (apt install libsdurw-all-dev) I get the following error:
![error_message](/uploads/c1f3f1bd3a93cc20efdb627504996f11/error_message.png)
Contents of CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.10 FATAL_ERROR)
project(rw_test)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED True)
find_package(RobWork REQUIRED)
include_directories(${ROBWORK_INCLUDE_DIRS})
add_executable(${PROJECT_NAME} main.cpp)
target_link_libraries(${PROJECT_NAME} ${ROBWORK_LIBRARIES})
```
Contents of main.cpp:
```
#include <rw/core/Ptr.hpp>
#include <vector>
#include <iostream>
int main() {
auto ptr = rw::core::ownedPtr(new std::vector<int>{1, 2, 3});
std::cout << (*ptr)[1] << std::endl;
return 0;
}
```
This can be reproduced by running a fresh docker container of ubuntu 18.04 and installing robwork via ppa. The error does not happen if RobWork is compiled from source.Kasper Høj Lorenzenkalor@mmmi.sdu.dkKasper Høj Lorenzenkalor@mmmi.sdu.dkhttps://gitlab.com/sdurobotics/RobWork/-/issues/102Segfault when saving an .xml without close tag2021-08-23T12:25:59ZTroels Blicher PetersenSegfault when saving an .xml without close tagI have a habit of saving every small change I do, even if they may not be "correct". In RobWorkStudio I did the same, when editing an xml in the program. Then it crashed and gave me the following error:
```
<WorkCell name="RobotModellin...I have a habit of saving every small change I do, even if they may not be "correct". In RobWorkStudio I did the same, when editing an xml in the program. Then it crashed and gave me the following error:
```
<WorkCell name="RobotModellingScene"
Error occoured in parsing element: WorkCell
Expected '/>' or '>' in start element
Aborted (core dumped)
```
which to me clearly tells, that I should be 100% sure that my syntax is correct before I save, or I might lose a lot of work.Kasper Høj Lorenzenkalor@mmmi.sdu.dkKasper Høj Lorenzenkalor@mmmi.sdu.dkhttps://gitlab.com/sdurobotics/RobWork/-/issues/100Workcell loader crashes when loading a workcell with empty SerialDevice tag2021-04-29T13:37:29ZAdam WolniakowskiWorkcell loader crashes when loading a workcell with empty SerialDevice tagCreating the following workcell crashes the application instead of giving an error message:
<WorkCell name="">
<SerialDevice name="aaa">
</SerialDevice>
</WorkCell>
The issue seems to be in parsing the SerialDevice tag.Creating the following workcell crashes the application instead of giving an error message:
<WorkCell name="">
<SerialDevice name="aaa">
</SerialDevice>
</WorkCell>
The issue seems to be in parsing the SerialDevice tag.Kasper Høj Lorenzenkalor@mmmi.sdu.dkKasper Høj Lorenzenkalor@mmmi.sdu.dkhttps://gitlab.com/sdurobotics/RobWork/-/issues/99Header file rwlibs/os/rwgl.hpp is missing in the RobWork package release2021-04-21T07:40:12ZAdam WolniakowskiHeader file rwlibs/os/rwgl.hpp is missing in the RobWork package releaseHeader file rwlibs/os/rwgl.hpp (included e.g. in rwlibs/opengl/DrawableUtil.hpp) seems to be missing in RobWork installed from the packages.
RobWork installed on Ubuntu 18.04.5.
Package version: bionic 1.2.11-4 amd64Header file rwlibs/os/rwgl.hpp (included e.g. in rwlibs/opengl/DrawableUtil.hpp) seems to be missing in RobWork installed from the packages.
RobWork installed on Ubuntu 18.04.5.
Package version: bionic 1.2.11-4 amd64Kasper Høj Lorenzenkalor@mmmi.sdu.dkKasper Høj Lorenzenkalor@mmmi.sdu.dkhttps://gitlab.com/sdurobotics/RobWork/-/issues/98Workcell editor uses "," when denominating decimal numbers and not "." which ...2021-04-21T07:40:14ZKasper Høj Lorenzenkalor@mmmi.sdu.dkWorkcell editor uses "," when denominating decimal numbers and not "." which is otherwise the standardWorkcell editor uses "," when denominating decimal numbers and not "." which is otherwise the standardWorkcell editor uses "," when denominating decimal numbers and not "." which is otherwise the standardhttps://gitlab.com/sdurobotics/RobWork/-/issues/97Workcell editor can't select .ac files when making a new drawable2021-04-21T07:40:16ZKasper Høj Lorenzenkalor@mmmi.sdu.dkWorkcell editor can't select .ac files when making a new drawableWhen opening the workcell editor in RobWorkStudio you can't select a .ac file using the CAD selector under add drawableWhen opening the workcell editor in RobWorkStudio you can't select a .ac file using the CAD selector under add drawablehttps://gitlab.com/sdurobotics/RobWork/-/issues/94The robwork studio camera, appears to get lost sometimes and the fixed perspe...2021-04-21T07:40:22ZDaniel HaraldsonThe robwork studio camera, appears to get lost sometimes and the fixed perspective tool buttons don't appear to bring it back to homeKasper Høj Lorenzenkalor@mmmi.sdu.dkKasper Høj Lorenzenkalor@mmmi.sdu.dkhttps://gitlab.com/sdurobotics/RobWork/-/issues/78The transparent function does not handle multiple objects2020-04-21T08:56:09ZDaniel HaraldsonThe transparent function does not handle multiple objectsIt would appear that the transparent function can't handle multiple objects, meaning that when one part covers the other then the second part disappears. It would be nice if one could see what lies behind objects using the transparent fu...It would appear that the transparent function can't handle multiple objects, meaning that when one part covers the other then the second part disappears. It would be nice if one could see what lies behind objects using the transparent function, so i am assuming that it failing to do that is do to some bug.
Best regards
Daniel
![trans1](/uploads/8f75d2f643ba99b962b26317ca6c03fe/trans1.png)
![trans2](/uploads/e152998d584b5f3edc474c959a117a53/trans2.png)
![trans3](/uploads/eb6ce1b7d5bfeab96692c9b37d11b4c4/trans3.png)
![trans4](/uploads/034e8a6607cdb265cba2572584414e9b/trans4.png)
![trans4_1](/uploads/46f9fff15e5f42d2cf185e39c68721d5/trans4_1.png)https://gitlab.com/sdurobotics/RobWork/-/issues/76Reloading Workcell Bug2020-01-23T10:00:09ZDaniel HaraldsonReloading Workcell BugIt has come to my attention that when one tries to reload a workcell in RobWorkstudio where one of the models in that workcell has changed shape, then it updates the model that gets rendered, but not the collision detector.
This is also...It has come to my attention that when one tries to reload a workcell in RobWorkstudio where one of the models in that workcell has changed shape, then it updates the model that gets rendered, but not the collision detector.
This is also the case when loading and reloading a workcell in c++ using the command DynamicWorkCellLoader::load. It was found that this issue could be avoid by using clearGeometryCache in advance. An example of the code can be seen bellow
rw::loaders::GeometryFactory::clearGeometryCache(); // This is to make sure that nothing from the old scene remains
dwc = DynamicWorkCellLoader::load(pathToRootFolder+"sceneFiles/tracks/" + subFolder + "/" + wcName+".dwc.xml");
It would therefore be nice if the collision detector gets updated as well.Kasper Høj Lorenzenkalor@mmmi.sdu.dkKasper Høj Lorenzenkalor@mmmi.sdu.dkhttps://gitlab.com/sdurobotics/RobWork/-/issues/71RWS playback plugin, "Record images to file" broken2019-09-23T12:36:39ZMichael K. SchmidtRWS playback plugin, "Record images to file" brokenWhen using the "Record images to file" option under the playback plugin, something goes wrong when saving the images. The motion goes back and forth, and some frames "skip".
Video example attached, as well as the workcell and .rwplay f...When using the "Record images to file" option under the playback plugin, something goes wrong when saving the images. The motion goes back and forth, and some frames "skip".
Video example attached, as well as the workcell and .rwplay file needed. ![output](/uploads/37412fe19ab79aa53a8d74d4d13d15eb/output.mp4)
Debug files:
[debugfiles.zip](/uploads/cfdc9075ce05008cdb564a38cdca39d9/debugfiles.zip)https://gitlab.com/sdurobotics/RobWork/-/issues/61RobWork Crashes when opening playback files larger then 300 Mb2019-09-23T12:36:28ZDaniel HaraldsonRobWork Crashes when opening playback files larger then 300 MbI am working with large playback files and when ever the file size exeedes the 300 Mb ish mark, it stalls for a couple of seconds and then it crashes.I am working with large playback files and when ever the file size exeedes the 300 Mb ish mark, it stalls for a couple of seconds and then it crashes.https://gitlab.com/sdurobotics/RobWork/-/issues/40geometry/TriDistanceCalc is included in the build even though PQP is disabled2017-05-10T13:15:46ZThor Stenvanggeometry/TriDistanceCalc is included in the build even though PQP is disabledgeometry/TriDistanceCalc is dependent on PQP and it is still included when disabling the external package PQP in the config.cmake file using `SET(RW_DISABLE_PQP ON)`
Consider adding below code in the /RobWork/src/rw/geometry/CMakeLists....geometry/TriDistanceCalc is dependent on PQP and it is still included when disabling the external package PQP in the config.cmake file using `SET(RW_DISABLE_PQP ON)`
Consider adding below code in the /RobWork/src/rw/geometry/CMakeLists.txt
```cmake
IF (RW_HAVE_PQP)
set(FILES_CPP ${FILES_CPP}
TriDistanceCalc.cpp
TriTriToleranceIntersect.cpp
)
set(FILES_HPP ${FILES_HPP}
TriDistanceCalc.hpp
TriTriToleranceIntersect.hpp
)
ENDIF()
```Thomas Nicky Thulesentnt@enabled-robotics.comThomas Nicky Thulesentnt@enabled-robotics.com2017-05-10https://gitlab.com/sdurobotics/RobWork/-/issues/37Qt 5.8 moc fails on Windows.2020-02-11T13:38:31ZThomas Nicky Thulesentnt@enabled-robotics.comQt 5.8 moc fails on Windows.When Qt 5.8 is used on Windows, the moc operation fails with "undefined interface" error. With 5.7.1 there is no problem. See the following for more details:
- https://bugreports.qt.io/browse/QTBUG-59460
- https://sdur-6.sandbox.tek.sdu...When Qt 5.8 is used on Windows, the moc operation fails with "undefined interface" error. With 5.7.1 there is no problem. See the following for more details:
- https://bugreports.qt.io/browse/QTBUG-59460
- https://sdur-6.sandbox.tek.sdu.dk:8083/job/Windows/job/RobWorkStudio/176
Lars-Peter mentions that this error might not occur when CMakes automoc feature is used. We might consider switching to that, depending on how this is supported in the older versions we are using. Otherwise, there probably is no good solution. Users should skip Qt 5.8 on Windows and wait for a newer version, where this issue is likely fixed.https://gitlab.com/sdurobotics/RobWork/-/issues/32Geometry modification of dwc in RWStudio causing geometry duplicates2018-05-05T13:39:29ZLukas SchwartzGeometry modification of dwc in RWStudio causing geometry duplicatesDuplicates of the geometries in a scene are duplicated when Bodies are added/removed in a dwc in RWStudio.
This seems to only be a problem when modifying the dwc after loading it into RWStudio, but not if the dwc is modified (with exact ...Duplicates of the geometries in a scene are duplicated when Bodies are added/removed in a dwc in RWStudio.
This seems to only be a problem when modifying the dwc after loading it into RWStudio, but not if the dwc is modified (with exact same code) in the generic event listener for "DynamicWorkCellLoaded".
**Examples:**
1)
When having opened a dwc in RWStudio and inspecting the tree view.
Then modification of the geometry of body X by first removing it from the wc and then adding the new through the workcell commands "removeObject" and "add".
This then in the tree view create duplicates of other objects in the workcell and the object in the workcell previously called remove on, does still exist together with the one newly added.
2)
Using same approach, but rwsim::dynamics::Body::setObject(obj) instead to modify the geometry with a completely new created does not change the geometry (no apparent effect).Michael K. SchmidtMichael K. Schmidt2017-06-08https://gitlab.com/sdurobotics/RobWork/-/issues/22RobWorkStudio not building with Qt4 on Ubuntu 16.042017-05-05T16:20:21ZMichael Bejer-AndersenRobWorkStudio not building with Qt4 on Ubuntu 16.04Currently the buildsystem defaults to use Qt4 unless Qt5 has been explicitly specified. This should be changed to default to Qt5, or somehow figure out whether to use Qt5 or Qt4.
The current "workaround" is to specify that Qt5 should ...Currently the buildsystem defaults to use Qt4 unless Qt5 has been explicitly specified. This should be changed to default to Qt5, or somehow figure out whether to use Qt5 or Qt4.
The current "workaround" is to specify that Qt5 should be used: ```-DRWS_USE_QT5=ON```Thomas Nicky Thulesentnt@enabled-robotics.comThomas Nicky Thulesentnt@enabled-robotics.com2016-08-31https://gitlab.com/sdurobotics/RobWork/-/issues/15RANSAC test broken2017-05-05T16:20:22ZThomas Nicky Thulesentnt@enabled-robotics.comRANSAC test brokenThe RANSAC test is broken (and has most likely always been broken). Previously I got it running using lucky random seeds, which is a bit of a hack.
As the normal distribution is different in new boost versions, the test is now failing o...The RANSAC test is broken (and has most likely always been broken). Previously I got it running using lucky random seeds, which is a bit of a hack.
As the normal distribution is different in new boost versions, the test is now failing on Windows. Until someone fixes the test, I have disabled it in revision 6033.https://gitlab.com/sdurobotics/RobWork/-/issues/11Building on Ubuntu 16.042017-05-05T16:20:22ZMichael Bejer-AndersenBuilding on Ubuntu 16.04# The Issue (as of revision 5955)
The linking is causing undefined references, e.g. from linking RobWork/bin/debug/rw_calibration-verification-tool:
```
[ 87%] Linking CXX executable /home/jenkins/robwork_trunk/RobWork/bin/debug/rw_ca...# The Issue (as of revision 5955)
The linking is causing undefined references, e.g. from linking RobWork/bin/debug/rw_calibration-verification-tool:
```
[ 87%] Linking CXX executable /home/jenkins/robwork_trunk/RobWork/bin/debug/rw_calibration-verification-tool
cd /home/jenkins/build-RobWork/tools/calibration && /usr/bin/cmake -E cmake_link_script CMakeFiles/rw_calibration-verification-tool.dir/link.txt --verbose=1
/usr/bin/c++ -g CMakeFiles/rw_calibration-verification-tool.dir/CalibrationVerificationTool.cpp.o -o /home/jenkins/robwork_trunk/RobWork/bin/debug/rw_calibration-verification-tool -L/home/jenkins/build-RobWork/imported-gtest -L/home/jenkins/robwork_trunk/RobWork/libs/debug -rdynamic /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_algorithms.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_pathplanners.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_pathoptimization.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_simulation.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_opengl.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_assembly.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_task.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_calibration.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_csg.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_lua_s.a -llua5.1 -lm /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_proximitystrategies.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/libyaobi.a /home/jenkins/robwork_trunk/RobWork/libs/debug/libpqp.a -lGLU -lGL -lxerces-c -lassimp -lboost_filesystem -lboost_regex -lboost_serialization -lboost_system -lboost_thread -lboost_program_options -lboost_chrono -lboost_date_time -lboost_atomic -lpthread -Wl,-Bstatic -lboost_test_exec_monitor -Wl,-Bdynamic -lboost_unit_test_framework -lqhull /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_csgjs.a -ldl /home/jenkins/robwork_trunk/RobWork/libs/debug/librw_control.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0 -lboost_filesystem -lboost_regex -lboost_serialization -lboost_system -lboost_thread -lboost_program_options -lboost_chrono -lboost_date_time -lboost_atomic -lpthread -Wl,-Bstatic -lboost_test_exec_monitor -Wl,-Bdynamic -lboost_unit_test_framework -Wl,-rpath,/home/jenkins/build-RobWork/imported-gtest:/home/jenkins/robwork_trunk/RobWork/libs/debug
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_save_qhull'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `Assimp::DefaultLogger::create(char const*, Assimp::Logger::LogSeverity, unsigned int, Assimp::IOSystem*)'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `Assimp::Importer::~Importer()'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `Assimp::Importer::ReadFile(char const*, unsigned int)'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_memfreeshort'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `Assimp::Logger::info(char const*)'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_check_points'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `Assimp::Importer::Importer()'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_restore_qhull'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_setsize'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `aiGetMaterialColor'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `Assimp::DefaultLogger::get()'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_new_qhull'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_qh'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_freeqhull'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_pointid'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `aiGetMaterialFloatArray'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `Assimp::Importer::GetErrorString() const'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `aiGetMaterialString'
/home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0: undefined reference to `qh_init_A'
collect2: error: ld returned 1 exit status
tools/calibration/CMakeFiles/rw_calibration-verification-tool.dir/build.make:142: recipe for target '/home/jenkins/robwork_trunk/RobWork/bin/debug/rw_calibration-verification-tool' failed
make[2]: *** [/home/jenkins/robwork_trunk/RobWork/bin/debug/rw_calibration-verification-tool] Error 1
```
This is because the order of linking is wrong, and I can't seem to find out why it is wrong on Ubuntu 16.04. The linking with ```/home/jenkins/robwork_trunk/RobWork/libs/debug/librw_control.so.0.7.0 /home/jenkins/robwork_trunk/RobWork/libs/debug/librw.so.0.7.0``` is happening after linking with assimp and qhull, but on Ubuntu 14.04 they are correctly being linked with before assimp and qhull.
# Workaround
It is possible to have it link properly, if you invoke cmake a second time after the initial linking issue above has appeared (doesn't work if you just invoke cmake twice before building anything at all).
# Notes
I have tried to modify the ordering of the robwork libraries that are being linked with, and looked around for any cause/reason to why it decides to order it the way it does. But I can't find the cause of this problem.https://gitlab.com/sdurobotics/RobWork/-/issues/5Inconsistency between building of static and shared libraries.2018-05-05T13:39:29ZThomas Nicky Thulesentnt@enabled-robotics.comInconsistency between building of static and shared libraries.For the first build of RobWork, static libraries are built. If cmake is run again, shared libraries are built (causing a recompilation of the entire project).
Previously I have experienced a similar issue in RobWorkSim where the config....For the first build of RobWork, static libraries are built. If cmake is run again, shared libraries are built (causing a recompilation of the entire project).
Previously I have experienced a similar issue in RobWorkSim where the config.cmake.template overrules options from the second run of cmake and onwards.
The RW_INIT_PROJECT macro will load the config.cmake.template file, which specifies:
```cmake
SET(PROJECT_SHARED_LIBS ON)
```
After this, the RW_OPTIONS macro is called, and sets shared libraries to OFF initially:
```cmake
option(PROJECT_SHARED_LIBS "Build shared libraries." OFF)
```
I think that this is what happens:
- For the first run: the variable is set to ON and afterwards overwritten by the option statement, which sets it to OFF adds an entry to the CMake cache.
- For the second run: the variable is OFF initially, but is overwritten by the set statement. The option statement has no effect, as it is a value read from the cache.
# A Fix
In RobWorkMacros.cmake the default option can just be set to ON. This will, however, not change the fact that config.cmake.template will always overrule the CMakeCache. This is ugly in my opinion.
It is unfortunate that default parameters can be specified multiple places. Especially when these are often inconsistent. Maybe the .template file should not even be used.Thomas Nicky Thulesentnt@enabled-robotics.comThomas Nicky Thulesentnt@enabled-robotics.comhttps://gitlab.com/sdurobotics/RobWork/-/issues/4RobWorkSim buildsystem fails to properly handle situation with Bullet install...2018-05-05T13:39:29ZMichael Bejer-AndersenRobWorkSim buildsystem fails to properly handle situation with Bullet installed but not explicitly enabledSee https://tek-marvin-6.sandbox.tek.sdu.dk:8083/job/robwork-defaults/56/console for more information, but basically it is
```
-- RobWorkSim: Bullet enabled and found.
-- BUILD_rwsim_bullet OFF : Disabled by default.
```
And then:
...See https://tek-marvin-6.sandbox.tek.sdu.dk:8083/job/robwork-defaults/56/console for more information, but basically it is
```
-- RobWorkSim: Bullet enabled and found.
-- BUILD_rwsim_bullet OFF : Disabled by default.
```
And then:
```
/usr/bin/ld: cannot find -lrwsim_bullet
collect2: error: ld returned 1 exit status
```
Because it tries to link with RobWorkSim bullet things, that is didn't build for some reason (which is the issue)
The solution should fit the following:
1. The RobWorkSim Bullet things should be compiled by default when Bullet is found.
2. If the user explicitly disables bullet, then it shouldn't be built (nor linked with).
Thomas Nicky Thulesentnt@enabled-robotics.comThomas Nicky Thulesentnt@enabled-robotics.com