Best Practices
Zachary Goldston edited this page Aug 29, 2022
·
9 revisions
- Always represent pose with the
SE3type from our library for internal states - Function signatures that require a pose should always have an SE3, this creates a unified interface for our libraries. Functions can internally unpack SE3 into the necessary forms for work
- It is worth noting that there is a semantic difference between the word "pose" and "transform", but they are mathematically related by the same object - an SE3. One could have the pose of an object in the world frame, which when thought of or applied as a transform is the transform from the object's frame to the world. For this reason, unlike the ROS messages, we have a single type for poses and transforms.
- Because of the fact that we do not distinguish between poses and transforms with the type, it is critical to follow a consistent naming convention to make it clear what a particular instance of
SE3actually encodes. If you have a transform, name your variable like{frameA}to{frameB}. If you have a pose, name your variable{frameA}in{frameB}. Make sure to following the naming conventions of the language you are using. Here are some examples:
Rover's pose in the world for python:
rover_in_world = SE3(...)
Transformation from camera frame to rover base frame in C++
SE3 cameraToBase(...)
- Use
ROS_INFO,ROS_WARN,ROS_ERRORetc. to print information to console for roscpp. - Use
rospy.loginfo,rospy.logwarn,rospy.logerretc. to print information to console for rospy.
- Keep logic associated with objects as much as possible. Sometimes this means making use of
@classmethodor@staticmethod. Do not write stuff likeutils.pywith completely random helper functions. - Classes that are essentially data storage containers should be
@dataclass. In general prefer to make classes data storage containers and do complex initialization logic with static factory methods instead of relying on__init__
If you are making a change/working on a ticket, please do NOT fork the mrover-ros repository. Merging in forked commits can lead to history rewriting and a lot of headaches when trying to clean up or revert any potential issues. Instead, as described in the workflow tutorials, checkout a new branch, and use the format <initials or github username>/<feature or change name> when naming the branch. Doing this method will make merging in changes from main easier, and avoid rebasing.