Installed HELICS on Ubuntu by building from source. In order to access and run HELICS examples, the BUILD_EXAMPLE option should be set to ON using the cmake GUI during build steps outlined here
Running it gave this output: I do not understand what it means yet.

Proceeded by following the instructions to install nix and set up the environment on my Windows Subsystem for Linux Ubuntu
Ran into libstdc++.so.6 error when running the gridlab example. After applying a temporary fix by using

shellHook = ''
    # fixes libstdc++ issues and libgl.so issues
    LD_LIBRARY_PATH=${stdenv.cc.cc.lib}/lib/
  ''

in {
        devShells.default = pkgs.mkShell {

          shellHook = ''
            source $(realpath ./.)/nix-shell-setup.bash
          '';

          buildInputs = with pkgs; [
            # C/C++ build utils
            gnumake
            (cmake.override {
              uiToolkits = [ "ncurses" ];
            })
            extra-cmake-modules

            boost
            czmq
            ncurses
            zlib
            poetry
            python310
          ];

          LD_LIBRARY_PATH = "${pkgs.stdenv.cc.cc.lib}/lib:${pkgs.zlib.outPath}/lib";

        };
      }

HELICS contains a variety of ways to allow simulations to communicate with each other. One of them is MPI which is typically used to pass messages between nodes in a parallel computing system but in this case could pass messages between federates. ROS also contains an mpi package, however, there is almost no documentation. A ROS user posted this:

It seems like I will have to analyze the ROS / Gazebo program source code and see where I can use the HELICS API for message passing.

Had a session where we mapped out important questions for our research and attempted to visualize how our simulation would co-exist with HELICS and gridlab-d. We created a map drawing links between each simulation within the co-simulation and how they would react. We switched from a brachiating robot to line robot due to impracticality of the former. Decided to simulate a ROS Turtlebot using Gazebo to understand our robot's simulation environment using this tutorial

I initially installed ROS and Gazebo directly within my WSL Ubuntu environment but due to a forced exit of Gazebo, the installation broke and the turtlebot was no longer being loaded into the simulation. So I decided to run in an LXD container instead.
The first step was installing the container on my WSL Ubuntu environment. I used the commands:

sudo apt install lxd-installer
sudo snap install lxd

As we had decided upon a line robot, we created an MVP based on it. The final MVP would be a simulated line robot with the functionality to work with one piece of substation equipment - a current transformer.
We also found real examples of CT failures and their impacts in the Mexico grid system, which we used to create a convincing argument for our IPR presentation. Here is the IEEE paper
We realized that it would be a higher priority to implement inspection and repair functionalities rather than movement mechanisms first so we're going with a Turtlebot that will interact with the relevant equipment placed on the ground (e.g. an overhead line placed on the ground), mimicking our actual line robot.

I am working on understanding HELICS through the simple gridlab-d example. I am using the HELICS documentation. It deals with federates, which are instances of the simulation that model an object or group of object. Value federates are used to models physics of a system and interface with the federation using publications and subscriptions. In the example, distribution has a value federate as follows:

Publications are an interface that allows the federate to broadcast data without specifying a recipient. Subscriptions allow the federate to receive data from a specific source. In the distribution federate the publications are Total Load, CurrentA, CurrentB and CurrentC. The subscription is the Transmission voltage. Tranmission and Relay also rely on value federates. The HELICS documentation on value federates is a great resource to understand the cps-cosimulation example.

Took time to learn about Grid-lab D, which helped develop an idea of how it would play into our ROS-HELICS-GRIDLAB co-simulation. Grid-lab D relies on a .glm file to define all the objects in its simulation and their properties. These include transformers, overhead lines and meters. It can also accurately simulate consumers of electricity such as pool pumps, water heaters, office lighting and street lights. Weather can also be simulated This all combined allows for an accurate simulation.
Overhead line:

Transformer:

Meter:

Weather:

Office lights:

Gridlab D contains a definition for the HELICS integration too and uses a json file to define the federates.
Helics definition in GLM:

HELICS JSON:

We discovered a tutorial that allowed us to create a basic MVP on ROS and provided a breakdown of the components and files used to make the robot. Here is the tutorial: https://bunchofcoders.github.io/basic_bocbot/

We also discovered a course of ROS basics that had a built in IDE to develop and run robot simulations on the browser. Link here: https://www.theconstructsim.com/the-ros-development-studio-by-the-construct/

Using the ROS breakdown tutorial, we constructed what would be our MVP, with some minor changes such as the robot name and some other definitions. We managed to operate it with a teleop keyboard plugin for ROS.

To allow Mac users to run Gridlab-D without issues and allow for support for ROS, we decided to use a cloud VM based on Google Cloud Compute Engine to run Ubuntu instead of VMware Fusion as it was paid on Mac and we could not obtain a license. We used Ubuntu 22.04 LTS and installed ROS Humble and the simple gridlab d example on it. Access was given through SSH to the entire team via SSH keys.

For Gazebo to work we used VNC to connect to the GUI of the cloud VM. We followed this tutorial: https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-vnc-on-ubuntu-22-04. One drawback with this implementation was that there was a single session for VNC, i.e. everyone would see and control the same thing.

After the team installed ROS (Rolling and Humble) and the simple gridlab d example on the VM, we were no longer able to SSH into the VM. We assumed the keys had expired but even the in-browser SSH was not working. Here was the error:

Even after creating new keys, it did not work. Some sources hinted at a full hard disk causing the issue. Upon inspection of the disk usage, this was confirmed. So we then reset the VM entirely, reinstalling Ubuntu.
This was a temporary fix, however, so we reached out to the instructor to set us up with a more powerful VM. We got SSH access, however VNC was not installed. We were suggested to use X-forwarding to run Gazebo. However, it crashed before starting. Using Indirect GLX seems to be a possible solution, although we have not tried it yet.

I decided to research robot arms for the MVP when I found two examples: https://github.com/dvalenciar/robotic_arm_environment and https://github.com/UniversalRobots/Universal_Robots_ROS2_Gazebo_Simulation. For the former, the arm would be controllable and look like this:
However, they do not have support for Humble, with one supporting Foxy and the other supporting Galactic and Rolling. Porting these to Humble or switching versions for everything seems to be most viable.

I found a potential version of a ROS arm that could be used, however it is a rudimentary implementation and we would have to add a claw or gripper to hold and modify objects. The tutorial is here https://gazebosim.org/docs/harmonic/ros2_interop
It will look like this (image from site):
We are yet to implement it.

On the first meeting we created a roadmap for progress this semester, especially the ROS/HELICS integration. We found a ROS tutorial system that had a built in sandbox environment and IDE we could use. It was a 22 hour course which we decided to span over 4 weeks based on the credit hours everyone took for the course. Here is the link: https://app.theconstruct.ai/courses/61/.

We soon discovered that this tutorial had a paywall that came in between and therefore was not feasible for all members to participate in without self funding. Therefore we decided to pivot to the official ROS2 documentation. We chose the Humble distro tutorial. Again we would span it over several weeks. Link: https://docs.ros.org/en/humble/Tutorials.html

Here is our initial target content to cover. It is enough to gain coding knowledge to figure out a rudimentary ROS/HELICS integration.

Understood the necessary environment variables for ROS in my WSL terminal. ROS_VERSION is set to 2, ROS_PYTHON_VERSION is set to 3 and ROS_DISTRO is set to humble. I also learned ROS communication is not limited to localhost and can occur over local network. The environment variable ROS_LOCALHOST_ONLY controls this.

Learned how to install turtlesim, a lightweight simulator to learn ROS2. Here is how I installed it:

We control it using a teleop keyboard:

We can also see nodes and their associated services, topics and actions.

But what are nodes, topics, and services?

At this stage the tutorial does not expand upon them but we used rqt to call some services and interact with turtlesim_node.

rqt is a GUI application where we navigate to Plugins > Services > Service Caller. From this, services seem like commands. We run /spawn which spawns a new turtle.

We can see parameters, the name must be different from the original turtle. We click call to run it.

However, if we want to use the teleop keyboard for this turtle, we must remap the cmd_vel topic. Topics appear to be variables from what we have seen. We run

ros2 run turtlesim turtle_teleop_key --ros-args --remap turtle1/cmd_vel:=turtle2/cmd_vel

ROS2 has a key concept called a ROS graph, which is a network of ROS2 elements simultaneous processing data. Here is what it looks like in the tutorial:

Nodes are responsible for a singular purpose and can send/receive data from other nodes via topics, services, actions, or parameters. When we run turtlesim_node and turtle_teleop_key, we get two nodes: “/turtlesim” and “/teleop turtle”. We can view them using “ros2 node list”.

There is a concept of remapping that allows us to reassign default node properties to our own values. Previous we remapped cmd_vel topic in turtle_teleop_key.

To see node information we run “ros2 node info /turtlesim”

This provides all ROS graph connections interacting with the node.

We saw in the previous entry the diagram in which there are nodes connected to each other. Some of these connections had topics. Topics are essentially a means for nodes to exchange messages, by either publishing data to a topic or subscribing to data from a topic. We can see the topics by running the command rqt_graph.

The topics are in rectangles. Topics carry messages and can be published to and subscribed from. For example, /teleop_turtle publishes to /turtle1/cmd_vel which /turtlesim subscribes to. Using the below commands we can see topics and their types too.

We can also subscribe to and monitor a topic from the command line:

This format of data is a specific type that can be found through the following command:

Once we know the type of data, we can see the format:

Services are another means of transmitting data between ROS nodes, except they rely on a synchronous method of call and response. Only one node will serve data and will only provide the “response” (data) when “called” (requested) by other node(s).

We can see the list of services using this command:

Similar to topics, we can find out the list and types of services. We can also show the interface. Replace topic in the commands from the previous entry with service. However, we cannot use echo. We must use call instead and provide arguments which we can discover from the interface.

Parameters are a method of storing configuration values for ROS nodes. To list we simply use ros2 param list. We can use

ros2 param get <node_name> <parameter_name>

to get the type and value of a parameter and use param set and append the value to the command to set the value. “param dump ” can get all the node’s parameters which can also be written to a file. “param load ” can load them into a node from file.

ros2 run turtlesim turtlesim_node --ros-args --params-file turtlesim.yaml

The above command will load parameters into the turtlesim_node from the turtlesim.yaml file on executing of the node.

Actions are a communication method relying on a client-server model. They have a goal, feedback and result. They provide a steady stream of feedback to the client after it sends a goal to the server. The server finally returns a result. Actions can be cancelled.

The key presses are actions in this case.

Here are the results of key presses:

Again just like topics and services, we can check the interface and list with similar commands. However, instead of echo or call, we use send_goal:

We can also add a parameter to receive feedback:

Learned to use rqt_console to log errors in ROS. Run it via

ros2 run rqt_console rqt_console

Here we can see errors, warnings and other logs.

If we want to run an entire robot, as our research aims to, multiple nodes must be launched at once which can be done via the “ros2 launch” command. You can run from launch files such as the example provided in the tutortial of multisim.launch.py

# turtlesim/launch/multisim.launch.py

from launch import LaunchDescription
import launch_ros.actions

def generate_launch_description():
    return LaunchDescription([
        launch_ros.actions.Node(
            namespace= "turtlesim1", package='turtlesim', executable='turtlesim_node', output='screen'),
        launch_ros.actions.Node(
            namespace= "turtlesim2", package='turtlesim', executable='turtlesim_node', output='screen'),
    ])

Learned how to record data published to topics in ROS and how to play it back to replicate conditions. This is useful during testing of the robot to ensure that conditions are repeated in order to ensure reliability.

We record topics for the turtlesim the following way:

The data is stored in an sqlite3 database file:

It can be replayed and relayed back the following way:

Learned how to use colcon, the ROS build tools.

Installed an example package from git and ran build on it.

But I experienced several errors as shown below.

To remedy them I found the following solution that involved decreasing the number of threads. Link here: https://answers.ros.org/question/368106/c-fatal-moveit-2-error-killed-signal-terminated-program-cc1plus-compilation/

colcon build --parallel-workers 4 --cmake-args -DCMAKE_CXX_FLAGS="--param ggc-min-expand=20" --symlink-install

It still did not work entirely:

Then I ran:

colcon build --parallel-workers 1 --cmake-args -DCMAKE_CXX_FLAGS="--param ggc-min-expand=20" --symlink-install

It was successful

We can now test:

Seems like the example was deprecated.

Now to actually run nodes:

We can use “ros2 pkg create” to create our own package from a template. We can set up colcon_cd using

echo "source /usr/share/colcon_cd/function/colcon_cd.sh" >> ~/.bashrc
echo "export _colcon_cd_root=/opt/ros/humble/" >> ~/.bashrc

colcon_cd can help us change directory to the workspace of a package.

Learned how to create a workspace in ROS. Found out overlays exist where you can override existing packages in a secondary workspace.

Changed the code for turtlesim in the overlay.

Created ROS packages which allow sharing and distribution of code. I went forward with CMake as we will use C++ for our project. We already created a workspace.

The following commands will create a package called cips_vip (mispelled cps_vip)

Once built, we can run the package.

We can also modify package.xml.

We included a description here and modified license.

Learned how to write C++ code for a publisher and subscriber node in ROS. Looking at this model, it seems like these files will most likely be a target for our HELICS integration efforts.

The publisher code has two headers outside the STL. “rclcpp/rclcpp.hpp” is a standard ROS header than includes common ROS functionality. “std_msgs/msg/string.hpp” is a header that will define the messages our publisher will publish. These headers will have to be added to package.xml as dependencies.

The publisher has a class that inherits from Node. Seems like ROS relies on OOP with inheritance and constructors. There is a timer field that executes every 500ms and calls a timer callback that publishes the message. Basically that means the timer callback will be the main function to publish messages.

Lastly, in the main function the node is initialized with arguments and then the class is initialized through rclcpp::spin.

Now we edit the cmake file to add the dependencies.

We name the executable talker so that we can run it as “ros2 run talker”

We now create the subscriber file.

The code sets a subscription to the topic called “topic in the constructor. The callback function will receive subscribed data and process it. In this case it simply outputs it to the console. Again we add this to the CMake file as an executable, naming it listener.

We then build and run both nodes. Now the publisher and subscriber can talk.

Sabina created a rudimentary HELICS/ROS integration (https://github.com/fizzyforever101/ros2-helics) and I attempted to replicate it. I began by building HELICS from source

Built the publisher and subscriber with my own version

Ran both nodes:

HELICS has been successfully integrated.

Architected a way to get ROS running with the Gridlab-D example. One node should be connected to the HELICS broker and act as a subscriber to the GLD federates within HELICS cosimulation. But within ROS it will be a publisher that will have a subscriber receiving data. This way it can easily be integrated into the GLD example without having to alter significant existing code.

Came up with a tangible use case for diagnostics. This involves having a two node "robot" in the cosimulation where the magnetometer/sensor is connected to the HELICS broker and receives data from the GLD current and voltage federates. The slide below explains it further in detail.

The graphic is how it is designed in the cosimulation context.

Had our first meeting of the semester where we prepared for the kickoff presentation. I took time to ask each member their skills and assess their placements in subteams for the rest of the semester. Here was the final assignments I came up with:

Additionally I evaluated key areas to work on and improve in for our coming semester.

We presented successfully. Additionally I began looking into ways to parse Gridlab-D data into a format that would support our magnetometer concept in the slides we presented:

Our first online weekly where I came up with the idea of recording minutes to help with notebooks and tracking the team progress. We would address topics for each subteam in this format:

As a member of the ROS/HELICS subteam with Sabina, our main concern was addressing how to retrieve data from Gridlab-D into ROS via HELICS and apply some sort of preprocessing within the ROS node in order to calculate a magnetic field.

Additionally we debated whether to make changes to the ROS source code itself or to HELICS and make a pull request to either repository to contribute to these open source projects. Of course, it was a stage we would have to consider after we had a PoC. Additionally, we would have to convert our code into some sort of ROS package or make significant changes to HELICS. For reference, Gridlab-D uses HELICS headers when building with HELICS support.

Debated on how to create an interface for ROS-HELICS. The two viable options I saw were to either broadcast all federates from HELICS to ROS by converting them to ROS topics or to have each ROS node act as its own federate and subscribe to HELICS federates accordingly. The former option is good to plug and play into ROS where all other nodes would simply need to subscribe to the HELICS federates converted to ROS topics. However, it is computationally wasteful and expensive. The other option was to have each ROS node be a HELICS federate and subscribe to the relevant data. It would have more overhead every time we need a node that has to interface with HELICS but would be less wasteful. Here is the idea for the broadcast method:

We had another team meeting where I realized an inefficiency with Missionary and Trajectory and Nodes/Sensors. Both teams were working on sensors as they were essential to their goals. But I realized that Mission and Trajectory should be more concerned with the Mission part. Hence I directed them to focus on what was essential to our mission: identifying points of failure in the substation and how to reach them. And then how the components can be fixed by a robot.

For ROS/HELICS we finally resolved the open source contribution dilemma and came up with the idea to serve our integration as a standalone ROS package. We debated between lifting the header files and link libraries only but it seemed wiser to include HELICS as a submodule in the package source and then use CMake to include them and build HELICS first.

Furthermore, we discussed a Docker build environment to make it easy for other developers to ramp up and quickly contribute to the HELICS/ROS integration. We would build HELICS and Gridlab-D with appropriate flags in that image and include a ROS Humble installation. The image would be hosted on our Github container registry for cps-vip. How to: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

We discussed bugs from last semester. Sabina was tasked with a better cleanup script. Additionally, in her docker image files were not copied with correct permissions. I recommended using CHMOD in Docker to set permissions while copying.

I began work on the Dockerfile, following installation instructions from Sabina's Notion: https://girlsinquantum.notion.site/ROS2-HELICS-GridLAB-D-Integration-Running-the-simple_gld_example-2ff07d8bae104e6b9989f0d3d21a6f57?pvs=4

Additionally, Sabina and I decided to shift from our initial device-robot interaction model using the magnetometer. I decided to discuss with Sam how faults are detected in the real world. Turns out that usually a device has some fault detection mechanism and sends it to a centralized command and control model. Sam recommended injecting faults into Gridlab-D using a fault injection module that is already available. We finally came up with a plan to have a python command and control federate that will receive data from gridlab-D, parse it to detect faults and then send commands to a ROS federate either through a ROS topic itself or through HELICS again.

I was not able to make it to the meeting due to a high fever. However, we came to the consensus to move forward with last week's work. I began facing unresolvable issues with building Gridlab-D. Mainly that it was completely unable to find HELICS headers despite using the verbatim command

cmake -DCMAKE_INSTALL_PREFIX=~/software/GridLAB-D -DCMAKE_BUILD_TYPE=Release -DGLD_USE_HELICS=ON -DGLD_HELICS_DIR=~/software/HELICS/build/lib -G "CodeBlocks - Unix Makefiles" ..

I checked paths and everything seemed correct. It was sourced from the official documentation: https://gridlab-d.shoutwiki.com/wiki/CMake_Build#Enable_building_with_HELICS

We met in class and discussed better diagramming with the paper draft coming up. I was introduced to mermaid.live, a tool to make such diagrams. I normally used draw.io so it was interesting to learn. Additionally, I shared the previous semester final paper with the team and instructed them to use it to ramp up before the paper draft deadline next week

I came up with the outline of our midterm paper.

I finalized the pseudocode for the two interface options we had to allow HELICS and ROS integration

Found another method to build Gridlab-D via Github. Ran into the same error of being unable to find HELICSConfig.cmake.

Prepared slides for the midterm presentation. Proposed the container images and mentioned the challenge of getting permission to use Github packages and the Container registry.

In the midterm presentation, I explained that we infact do have a container registry in Github although it is not very visible. Plans to get permission once we figure out how to push our images.

Addressed various areas of our command and control model. With mission planning we came up with the idea that the ROS/HELICS team will insert a fault into the Gridlab-D substation which will be processed by our command and control that will send a command to ROS. The ROS robot will then move in Gazebo.

We would use an IF ELSE statement to detect erroneous values from the Gridlab-D data within the command and control center. The command will trigger a movement to a point X in the substation. This will be our basic proof of concept. Additionally we had Mission and Trajectory Planning prepare a questionnaire for the Device Modelling team:

What is the device? Outputs of the device (voltage, current) Data type (complex, value, string, floating) Simulation configuration Potential faults and how we can produce them Communication protocols Physical structure and location ( a rough idea)

Proposed the idea of using JIRA to track our team's progress and use agile techniques to speed up our prototype development. Added all team members. Created a board akin to this:

Example from official JIRA website.

Reviewed questionnaire completed by Hussain and sent to Device Modelling.

Met the Device Modelling team and introduced the questionnaire. They also mentioned they will be sending their progress in the form of glm files. Decided to have a robot design team in the future for the physical robot.

Also picked up on Sabina's work with fault injection as she had limited bandwidth.

Reviewed Gridlab-D reliability user guide: https://gridlab-d.shoutwiki.com/wiki/Reliability_User_Guide

The main feature is being able to deterministically induce faults using an eventgen object. Faults can be induced in specific nodes in Gridlab-D and at specific times

Worked on injecting faults but Gridlab-D kept crashing as it could not find the reliability module. I used code from this example (https://github.com/gridlab-d/gridlab-d/blob/master/reliability/autotest/test_fault_current_4_node.glm):

module powerflow{
	solver_method NR;
};
module tape;
module assert;
module reliability {
	maximum_event_length 1800;
	report_event_log TRUE;
};

clock {
	timezone PST+8PDT;
	starttime '2001-01-01 00:00:00';
	stoptime '2001-01-01 00:00:22';
}

//setup reliability
object fault_check {				//Fault check object - required to make powerflow properly handle faults
	name test_fault;
	check_mode ONCHANGE;			//Fault check mode - should be in ONCHANGE - reliability will change it
	eventgen_object SLG_A;		//Link to eventgen object - used to handle "unscheduled" events - fuses and switch openings
	output_filename testout.txt;	//"unsupported node" dump file
};

object metrics {
	name testmetrics;
	report_file testmetrics.txt;						//Name of the output file
	module_metrics_object pwrmetrics;					//Module-specific "metrics" object - a powerflow metrics object is specified here
	metrics_of_interest "SAIFI,SAIDI,CAIDI,ASAI,MAIFI";	//Metrics to output into the report file
	customer_group "groupid=METERTEST";					//Search criteria for determining "customers" of the system - similar to collectors - this group is both three-phase and triplex meters
	//customer_group "class=meter";						//"Customers" are only 3-phase meters on the system
	//customer_group "class=triplex_meter";				//"Customers" are only triplex meters on the system
	metric_interval 5 h; 								//Interval to run metrics - (separate from "simulation-long" metrics) - set to 0 for no metric updates (defaults to no interval updates)
	report_interval 5 h;								//Interval to dump metric updates to the output file.
}

object eventgen {				//Event generation object - induces actual faults on the system - this one is a manual object
	name SLG_A;
	parent testmetrics;			//Parent it to the reliability metrics object
	fault_type "SLG-A";			//Type of fault for the object to induce
	manual_outages "overhead_line_34,2001-01-01 0:00:01,2001-01-01 00:00:02";
}

Modifying for my Gridlab-D example and using OC (open conductor) faults. The problem was that the reliability module could not be found.

In class I debugged this issue. The problem was that the powerflow module was being redeclared as it was already there. I fixed it but then realized that it was not working as we used a FBS solver which was not compatible. So I modified it to use the Newton Raphson solver which was compatible

module powerflow {
    solver_method NR;
    default_maximum_voltage_error 1e-4;
    line_limits TRUE;
}

Also created the eventgen object to induce the faults:

object eventgen {
	name RandEvent;
	parent testmetrics;
	//target_group "class=overhead_line_conductor";
	fault_type "OC-X";
    manual_outages "linobj12, 2013-08-28 0:00:00,2013-08-28 01:00:00";
}

Analyzed the values produced by the fault injection module.

TotalLoad showed the most visible discrepancy. But it turned out I was interpreting the values incorrectly. TotalLoad was a power value and had to be in Watts. But due to the Relay script, it was being simply represented as Amperes. However, I noticed that the fault created very small values for TotalLoad compared to without the fault:

So I decided to set the threshold for the real part to 10 in order to detect faults

Finally figured out how to build the docker image. Had tried using Sabina's initially after she pushed to the container registry but it failed as it was of an unsupported architecture. Spent some time figuring out how to build the images and finally found the correct command:

RUN cmake -DCMAKE_INSTALL_PREFIX=/software/GridLAB-D -DCMAKE_BUILD_TYPE=Release -DGLD_USE_HELICS=ON -DGLD_HELICS_DIR=/software/HELICS/build -DCMAKE_CXX_FLAGS="-I/software/HELICS/include" -G "CodeBlocks - Unix Makefiles" .. && \
cmake --build . -j8 --target install

Additionally, I built on top of tiryoh/ros2-desktop-vnc:humble as it allowed me to access the container via VNC:

To run the command is docker run -p 6080:80 --security-opt seccomp=unconfined --shm-size=512m helics-image-ros

Followed Sabina's instructions to build the HELICS-CC-ROS integration. I pushed my own branch that has a working control loop: https://github.com/fizzyforever101/ros2-helics/tree/SAFIY/fault_injection

Here is the modifications to the command and control:

        fault_detected = False
        for i in range(0, subkeys_count):
            sub = subid["m{}".format(i)]
            name = h.helicsInputGetTarget(sub) 
            current = h.helicsInputGetComplex(sub)

            if name == "IEEE_123_feeder_0/totalLoad":
                vals.append(current.real)
            if name == "IEEE_123_feeder_0/totalLoad" and current.real < 10:
                logger.info("Fault detected {} A!".format(current))

                fault_detected = True
                #print("Fault detected {} A!\n".format(current))
            logger.info("{}: Substation {} to Distribution System = {} A".format(federate_name, name, current))


        for i in range(0, pubkeys_count):

            if fault_detected:
                pub = pubid["m{}".format(i)]
                status = h.helicsPublicationPublishString(pub, "Fault detected!")

            else:

                pub = pubid["m{}".format(i)]
                status = h.helicsPublicationPublishString(pub, "All clear!")

Also used matplotlib to save a plot of the totalLoad values throughout the execution of the cosimulation. Now the only item left is getting ROS to connect to Gazebo and move the robot there. Discussions with Joseph indicated that we would have to publish integers to the keyboard controller topic to move the robot in order to complete our proof of concept. Asked Joseph to push his code at his convenience so I can pick it up.

Pushed the container image to Github:

Presented slides for the final presentation detailing our progress with fault detection and explaining it:

Wrote sections of the final paper for fault injection and docker. Learned to use verbatim in Latex to display code and terminal output:

Held the first standup of the semester. I had new members list preferences and skills in order to help them decide their subtasks within helics-ros subteam. We also merged mission and trajectory, and nodes/sensors to mission and navigation to better allocate resources and reduce redundancy in subtasks. Additionally, I asked for goals for each subtask by their assignees. Only ROS/HELICS had a clear idea during the meeting, which was to build a physical robot.

Wrote my parts for and recorded for my kickoff presentation. I scrapped all the magnetic field information as it is no longer relevant to our goal. I came up with a clear plan for fault injection: to continue last semester's work and get the command and control to move the robot in Gazebo.

We had our retrospect about the presentation. We had a comprehensive discussion on goal setting and milestones for each subtask. Here were our goals and progress:

We also changed our docker images to internal visibility