This will mean that all Network Profile, Documentation, Abstract Business Logic, etc. attributes may have to be children (until WebGME supports custom attribute types) of their respective parents but will allow the CodeMirror - based editing to be more general and flexible (allowing for instance different syntax-highlighting, code completion, and linting for the c++, ROS, markdown, etc. types we support)

When running imageProcessor component, it fails to properly link to opencv_core at run-time.

Should explain how the models work (containment hierarchy, etc.) as well as how they map to hosts on networks for execution. The end of this guide should be the execution of the RunExperiment plugin on a sample model and some explanation of how to get access the output of the experiments.

If binaries don't exist, the error is an ENOENT showing the full path of the generated directory that should exist; need to catch it and refactor the error.

This would occur when node_main or roscore return errors for some reason. Propagate that error back to the user.

Allow users to add extra brief and detailed comments to port operations that will be added to the generated documentation.

Right now the running experiment's relevant info (the actual container->host mapping) is lost when the RunExperiment plugin finishes execution. These data should be saved as children of the experiment in the database. This will allow visualization of the actual experiment as well as more fine-grained StopExperiment execution.

Add an attribute in the Results object that saves the contents of the retrieved plot and prepare a visualizer; one that displays the plot of the execution when clicked.

Currently, in the Run_Experiment plugin, we have a hard-coded command "'export DISPLAY=:0.0'" in the start_processes function. Such commands are a property of the application and not the deployment infrastructure. So, commands like these need to be prepared in the model and therefore required as a concept in the metamodel.

It properly loads the openCV libraries, but cannot resolve an (oddly unmangled) cvFontQt symbol.

We want to be able to set deadlines for component instances so that we don't have to recompile during experimentation.

All stable ROSMOD v0.3 samples need to be ported to webGME ROSMOD

Need to ensure that names for package, component, port, message, service and other items that become generated code follow proper naming conventions and don't have name collisions with each other. Need to also ensure that they do not collide with special or used names.

I want to run a single experiment 32 times. It would be great if we have a multiplier textbox where users can specify a number. If the experiment needs to run 10 times and the user wants all the logs aggregated, then the user enter 10. Also, we need some way to differentiate between "Run as many times as possible if 10 unique hosts are not available" and "Do not run if you cannot run the experiment 10 times".

These include

• client-server
• publish-subscribe
• three-component-example
• timer
• sequential-leds

Each of these should have at least a Localhost-only system/deployment/experiment (SDE) as well as a cluster based SDE.

Use the new Documentation objects that each FCO contains to generate html/pdf documentation separate from the code documentation that goes into the generated Doxygen documentation.

Ports need different names from parent components

String equality matching from the name of the constraint to the name of the capability.

Need to order the constraint solution in order of containers with descending number of constraints that need to be met. Investigate if this will always find a solution if one exists.

Files such as camera.yml which is required for the imageProcessor aruco code needs to be captured in the meta-model/model and must be deployed and managed with the binaries.

Allow SoftwareGenerator and RunExperiment plugins to be run on client side so that they can simply generate and zip the source files and deployment files for the project. This would be useful for guests on rcps.isis.vanderbilt.edu who do not have permission to use the cluster but still wish to create models and get back their generated code to compile and run themselves.

The errors are either squashed by the function or are not properly formatted for passing back to the user.

These functions have known remote error propagation issues:

• testSSH
• executeOnHost

These visualizers need to account for the usage paradigm of the object and provide only the relevant options based on the meta-model (e.g. in Root visualizer (RootViz), only allow creation or deletion of Project objects).

These need support for connection drawing, pointer referencing, set membership, etc.

Right now any other code that has been generated by the model gets copied over for compilation even if it is not part of the current project's software model.

The CodeMirror code editing modal dialogs triggered from decorators should be refactored into separate tabs (fullscreen-able) inside the center-widget as part of a custom visualizer for their respective model object.

Develop a user-guide which walks through one or two simple examples to show how to open/create, traverse, and edit models. Should cover simple software and system models including components, services/messages, networks, and hosts. The conclusion of this guide should be execution of the SoftwareGenerator plugin to produce source code and automatically compile it. Perhaps have a section on adding user-added business logic.

Compilation warnings or errors stemming from user component or port code should be properly detected and point back to the proper line of the code object.

Use arrays to store objects instead of storing objects as key:value pairs in other objects. Currently the objects are stored with the key being the name of the object so name collisions result in overwriting the original object. By using arrays we easily handle duplicate names without issue and can use array.map(function(element) {}); syntax which is much cleaner

We currently have no way to specify in the model which user to deplpy an experiment as -- ROSMOD always chooses the first available user.

node_mains start but deployment process fails with error: write after end

Should also delineate by product type (server, BeagleBone Black, NVIDIA Tegra) using lshw. These should be added as attributes and used for compilation and deployment / experiment mapping constraints.

The compileOnHost invocation of executeOnHost function does not properly receive errors in the compilation steps and pass those errors back to the user.

Error processing needs to be refactored because, for instance, an incorrect SSH key specification shows up as an incorrect Arch/OS error when it is not.

Displayed in the various parts of the model which guides new users through what the model is and how to use it and run the plugins.