-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Path planner #14
base: main
Are you sure you want to change the base?
Path planner #14
Conversation
rb_ws/src/buggy/setup.py
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isn't this file required to have in a package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changed package to be C based with python as an add-on, not necessary anymore
@@ -2,23 +2,14 @@ | |||
|
|||
<node pkg="foxglove_bridge" exec="foxglove_bridge" name="foxglove" namespace="SC"/> | |||
|
|||
<node pkg="buggy" exec="sim_single" name="SC_sim_single" namespace="SC"> | |||
<node pkg="buggy" exec="engine.py" name="SC_sim_single" namespace="SC"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i thought the parameter for the exec node was the name set in setup.py... which was deleted.
is this an alternate framework? its different than how most of the docs ive read are setup, they don't use filenames here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are doing something different, similar to what was in RoboBuggy2, with CMake installation, so yeah minor changes
<version>2.0.0</version> | ||
<description>CMU's First Robotic Buggy</description> | ||
<maintainer email="officers@roboclub.com">CMU's Robotic Club Officers</maintainer> | ||
<license>MIT</license> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why are you endorsing our competitors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's just a standard liscence breh
<buildtool_depend>ament_cmake_python</buildtool_depend> | ||
|
||
|
||
<depend>rclcpp</depend> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we depend on c++ ros?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Required modification to have custom msg imports
rb_ws/src/buggy/resource/buggy
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this file be deleted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep
|
||
|
||
def main(args=None): | ||
rclpy.init(args=args) | ||
sim = Simulator() | ||
for _ in range(500): | ||
time.sleep(0.01) | ||
sim.publish() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what is this loop for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a delay timer for everything to initialize, including init check, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what were all these deleted files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unclear, seemed to be unnecessary test files that were originally auto-generated
|
||
#Publishers | ||
self.other_buggy_xtrack_publisher = self.create_publisher(Float64, "self/debug/other_buggy_xtrack", 10) | ||
self.traj_publisher = self.create_publisher(TrajectoryMsg, "self/cur_traj", 10) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we want to append "/self" to all rostopics pertaining to the buggy's own data? seem unnecessarily verbose to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fair, this should just be debug
self.self_pose_lock = Lock() | ||
self.other_pose_lock = Lock() | ||
|
||
def self_pose_callback(self, msg): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need to convert the rosposes to poses? we seem to only ever access pose.x and pose.y, which are just as easily accessible from the original buggystate. we also don't use any special pose math functions - why do we convert?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair, I will be reworking this code I guess
self.get_logger().debug("RECEIVED FROM NAND") | ||
|
||
def timer_callback(self): | ||
with self.self_pose_lock and self.other_pose_lock: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this how you do simultaneous locks? should it be with self.self_pose_lock and with self.other_pose_lock, or even just nest them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is fine, as it did compile in sim.
path_planner.destroy_node() | ||
rclpy.shutdown() | ||
|
||
if __name__ == '__main__': |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this works in sim right
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup
What type of PR is this? (check all applicable)
Description
Describe the CHANGES, the REASONING, and BENEFITS of this PR.
CHANGES - The path planner was separated from controller, new package structure, etc.
REASONING - Everything was a pain beforehand
BENEFITS - We have a working path planner
Related Tickets & Documents
QA Instructions, Screenshots, Recordings
Please replace this line with instructions on how to test your changes, a note
on the devices and browsers this has been tested on, as well as any relevant
images for UI changes.
Added/updated tests?
We encourage you to keep the code coverage percentage at 80% and above.
have not been included
[optional] Are there any post deployment tasks we need to perform?
[optional] What gif best describes this PR or how it makes you feel?