Open francocipollone opened 2 years ago
Probably we could try to backport it to ign-gui3 or just add it here in delphyne_gui
See https://github.com/ignitionrobotics/ign-gui/issues/289
I tried it locally backporting this plotting feature to ign-gui3 and it worked correctly with delphyne_gui:
It can't be ported because it breaks ABI.
We will need to migrate from citadel
to a newer release.
Probably migrating to Fortress is the best option given that it is LTS, and it is being released at the end of September. I honestly don't expect major changes. We could do a checkpoint at Edifice just to evaluate the impact.
I created a maliput worskpace from scratch using Edifice instead of Citadel on Delphyne and Delphyne-Gui and no changes were needed, visualizer is working as before but in addition, it has the Plotting feature
Here are the branches:
delphyne_gui: https://github.com/ToyotaResearchInstitute/delphyne_gui/tree/francocipollone/migrate_to_edifice
I think we can move to Edifice
as it is effortless and later on migrate to Fortress
. WDYT? @agalbachicar
Great findings @francocipollone !
I think we can just wait one more week to get ign-fortress released ( see https://github.com/ignition-tooling/release-tools/issues/459 ) and then try it directly with the next LTS. Having checked that with ig-edifice it's just a change of version increases the probability that it will be the same with fortress. That way, we do the work just once.
Given that the final decision was not to migrate to a newer release and stay with citadel
, I made an attempt to bring the Plotting feature. Some comments:
ignition::gui::Plugin
and some of thems from ignition/gui/Application.hh
file, which provides a method App()
that returns a Application
instance. So when this builtin plugins are used and they try to get the instance they point to an ignition::gui::Application
(which doesn't exist) instead of to a delphyne::gui::Application
, which causes a SEGFAULT.This was worth trying but I don't see it valid to continue with this path as it compromises the built-in plugin on which we rely, unless we bring all the builtin plugins to delphyne-gui but It sounds a bit cumbersome.
I think we can consider building an application from scratch that does not rely on the plugin architecture but implements the same plotting functionality offered by newer versions of the plugin.
We could think of coupling the application and the topic viewer via an ignition topic and service. Management of the plotting tool life cycle could be or not managed by the plugin. It changes (for worse) the user experience because of having another application instead of just one but could be a way to deal with the error for the time being.
How about subprocess, not topics and services (that's getting complicated)?
I think we missed to answer here, sorry about that. If you referred to use pipes for message transport between subprocesses I think we would do require message serialization and some kind of event system to gather data and visualize it. We could certainly do it with pipes for example but having ign-transport there which offers everything we need is tempting.
How relevant do you think this plugin is?
Context
As Delphyne Guide states, the visualizer used to use the Plot plugin that was provided by
ign-gui0
.During the migration to
ign-gui3
, it seems thatPlot
migration was omitted.ign-gui3
doesn't provide aplot plugin
ign-gazebo3
provides a (Plot3D) plugin but it isn't meant to plot graphics but lines into the scene.EDITED:
Probably we could try to backport it to ign-gui3 or just add it here in delphyne_gui
Victory condition
Adds Plot plugin.