swri-robotics / marti_common Goto Github PK
View Code? Open in Web Editor NEWCommon utility functions for MARTI
License: BSD 3-Clause "New" or "Revised" License
Common utility functions for MARTI
License: BSD 3-Clause "New" or "Revised" License
The BSD license has two tags for organization. The license files do not have the second instance filled in.
The transform util functionality would be useful in Python for rapid prototyping in Python nodes.
The test nodes in swri_roscpp use std_msgs and std_srvs, but they aren't included in the package.xml or the CMakeLists.txt.
See this failing indigo build and this failing jade build.
georeference class incorrectly uses cv::Vec2s instead of cv::Vec2i
This causes images with dimensions larger than a short to fail to load.
There's a syntax error in the .travis.yml file that is preventing the build from running.
The documentation for these packages is sparse (where it exists at all) and sometimes incorrect. For example, see http://docs.ros.org/api/marti_data_structures/html/.
gps_common still hasn't been released for ROS Jade, and it looks like it's been superseded by sensor_msgs/NavSatFix ana sensor_msgs/NavSatStatus. swri_transform_util currently uses gps_common/GPSFix for the local XY origin message. We should replace these with sensor_msgs/NavSatFix or perhaps geometry_msgs/PoseStamped
All of the tests that depend on interaction with initialize_origin.py (transform_manager.test, local_xy_util.test) have potential race conditions that make the tests flaky. They seem to fail more on heavily-loaded systems (i.e. systems that are simultaneously building other code).
Use #cmakedefine when creating yaml_util/version.h to avoid unnecessarily rebuilding packages that depend on yaml_util.
When the initialize_origins node is set to auto, the current node does not set the header frame_id. The rest of the system uses this to name the local_xy frame, so many transforms currently fail.
Update earth constants
This is an outdated package that is not actively used anymore and not recommended for use.
xterm_prefix in swri_prefix_tools calls .get_children() on a psutil Process object. The name of this function has been changed to .children() in the latest version:
http://grodola.blogspot.com/2014/01/psutil-20-porting.html
Maybe other changes are required, because I made this change and the function still fails to find any children. The function terminates at:
if grandchild is None:
print "Found no running process for node. Quitting."
sys.exit(1)
FYI, I'm using swri_prefix_tools in combination with swri_nodelet, in case that's relevant.
Use format 2 of package.xml to simplify dependency declarations.
When building on Ubuntu 16.04, the swri_geometry_util
fails due to the following error:
In file included from /usr/include/geos/geom/CoordinateSequence.h:19:0,
from /usr/include/geos/geom/CoordinateArraySequence.h:21,
from /root/ros/ws_ci_src/src/ci_src/swri_geometry_util/src/intersection.cpp:34:
/usr/include/geos/platform.h:66:26: error: conflicting declaration 'typedef long long int int64'
typedef long long int int64;
^
In file included from /usr/include/opencv2/core/core.hpp:49:0,
from /root/ros/ws_ci_src/src/ci_src/swri_geometry_util/include/swri_geometry_util/intersection.h:31,
from /root/ros/ws_ci_src/src/ci_src/swri_geometry_util/src/intersection.cpp:32:
/usr/include/opencv2/core/types_c.h:163:20: note: previous declaration as 'typedef int64_t int64'
typedef int64_t int64;
^
Set the frame_id of the /local_xy_origin topic to be the TF frame representing LocalXY to remove the need for a global /local_xy_frame parameter.
This seems to be a dependency issue with catkin where marti_can_msgs does not always get built before can_util.
Remove build_tools dependency for catkin branches. Use a more catkin based approach if functionality is desired in the future.
Right now, the bloom script complains that there is no key for installing libgeos++ in fedora:heisenbug. You can just tell it to skip the generator for that distribution (and really, who's running ROS on non-Ubuntu systems?) but we should figure out what the RPM key is for that library and add it to the rosdep db.
Remove version.txt from build_tools since it is auto-generated.
Arc lengths before the start point will always be the (negative) distance between the current point and the next, instead of the cumulative distance backward from the start point.
https://github.com/swri-robotics/marti_common/blob/indigo-devel/swri_route_util/src/util.cpp#L468
https://github.com/swri-robotics/marti_common/blob/indigo-devel/swri_route_util/src/util.cpp#L483
In both cases, the code should probably look something like
arc_lengths[i] = arc_lengths[i+1] - (pt2-pt1).length();
^---change to plus
When a point is past the end of the route, swri_route_util::projectOntoRoute does not return a normalized route position coordinate.
Hello,
I try to invoke the initialize_origin.py script from my launch file as such:
<node pkg="swri_transform_util" type="initialize_origin.py" name="initialize_origin" >
<param name="local_xy_frame" value="/map"/>
<param name="local_xy_origin" value="Spata"/>
<rosparam param="local_xy_origins">
[{ name: Spata,
latitude: 37.9879772,
longitude: 23.9078602,
altitude: 129.69,
heading: 0.0}]
</rosparam>
</node>
I get the error:
ERROR: cannot launch node of type [swri_transform_util/initialize_origin.py]: can't locate node [initialize_origin.py] in package [swri_transform_util]
catkin can't see the python script as executable.
I fixed it by chmod +x
the .py script, but it's not ideal.
I noticed that you recently added an install target to the script but perhaps it doesn't work?
I have the latest version of marti_common
git pulled in my workspace.
From @pjreed:
Jade branch is failing to build due to swri_geometry_util (and possibly others) being unable to find "Eigen3".
Use set_target_properties when setting CMAKE_CXX_FLAGS since catkin allows set(CMAKE_CXX_FLAGS) to pollute the entire workspace.
debian packaging takes the highest changelog. Thus debian's buildpackage is tagging your package with 0.1.0 not 0.0.6
See the console output here: http://jenkins.ros.org/view/Isrc/job/ros-indigo-swri-roscpp_sourcedeb/41/console which means that this job is continuously triggering and rebuilding trying to get the version declared in the rosdistro.
Our nextgen buildfarm is more strict and it's failing every cycle: http://54.183.26.131:8080/view/Isrc_uT/job/Isrc_uT__swri_roscpp__ubuntu_trusty__source/73/console
local_xy_util was recently changed to read the local_xy_frame from the header of the local_xy_origin GPS message. This is the preferred way to set the origin, but is incompatible with older bag files that were recorded before the change.
A straightforward way to work around this problem is to add a global parameter /local_xy_frame that can be used to set the origin. We could either have the local_xy_frame parameter always override the local_xy_origin frame, or just use it as a fallback when the frame_id empty.
@dirk-thomas raised the objection that most of the package names in this repository are overly generic. I plan to rename all of the packages with swri_ prefixes. This change should only be applied in the indigo-devel branch.
Most ubuntu systems already have libyaml-cpp-dev installed, but the ROS docker build farm does not. See http://jenkins.ros.org/view/IbinT64/job/ros-indigo-swri-yaml-util_binarydeb_trusty_amd64/1/console
Most Ubuntu systems have boost installed already, so this one slipped through the cracks. See http://jenkins.ros.org/view/IbinT64/job/ros-indigo-swri-serial-util_binarydeb_trusty_amd64/1/console
It would be helpful to have a document outlining the guidelines for contributing to the project, both for SwRI folks and for community contributors. It would lay out things like issue tracking, branch management, and code style.
I've started work on a document for this. When I finish a draft, I'll make a PR.
The ROS Eigen CMake module is deprecated in Jade, and may be removed in K-turtle. See http://wiki.ros.org/jade/Migration
${YamlCpp_LIBRARY} should be ${YamlCpp_LIBRARIES} in which case yaml-cpp can be removed from the catkin_package() definition
This method is declared in the header without an inline qualifier, causing compiler errors when the header is included in multiple compilation units.
marti_common uses OpenCV 2 and actually does not depend on 3 at all, but having 3 installed is useful for testing the build scripts because it will cause the builds to fail if they don't explicitly depend on 2.
Remove lapackpp dependency in favor of Eigen library.
Missing opencv, yaml-cpp, and boost in package.xml
Compare these CI builds of the same commit, and you can see that our Travis CI fails and the OSRF Jenkins build passes.
This package also seems to build fine for me on Mint 17.2.
Because the path to libgeos is now /usr/lib/x86_64-linux-gnu/geos-3.5.0
, the regex to find the library name matches on a portion of the library directory, resulting in broken linker flags:
[swri_geometry_util:cmake] -- Found GEOS: inux-gnugeos-3.5.0 (version: 3.5.0, includes: /usr/include)
...
[swri_geometry_util:make] [100%] Linking CXX shared library /root/ros/ws_ci_src/devel/.private/swri_geometry_util/lib/libswri_geometry_util.so
[swri_geometry_util:make] /usr/bin/cmake -E cmake_link_script CMakeFiles/swri_geometry_util.dir/link.txt --verbose=1
[swri_geometry_util:make] /usr/bin/c++ -fPIC -shared -Wl,-soname,libswri_geometry_util.so -o /root/ros/ws_ci_src/devel/.private/swri_geometry_util/lib/libswri_geometry_util.so CMakeFiles/swri_geometry_util.dir/src/intersection.cpp.o CMakeFiles/swri_geometry_util.dir/src/polygon.cpp.o CMakeFiles/swri_geometry_util.dir/src/geometry_util.cpp.o CMakeFiles/swri_geometry_util.dir/src/cubic_spline.cpp.o /opt/ros/kinetic/lib/libtf.so /opt/ros/kinetic/lib/libtf2_ros.so /opt/ros/kinetic/lib/libactionlib.so /opt/ros/kinetic/lib/libmessage_filters.so /opt/ros/kinetic/lib/libroscpp.so -lboost_signals -lboost_filesystem /opt/ros/kinetic/lib/libxmlrpcpp.so /opt/ros/kinetic/lib/libtf2.so /opt/ros/kinetic/lib/libroscpp_serialization.so /opt/ros/kinetic/lib/librosconsole.so /opt/ros/kinetic/lib/librosconsole_log4cxx.so /opt/ros/kinetic/lib/librosconsole_backend_interface.so -llog4cxx -lboost_regex -lboost_chrono -lboost_atomic /opt/ros/kinetic/lib/librostime.so -lboost_date_time /opt/ros/kinetic/lib/libcpp_common.so -lboost_system -lboost_thread -lpthread -lconsole_bridge /usr/lib/x86_64-linux-gnu/libopencv_videostab.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_superres.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_stitching.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_ocl.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_gpu.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_contrib.so.2.4.9 -linux-gnugeos-3.5.0 /usr/lib/x86_64-linux-gnu/libopencv_photo.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_legacy.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_video.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_objdetect.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_ml.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_calib3d.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_features2d.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_highgui.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_imgproc.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_flann.so.2.4.9 /usr/lib/x86_64-linux-gnu/libopencv_core.so.2.4.9 -Wl,-rpath,/opt/ros/kinetic/lib:
[swri_geometry_util:make] /usr/bin/ld: cannot find -linux-gnugeos-3.5.0
The prefix scripts need to be installed to the CATKIN_PACKAGE_SHARE_DESTINATION so they can be used from an installed package.
swri_transfrom_util initializat_origin.py needs to be updated for this.
The master branch fails to build on Ubuntu 14.04 due to Boost filesystem version
yaml-cpp uses boost header files, but it seems that it doesn't export the boost headers in its include files. This causes compilation of swri_yaml_util to fail (see http://jenkins.ros.org/view/IbinT64/job/ros-indigo-swri-yaml-util_binarydeb_trusty_amd64/3/console).
Adding boost to as a direct dependency of this package is technically wrong, but should solve the problem.
When converting from /utm coordinates in the southern hemisphere, quaternions are not being transformed correctly.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.