• First week of class. Getting to know instructor and teammates.
• Read the syllabus and attempted the Welcome Quiz.
• Joined the Discord, and created this notebook for tracking progress.

Note: I'm one credit hour student, so there will usually be one entry.

• Second week of class. Team meeting was to illustrate components of cyber physical system and getting to know which subteam each person will be in.

• Read the powerpoint slides to understand components of power system simulator for device modelling.

• Installed linux and learnt about its structure. It was my computer -> windows -> WSL -> Ubuntu 26.04 LTS -> Bash

• Went over this Linux tutorial up to but not include Manual Pages. Learnt commands such as pwd, mkdir, mv, cat, ls, file, ls -a, cd to navigate linux

• Bash command example:

ryosuke_shibuya@Lenovo:~$ mkdir practice
ryosuke_shibuya@Lenovo:~$ cd practice
ryosuke_shibuya@Lenovo:~/practice$ cd..
ryosuke_shibuya@Lenovo:~$ pwd 
ryosuke_shibuya@Lenovo:~$ ls 
ryosuke_shibuya@Lenovo:~$ touch message.txt
ryosuke_shibuya@Lenovo:~$ echo "This is a bash code snippet" > message.txt
ryosuke_shibuya@Lenovo:~$ cat message.txt

• Terminal output example:

/home/ryosuke_shibuya
practice
This is a bash code snippet

• Went over github tutorial GitHub tutorial. Created repository, created branches, modified README file, pulled request, and merged the request.
• switched a team from Device Modelling to ROS/HELICS.
• Created a python virtual environment and installed HELICS. Went over HELICS Quick Start
• team meeting happened on Friday to discuss about the kick off presentation. Looked over the slides from previous semesters and learnt that important components are integrating GridLabD, HELICS, ROS, NAV2, to simulate fault, detect fault and send the commanding signal to the robot to navigate to the faulty equipment, respectively. For example, the flow for the detecting overheated transformer is

1. The GridlabD continuously publish the line current via HELICS
2. The thermal monitor Python federate calculates the temperature of the transformer using the current
3. If temperature exceeds the threshold, then send the command to ROS2 via HELICS
4. ROS2 translate the fault to the map coordinate and send it to NAV2 action server
5. Robot navigates through simulated world, and finds the faulty transformer. It does 360 degrees rotation to capture the temperature using sesnsor

Other important matters for the robots are robot hardware for ground traversal, and PCBs and serial communication between RPi and STM32. Kalman filtering is the another ask.

• meeting was held offline. Discussed what each team members has worked on, what we're going to work on and any concerns.
• Went over NAV2 repository (https://github.com/cps-vip/NAV2). I read the instructions on getting the software started and learnt important directory strcutrues in NAV2 folder. The src folder is the one developers modify their source code, the build folder has the pre-installed tools in it to process the source code, install is the the folder that contains useful output of the source code, and log is the the output of the build process. I used ROS2 Jazzy platform.
• First day downloading was rough, as I got persistent connection error, but on second day, I finally got the robot simulation setup and ready to work on actual tasks for the semester. The key was to launch new terminal in the same Docker environment rather than WSL on my computer.

• Integrated ROS2 Nav2 with HELICS by using a waypoint publisher to receive power-grid fault coordinates and send them to the Nav2 navigate_to_pose action server. GitHub
• Built and configured the autonomous robot simulation using ROS2, Gazebo, RViz, SLAM, LiDAR, and the Nav2 planner/controller stack for path planning and navigation. GitHub
• Implemented the end-to-end fault-response workflow, connecting GridLAB-D fault detection → HELICS communication → ROS2/Nav2 → autonomous robot navigation to the detected fault location.
• Figuring out ways to update the code and propagate the change through the system.

• spent some time mapping how software side interact with the hardware as I couldn't follow the meeting discussion. I drew flow diagram to understand the different components of the robot. We discussed in the meeting that STM32 microprocessor is replaced by Zynq 7000 or FPGA.

• traced through the software found GitHub and found two limitation. The current only gets received from phase A, but not phase B or C. The coordinate is right now fixed to (-5,3) so it would need to be changed to reflect actual robot location.

• I cloned the (https://github.com/cps-vip/cosim-fault-injection) with added changes from Favour onto Docker with unified code to run the terminal, so I don't have to keep running 4 terminals every time.

• worked on software workflow from Grid-LabD detecting a fault, Helics sending the coordinate of the fault, waypoint_publisher.py sending a goal, NAV2 plans a route, and Gazebo robot drives to the fault. I found that the simulation was running properly, but the robot wasn't navigating to the fault location. So, I edited the waypoint_publisher.py and added a call-back function to report whether Nav2 accepts or rejects navigation goals.

~/ros2_ws/src/NAV2/src/vipnav/node/waypoint_publisher.py

Specifically I changed from

self.nav_to_pose_client.send_goal_async(goal_msg)

to

future = self.nav_to_pose_client.send_goal_async(goal_msg)
future.add_done_callback(self.goal_response_callback)

Results:

• Nav2 initially accepted a goal at (1.5, 0.5).
• Later goals were rejected because the navigation action server was inactive.
• The logs also showed missing coordinate transforms.

This confirmed that the HELICS was sending to ROS2 properly, but Nav2 wasn't fully ready.

• Discovered missing Gazebo-to-ROS2 connections. /odom and /clock had no publisher and /tf was missing /odom -> base_link transform. Gazebo was producing odometry, yet ROS2 wasn't receiving it. Manual temporary bridges worked and confirmed that each connection worked.

~/ros2_ws/src/NAV2/src/vipnav/launch/launch_sim.launch.py

Specifically I changed from

arguments=[
    "--ros-args",
    "-p",
    f"config_file:={bridge_params}",
],

to

parameters=[{"config_file": bridge_params}],

The required bridge topics were now being published after launch. We still need to verify whether the four TF publishers include any conflicting transforms.

• other updates: NAV2 is active, the robot was being commanded to remain stationary at that instant, the odom → base_link transform is available, but the map frame is missing in the logs we inspected. SLAM Toolbox normally provides map → odom, so that is what we need to investigate next.

• prevented repeated fault-locations messages from triggering duplicate navigation requests. It will now send the navigation goal when the goal is different from last submitted one.

last_goal = None

while h.helicsFederateGetState(fed) == h.HELICS_STATE_EXECUTION:
    if h.helicsInputIsUpdated(sub):
        fault_name = h.helicsInputGetString(sub)
        x, y = fault_name.split(',')

        goal = (float(x), float(y))

        if goal != last_goal:
            node.send_goal(x, y)
            last_goal = goal
        else:
            node.get_logger().info(
                "Duplicate fault location - skipping goal"
            )

• modified the SLAM Toolbox parameter for the minimum_travel_distance from 0.5 to 0.05 m to allow it to process smaller robot movements when updating the map.

ros2 param set /slam_toolbox minimum_travel_distance 0.05

• The path planning failed initially, but after refreshing the simulation and initializing the map, robot started to navigate correctly. The robot attempted to move to fault location (1.5, 0.5) and eventually reached (1.274, 0.591) before confirming NAV2 returned "status : 4", indicating successful navigation. Although, it should reach more closely towards an actual fault location.