ubc-snowbots / snowflake Goto Github PK

• Currently, almost all nodes have and use ros::NodeHandle public_nh("~"). The problem is that the ros::NodeHandle handle_name("~") declares a nodehandle in the private namespace.
• This can cause issues, as declaring a publisher (for example called MY_PUBLISHER) under the "public namespace" will actually create it under NODE_NAME/MY_PUBLISHER which is incorrect.
• Basically, (almost) all nodes need to have public_nh changed to private_nh
• This should just be a simple matter of using the built in refactor functionality in clion

We've not been able to get the IBEO lux running for a few years. Try and get it running! Ask gareth for more details.

Gazebo does not know where to find the world files. So add it in the environment. (in .bashrc).
Best to do this by amending the get_started.sh script

export GAZEBO_MODEL_PATH=/home/path/to/IGVC-2017/src/sb_gazebo/models:${GAZEBO_MODEL_PATH}
export GAZEBO_PLUGIN_PATH=/home/path/to/IGVC-2017/src/sb_gazebo/lib:${GAZEBO_PLUGIN_PATH}
export GAZEBO_RESOURCE_PATH=/home/path/to/IGVC-2017/src/sb_gazebo/models:${GAZEBO_RESOURCE_PATH}

Depends on: #82

• Currently, to properly try and retrieve a param, we need an if statement and then a warn message if we can't retrieve it.
• This is a bit tedious and repetitive, and can be far more easily by just calling the SB_getParam function from the sb_util library.
• You will first need to link the library to each of the executables that you want to use this function in (for an example, see the ros_vision executable in the vision package). To do this, add ${sb_utils_LIBRARIES} to the target_link_libraries statement for each node you want to to use the library in
• You will also have to #include <sb_utils.h> in the header of each node you want to add this to

Whenever I try to use this, on sudo apt-get install -y python-catkin-pkg python-rosdep python-wstool ros-$ROS_DISTRO-catkin" I get E: Unable to locate package ros-kinetic-catkin and the corresponding Travis-CI error The command "sudo apt-get install -y python-catkin-pkg python-rosdep python-wstool ros-$ROS_DISTRO-catkin" failed and exited with 100 during .. Any thoughts on what might be going wrong? I tried replacing the commands with those from the kinetic wiki but got the same error

• The readme needs a link to somewhere that people can read up on launch files
• Should be under launch file section created in #71 (and so depends on #71 to be merged first or add it to the rostest_example branch)

• Make a launch file that you can pass a robot and world name to, and it will launch the given world with the given robot
• It should also check (if this is even possible) if all the required files are present, and throw appropriate errors if not

Currently, when you launch gazebo, you have to manually pick up and drop the robot before it will move properly. We probably shouldn't have to do this.....

A quick search reveals this may be a good place to start: https://coderwall.com/p/fy05hq/how-to-make-beautiful-github-readme#team-members

We've just received our brand spanking new IMU! It's pretty cool, lots of pretty accurate data, and all in a neat little package. However, it still needs to be calibrated. Calibration instructions can be found here (under the indigo section). The determined values should be written to our copy of the firmware file in src/firmware/razor_imu_9dof, as per the calibration instructions.

Current, we are only able to run rostest's via the rostest command line tool and via catkin_make run_tests. We can run gtest's from CLion, and it would be really nice if we had the ability to run rostest's from there as well.

TLDR: give clion the ability to run rostest's like gtest's

Add a .launch file that will run my_node with specified parameters:
suggestions:

• Param of how many "!" are appended to input string
• remap of topics
• launching more than one instance of one node with different topics

After #71 is merged, and #70 is closed

• Currently, we decide to merge two lidar obstacles into the same one if the minimum difference in angle between them is below some threshold.
• We should also be considering how far away two objects are when we decide to merge them. The objects may appear to be right beside each other, but one may be 20m away, and another 3m away. We probably don't want to merge these two objects

• Current one is a bit of a hacky mess in bash
• Does not need to be bash, other frameworks/programs are totally an option as well
• Needs to add things to .bashrc and install programs, via apt-get for stuff like ROS, and by manually wget'ing and install other packages, such as Clion

• Add a message if a param is retreived succesfully to both implementations of SB_getParam.
• The message should contain the value that was set (pretty similar to the "not set, defaulting to" message)
• Note that this is going to break things..... just do it and you'll see

• Should explain roughly how the launch file system works
• Should have a list of files you will need to change, and sample files (or references to already made files) for each of the files you will need to implement

• Currently is just sin(the angle of the obstacle relative to the robot) * (1/the distance of the obstacle from the robot)
• is in src/decision/LidarObstacle.cpp

Since we're gonna work a lot on the nice new Snowbots laptop, it's nice if there's a way to share files easily without needing to be logged into an account. Gareth suggests setting up a network drive, open for suggestions.

• Should be in main README

Make all default x and y values relative to width and height.

There is an ROS_WARN being thrown when the tests are run, namely:

[ERROR] [1487482866.179100462]: Given odd length list of waypoints, check that "waypoints" parameter has an (numerically) even length. As this is a series of lat/lon coordinates,it should always be even

This is an expected error, originating from the fact that the test causing it is actually testing an odd number of points. This error is causing warnings in the tests, and so should somehow be removed, or modified so that it indicates that it is acceptable for this to fail in testing (ie. add [t is acceptable for this to fail in testing] to the end of it, or something like that)

Testing section should be amended or created to basically just point the reader at the sample package rostest stuff for an example of how to use setup functions with gtest.

Right now we're using a script (install_dependencies)to manually install all dependencies, but CI uses a different (and much better system) where it finds all the requirements from the package.xml files (fairly sure it's rosdep, or something like that anyhow). We should look at what CI is doing (script is located here) and change install_dependencies to just use the same commands that CI does (although it should be kept separate from getting_started to make it easier for people to update all their dependencies after they've setup the repo for the first time

• an example of getting params can be found here: https://github.com/UBC-Snowbots/Snowflake/blob/master/src/decision/src/gps_decision/gps_decision.cpp
• Just a simple example should do, perhaps replacing the character that is added to the end of the string?

In the vision stack (currently the ros_vision node) if the node does not receive any camera input, then no windows will open up (normally there is one for raw camera, one for filtered camera, one with IPM, and the final image). The windows should still pop up, but display a message saying something like "No camera input". Alternatively (and much more simply) a ROS_WARN message could be added to the node with a similar warning.

Right now the params are being saved to a file in a mildly sketchy location. They should be saved on the param server. For more details ask @ValRat

Currently, gps_decision requires the current heading in the same frame of reference as the "current_location" and "current_waypoint" (origin is starting location, 0 degree heading is starting heading). As such, you need to output the current relative compass heading on a new topic (probably "gps_manager/heading")

On initialise (of the sample programs) the ZED looks for a calibration file online but it can't download it through the terminal. Going to the link it provides, the file can be downloaded through a browser. Maybe try to figure out why it can't get the files through the terminal.
But we can download the file and set the calibration manually for a simple fix.

• The Arduino firmware for the GPS is complete and working, but we need a ROS node to interface with it.
• The node would need to get the gps readings sent by an arduino running firmware/gps_firmware/gps_firmware.ino.
• This means also checking for "no signal" (or whatever the equivelent is that the gps firmware sends) and not publishing a ROS message in this case (or some other sort of indication that we do not have a signal, perhaps a boolean on a separate topic).

• Friction coefficient for both wheels and the ground plane are off (friction for both the wheel models and the joints)
• Damping values for the caster wheels are off

Porting over vision #17

Currently, there is a lot of repeated code in the CMakeLists.txt files. Things like targeting_link_libraries reference the same thing, and could probably be written a bit better if there were some sort of for loop where you added your node and everything you needed was just linked in automatically.

This will likely require a fair amount of CMake knowledge, a good place to start might be to get @fhackett to take a look at the problem and make some suggestions given his CMake expertise.

• currently our IPM (inverse prespective mapping) and HSV filters are in a node/class called ros_vision
• this is not a very good name. Yes we use ros, and yes it does have to do with vision, but we should probably rename it to something more reflective of what it actually does
• a suggestion could be ipm_and_hsv_filter
• this will likely require a change in at minimum: the CMakeLists.txt, the class name in .cpp and .h files for ros_vision, the names of aforementioned .cpp and .h files, the topics that other nodes are subscribing to that are under the ros vision namespace (ie. /ros_vision/something), launch files...

Just a reminder to do this sometime in the future:
Add the package dependency ros-kinetic-grid-map && laser_geometry to both the setup script and the CI script if applicable so that project compiles for everyone once #52 gets merged in.

Currently, every project has a cmake file generated by catkin_create_pkg, which have many useful comments, but there's no need for them to be in every cmake file. All comments should be retained in the sample_package project, but all other projects can have their CMake files cleared of most explanatory comments (unless they are specific to the project or otherwise make things significantly clearer)

• Should have an explanation of how to add new tests to nodes, both for nodes that already have rostest setup, and those that do not

Currently, SB_changeVectorOrientation is fairly slow, largely because we're translating everything from geometry_msgs to tf, and back again. We can probably do this faster if we just do the math ourselves, instead of relying on the tf package to do it for us. Code is in src/sb_utils/src/sb_utils.cpp

Note: This code has not been merged yet. Ask Gareth for details

• Once a name for the new robot has been decided on, all instances of "oaken" in sb_gazebo project should be changed to the new name, or some abbreviation of it (if it's too long)
  Update:
• The new robot name is "Jack Frost", a nice abbreviation might be "jfrost"
• Changing the name should just be a simple matter of search and replace in the folder, current name is "oaken", so just replace all instances of that

• Add rostest to the sample_package with a couple of really basic demo tests to help get people up and running

This issue will likely be split off into multiple issues later on, as we decide on how to split up projects

• Full mapping with the grid_map library
• (Tentatively) separate layers for vision and lidar
• Possibly discrete obstacle detection for cones since we know how big they are? Most of the code is in the decision->LidarObstacle class, and the rest is either trivial, or needs to be moved from the LidarDecision class to the LidarObstacle class

• See vision project for an example

• In CMake, need to:

• find_package(sb_utils REQUIRED)

• add ${sb_utils_INCLUDE_DIRS} to include_directories

• add <build_depend>sb_utils</build_depend> and <run_depend>sb_utils</run_depend> to package.xml

• full localisation integrating IMU, Lidar, Encoders
• will likely be implemented with some sort of Kalman Filter (either extended or unscented) though research into this still needs to be done
• After some basic research, it looks like there are several ROS packages that do what we need, so this is likely a 1 person job