MoffKalast / vizanti

A mission planner and visualizer for controlling outdoor ROS robots.
https://wiki.ros.org/vizanti
BSD 3-Clause "New" or "Revised" License
145 stars 30 forks source link

ROS 2 Port Finalization #27

Closed MoffKalast closed 1 year ago

MoffKalast commented 1 year ago

Checking out and fixing the final few widgets and adding some minor QoL things.

The supported MarkerArray types have more parity now. image

MoffKalast commented 1 year ago

Hey @b1n-ch1kn I've finally gotten around to restructuring the package to include the interfaces. The metapackage scheme seemed easiest, especially since we'll also have the vizanti_demos package for some test nodes. I've laid it out in a way that more or less mimics rosbridge_suite.

I had some serious trouble getting it all to compile properly for a bit but it seems to be working for me now, could you give it a go on your end to confirm? 😄

Oh and the new launch command is ros2 launch vizanti_server launch.py since the _server is the main package now.

There's still a few things to look into, especially the param setter widget, but overall this should be getting close to a first ROS 2 release.

b1n-ch1kn commented 1 year ago

Compiles and works fantastic! The improvements since I last touched it (albiet a while ago) are awesome and I'm definitely planning on using this for the majority of my 2D navigation testing. Pic below of Nav2 being used in an autonomous racing scenario with Vizanti: image

MoffKalast commented 1 year ago

Ah fantastic, I'm glad it's coming in handy. I'm still a bit concerned about overall usability since rosbridge on ROS 2 isn't yet quite up to its former speed and reliability as it was in ROS 1 (cbor compression isn't supported yet, some topic/node info calls hang sometimes and such) so there's more TCP clogging than before.

We can change it to vizanti.launch.py or vizanti_server.launch.py, I mostly trimmed that for brevity so there's no repetition in writing the command given that there's only one launch for now.

I think there is actually a bug with symlink install, in that it doesn't quite use the correct public directory since this detection I've added doesn't seem to fully work. It should at least have the python scripts as symlinks though which is better than nothing.