• Attended the first class meeting, where Hayden presented the syllabus and explained the goals of our VIP and the different teams available.
• Expressed interest in joining the Device Security team.
• Researched members from previous semesters to learn about the progress they have made till now. Identified the following members:
  • Piper, Favour, Estelle, Galadriel, Carter

• Found out that previous members were woking on the following topics:
  • Favour, Soyound: Physical Unclonable Functions(PUFs)
  • Galadriel: Disk Encryption
  • Estelle, Carter, Piper, Aly Aadil: Side channel attacks
  • Bermet: Fault Injection
• To decide which topic I would like to work on, I researched to all of these topics since I am new to all of them. I included the brief definitions below for my own reference and then explored each topic in more depth using the provided links.
• PUFs: A mechanism that uses variations of a device to output unique identifier to a given input, which makes the device difficult to replicate. Reference: Link
• Disk Encryption: A technology that converts personal information into unreadable code, that can only be accessed by password. Reference: Link
• Side Channel Attacks: A security exploit that uses information leaked by a system, such as timing, to extract sensitive information or secrets. Reference:Link
• Fault injection: Intentionally adding faults to see how systems behave when stressed. Fuzzing is a type of fault injection. Reference: Link
• I will review the previous members' notebooks and final presentation to better understand the different projects before deciding which Device Security sub team I would like to join.

• During class, I expressed that I was not sure which subteam to join, but after further research, I have decided to move forward with side-channel attacks.
• Began reading through Estelle's notebook to see where she left off last semester:
  • The team explored 2 types of side-channel attacks: timing attacks and power analysis attacks, including using Correlation Power analysis (CPA) with AES-128.
  • The timing attack involved a password checker that leaked information through differences in execution time. Team found out that measurements on general purpose computer were too noisy to recover the password but eventually achieved black box recovery using timing information.
• I also reviewed Carter's notebook:
  • He worked on timing attack and AES-128 using simulated power traces.
  • Worked on black-box password recovery using timing information.
  • The team decided to move from simulated attacks to hardware experiments using ChipWhisper.
• Next Steps:
  • Review the side channel repository: https://github.com/fbv81bp/Side_channels
  • Understand how existing timing-attack simulation works.
  • Begin learning Rust so I can understand and eventually work with the existing code.

• Reviewed Piper's notebook to understand her progress:
  • Learned that she developed a vulnerable password checker and attack script using timing differences.
  • To make the attacks more reliable, she tested different sample sizes and CPU work iteration.
• Reviewed Aly's notebook to understand his work:
  • Developed a password timing attack and worked on AES-128
  • Mentioned about statistical filtering and cycle accurate timing measurement to reduce noise.
• Repository that I need to review: https://github.com/cps-vip/side-channel-attacks
• I plan to explore Rust because I am not familiar with the language. I will work through the team's existing simulations to understand timing attacks and CPA.
• I explored this Linux tutorial: https://ryanstutorials.net/linuxtutorial/ to refresh my knowledge about basic Linux commands like pwd, echo, cat, rmdir, ls, etc.
• Found resources for learning Rust next week: https://rust-cli.github.io/book/index.html, https://www.w3schools.com/rust/

• Started learning Rust from https://rust-lang.org/learn/
• Completed Chapters 1-3 covering:
  • Rust setup, Cargo, variables, data types, functions, control flow, and basic I/O
  • Built and ran the Guessing Game using Cargo
  • Leaned basic Rust concepts: let, mut, String, match, loops, and libraries
• My team met in class for the team Kickoff presentation. We decided to split into subteams based on different topics. Christopher, Aly Aadil and I decided to work on Side-channel attacks and agreed to meet on Mondays at 2PM to share updates and discuss our progress.
• Worked on my slide for the side channel attack team goals. I did not include the hardware attack goal yet because we did not want to overcommit at this stage and wanted to focus on our initial software-based attack goals first.
  
• Completed the notebook self-evaluation and submitted it on Canvas.

• Reviewed the existing timing attack implementations in the team repo: https://github.com/cps-vip/side-channel-attacks to have a deeper understanding of the team's previous work.
• Started with the Rust implementations and will conitnue reviewing the reminaing timing attack and Python files over the weekend.

• The implementation uses a vulnerable password checker that compares the password one byte at a time.
• A 9 ms artificial delay is added after every correctly matched character. If it sees an incorrect character, it returns false.
• Attack tests each possible character and measures execution time.
• The character with longest time is selected and added to the known password and this repeats until the password is recovered.
• Uses sleep() function to observer the timing side channel but does not represent a real attack.

• This implementation replaces the artificial sleep() function with CPU based work using do_per_char_work().
• It uses black_box() and #[inline(never)] to reduce compiler optimizations which affects the timing.
• It still uses early-exit comparision so the timing side channel remains.
• The program reads password attempts from stdin, allowing an external attacker to interact with the checker.
• So now: Instead of sleep() it does CPU work and conitnues the comparison.

• It uses read_volatile() and write_volatile() to prevent the compiler from removing the CPU work.
• Also, it uses multiple timing samples instead of relying on one measurement.
• Removes the highest and lowest 20% of measurement and averages the rest of the measurements, also known as trimmed mean.
• Trimmed mean is used in side-channel analysis in order to isolate the leakages from the target execution operation (e.g., the AES encryption interval) (Source).
• Compares candidate timings and chooses the character with the longest time.
• Eventually, it calculates the gap between the best and the 2nd best candidates to evaluate the strength of the result.

• Goal: Reproduce the existing timing attack baseline and verify that the vulnerable password checker leaks information through response time.
• I went through Bash Pipeline documentation to understand the bash commands used in the timing attacks.
• I cloned the https://github.com/cps-vip/side-channel-attacks repository and worked in the timing_attack_rust2 directory.
• First, I inspected src/main.rs and identified the vulnerable_check_password() function.

• The function compares the password byte-by-byte and returns immediately when a character does not match.
• For every correctly matched character, the program adds a 9ms artificial delay using thread::sleep(). So, this program creates a timing difference based on how many characters of a guess match the beginning of the secret.
• I built and ran the Rust program locally and verified that an incorrect guess returns NO and the test password "Pa55word123" returns OK.
• I then tested several guesses with different correct prefixes to see the timing difference:
• Observed that guesses with more correctly matched characters take longer to process because of the 9ms delay addition, which confirms the expected timing side-channel behavior.
• I then ran the Python timing attack harness to automate the process of testing characters based on their response times. The attack recover the test password: "Pa55word123" sucessfully, which shows us that the timing difference can be exploited to recover the secret.

Goal: To observe how reducing the timing delay would affect the timing side-channel attack.

• In src/main.rs, I changed the artificial delay from 9ms to 1 ms while keeping the rest of the password checking logic unchanged.
• I also rebuilt the Rust program with cargo build --release and repeated the timing tests using guesses with different correct prefixes.
• Then, I ran the same Python timing attack harness using the 1ms version.

• Observation: Reducing the artificial delay made the timing signal smaller, but th attack was still able to recover the password because the checker still exits early when a character does not match.
• Median runtime increased from 1.27 ms for the first recovered character to 14.08 ms after recovering the full password. This shows that a smaller timing signal still existed and was enough for the attack to recover the password.
• Therefore, reducing the delay does not eliminate the vulnerability in the program.

• Task 1: Build on the previous team's implementation, inspect its compiled behavior, and establish a working baseline for timing measurements.

• Completed✅

• Task 2: Collect repeated response-time measurements to recover the password. Measure attack success as artificial timing amplification is reduced and removed.

• In Progress

  • Reduced the artificial timing delay from 9ms to 1 ms and successfully recovered the password.
  • Next goal: Test the attack using natural timing without artificial delay.

• This week I continued testing the timing attack by removing the artificial timing amplification from the Rust password checker. I copied timing_attack_refined_rust/password_checker.rs into my own timing_attack_natural_rust/ directory.

• The refined version used a do_per_char_work() function that performed 500 iterations of CPU work after every correctly matched character. This was an artificial way of making the timing difference easier to observe.

• I removed the do_per_char_work() function call and the function itself so that the checker only performs byte-by-byte comparison and exits early when it finds a wrong character.

• Using the macOS time command, I collected repeated measurements. References for the command:

  • https://unix.stackexchange.com/questions/377979/how-to-make-a-for-loop-in-command-line
  • https://stackoverflow.com/questions/67082265/why-is-for-i-in-1-10-different-from-for-i-1-i-10-i

• The results showed overlap between the two groups. When there were 0 correct characters, the range was 4-14 ms in the repeated tests, while when there was 1 correct character, the range was roughly 4-10 ms. So, millisecond level timing is too noisy to clearly distinguish the small timing difference from 1 correct character.

• The next step is to find a higher fidelity timing method for Mac that can measure the smaller differences more precisely.

• I investigated higher fidelity timing methods today.

• Hayden suggested checking the number of CPU clock cycles to get more accurate timing information. Since I am using an Apple M1 mac, I searched for ways to access CPU cycle counters.

• Also, in the sub team meeting we decided to do an implementation for Macs.

• I used this article to understand hardware performance counters on Apple Silicon.

• I also investigated mperf, which is a command-line tool for accessing hardware performance counters on macOS. I downloaded and compiled it on my mac and found that the tool supports measurements including CPU cycles, instructions, branches and branch misses.

  • Resources:
    • https://lambdafoo.com/posts/2026-03-25-mperf-hardware-counters-macos.html
    • https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/tree/master/2021/03/24

• I verified that mperf could access CPU cycle measurements on my laptop and measured my natural password checker. The screenshots below show a comparison between guesses with 0 and 1 correct characters, as well as repeated measurements to see the variation between runs.

• The CPU cycle measurements still had a significant variations between runs.

• I also investigated Apple's xctrace and installed Xcode. I was able to confirm that xctrace was working and had the following templates: CPU counters, CPU Profiler and Processor trace.

• I found that the CPU Counters template on xctrace focuses on CPU bottlenecks and does not show raw cycle counts like mperf does.

• Next step: Find a way to measure the password checker itself.

• I continued investigating why the CPU cycle measurements from mperf varied between runs.
• After collecting 100 measurements for 0 correct characters and 100 measurements for 1 correct character, I saw that there was a significant variation between runs, including some high outliers.
• I noticed that the measurements were not always consistent even when I used the same password guess.
• This suggested that factors outside the password checker itself could be affecting the measurements.
• I decided to investigate whether the CPU cores and system activity could be contributing to variation.
• Since it was fall break, I could not do much work.

• Since I am using an Apple M1, I first checked how the CPU cores are optimized, I found that M1 has 2 types of CPU cores: 4 performance (P) cores and 4 efficiency (E) cores. Reference: https://developer.apple.com/news/?id=vk3m204o
• I researched whether mperf has an option to run the password checker on only one type of core.
• I reviewed this mperf github repo: https://github.com/tmcgilchrist/mperf and found that it shows no options to select P-core or E-core.
• I also looked into macOS taskpolicy to see if it could force the password checker to use only P-cores or only E-cores, but I could not find an option for this.
• I used powermetrics to observe CPU activity and was able to confirm that both the P-core and E-core clusters were active while the system was running.
• The system was also running other processes in the background, which could contribute to variations in the measurements.
• Based on this, I could not find a straightforward way to force the password checker to run on only P-cores or only E-cores using the standard macOS tools I tested.

• I continued investigating variation in CPU-cycle measurements from the natural-timing Rust password checker.
• Collected 100 measurements using mperf and calculated the mean, median, standard deviation and number of outliers for each group.
• I used the IQR method to identify outliers. Each group had 2 flagged outliers. I created a box plot to compare the distributions and visualize the outliers (Reference for IQR method: https://www.itl.nist.gov/div898/handbook/eda/section3/boxplot.htm)
• The median was approximately 6.02 million cycles for 0 correct characters and 6.30 million cycles for 1 correct character.
• After removing the outliers, I found that it had little effect on the medians as the difference remained approximately 278,000 cycles.
• These results suggest that the guess with one correct character took more CPU cycles at the median, although the 2 distributions still overlapped.
• I successfully connected to the VIP Linux Server, and checked whether Rust, Cargo and perf were available.
• I could not begin testing because Rust and Cargo were not installed and my account did not have sudo permissions to install system packages.
• I tried using Linux perf to measure CPU cycles, but the measurements were unsupported because access to performance counters was restricted by the server.
• My next step is to ask Hayden whether I can install Rust in my home directory and whether CPU performance-counter access can be enabled on the server. I will then repeat the measurements to see whether the timing difference is consistent.

• I collected 1100 measurements using the natural Rust password checker with 100 trials for each group(0 to 10 correct characters).
• I checked that each group had 100 measurements and that there were no invalid cycle values.
• Plotted the median CPU cycles and created a box plot to visualize the timing distributions:
• The timing did not consistently increase as the number of characters matched. Some of the groups took 6 million cycles while others took 13-14 million cycles.
• There is a lot of variations in the measurements, so I need to search why the timing is inconsistent.

• Completed the Welcome Quiz and Sub-team Preference quiz.
• Chose to continue in the Navigation & Fault Detection Integration team.
• Scheduled weekly virtual meetings with the team every Friday at 11:00 AM to discuss goals and progress.

• Updated slides for the Kick-off presentation.
• Link to the presentation: Team Presentation
• My slide contribution:

• Met on Discord to discuss team goals for the semester and review progress from the previous semester.
• Assigned task: Prepare a detailed writeup by early next week including:
  • Specific issues encountered
  • Commands used
  • Fixes attempted
  • Versions of software and tools used

• Reviewed my notebook and compiled a technical document summarizing: Progress achieved, issues encountered, steps taken to resolve issues, and Software versions & configurations.
• Link to document: Google Doc

• During the team meeting, I was advised to:

  • Add debug messages within each federate to verify that data was actually being transmitted and received via the HELICS broker.
  • Use gdb or additional instrumentation to observe whether federates were correctly progressing through time and handling publications/subscriptions.
  • Work with Calvin to recreate the issue I experienced last semester.

• The primary goal was to determine whether:

  • The HELICS broker was functioning correctly.
  • Federates were publishing and subscribing as expected.
  • The failure occurred at the communication layer or deeper in the simulation stack

• Attempted to verify if the federates are actually communicating with each other by:
  • Adding additional debug print statements
  • Inspecting GridLAB-D behavior during runtime
• However, this introduced additional runtime instability. The debugging approach did not show the issue clearly, and new errors appeared during execution: lost comms error and 1317 segmentation fault

• To eliminate the possibility of environment contamination, I was advised to start from a fresh Docker container.
• Installed Docker locally and pulled the CPS VIP Docker image. Source:Joseph's Notebook
• Ran the run_example.sh in the new docker container but execution failed with NumPy and SciPy version errors.
• The error indicated:
  • SciPy required NumPy < 2.0
  • The container had NumPy 2.x installed
  • Modules compiled against NumPy 1.x were incompatible with NumPy 2.x

• To resolve the NumPy/SciPy conflict, I manually created a Python virtual environment inside the container and installed:
  • Python 3.12
  • numpy 1.26.4
  • scipy 1.17.0
  • PYPOWER 5.1.16
• After that the HELICS broker initialized successfully and the Relay federate registered its subscriptions.
• The run after that progressed further but failed later at runtime with a HELICS "lost comms" error and a GridLAB-D segmentation fault.

• Reviewed HELICS documentation on timeouts and broker disconnections: https://docs.helics.org/en/latest/user-guide/advanced_topics/timeouts.html#timeouts
• Reviewed a GridLAB-D forum discussion on segmentation faults: https://sourceforge.net/p/gridlab-d/discussion/842562/thread/099ea09a75/
• The issue referenced in the forum was resolved after GridLAB-D v4.2.x. Since the container was running v5.2.x, the segmentation fault was unlikely due to a version bug.

• Calvin identified that the Docker container had NumPy 2.x installed at the system level while my container had NumPy 1.26.4 installed.
• Mixed NumPy versions caused instability and runtime crashes.
• He created a modified Dockerfile with a new requirements file pinning the compatible version: Numpy 1.26.4
• Built the new Docker image using: docker build -f newFileName -t image_name
• Resolved additional missing dependency (matplotlib) within the container and re-ran the run_example.sh
• The simulation initialized HELICS broker, registered federate subscriptions, advanced simulation time to completion, rendered voltage and load plots successfully.
  

• Cloned Elliot’s repository: https://github.com/elliotkantor/cosim-fault-injection inside the container and sourced the virtual environment using ./install_software.sh command.

Issues Encountered:

1. When running the ting bash ./cc_run_example.sh,I received the error: “broker is unable to connect.”
2. I am only getting the tele_twist_keyboard pop-up window for all 3 terminals, instead of the actual simulation.

• The issue encountered yesterday was resolved after Nguyen realized that the HELICS branch had not been merged, which caused the error. Once the branch was merged, the error was resolved.

• While running simple_gridlabd_example, several dependency issues occurred, specifically the errors nav2_route not found and twist_mux not found.

• Solution: Installed the missing ROS packages:

  • sudo apt install ros-jazzy-nav2-route
  • sudo apt install ros-jazzy-twist-mux

• I was assigned the task of writing documentation starting from installing Docker to running Mission Room 1 using Elliot’s and Nguyen’s code.
• Between Elliot’s code and Nguyen’s code, I need to add the necessary components to resolve the Python issues that occur after sourcing the .venv from Elliot’s repository.

• Integrate and bridge gaps between: Nguyen’s implementation and Elliot’s repository/codebase
• Develop step-by-step documentation covering: Docker setup, Environment installation, Execution of Mission 1
• Clearly explain system architecture and underlying concepts for new users

• While running:ros2 run vipnav waypoint_publisher.py, encountered error: ModuleNotFoundError: No module named 'yaml'
• Attempted to install using system package manager: sudo apt install python3-yaml
• Despite successful installation, the error persisted.
• Reviewed external resources: https://stackoverflow.com/questions/50868322/importerror-no-module-named-yaml and https://github.com/knadh/tg-archive/issues/127.
• Installing PyYAML via pip resolved the issue. Command used: pip install pyyaml
• Root cause:The Python environment used by ROS was not linked to the system-installed package (python3-yaml). Installing via pip ensured the module was available in the active Python environment

• While running Ngyuyen's code, broker failed to connect and errors appeared when executing: ros2 run vipnav waypoint_publisher.py.

• Solution: Ngyuyen advised that I dont need to run ros2 launch vipnav launch_sim.launch.py when running bash ./cc_run_example.sh because bash ./cc_run_example.sh should run the ros code for you.

• Root Cause: The issue occurred due to conflicting launch processes. I was manually running: ros2 launch vipnav launch_sim.launch.py alongside bash ./cc_run_example.sh.

• However, cc_run_example.sh already launches required ROS nodes and starts the necessary simulation components

• Fix: Removed redundant launch command and only executed: bash ./cc_run_example.sh. This resolved the broker connection issue

• Advised to include a clear explanation of system architecture for onboarding new team members
• Focused on documenting:
  • Interaction between HELICS and ROS2
  • Role of each component (simulation, control center, navigation stack)
  • Data flow between subsystems
  • Added diagrams to improve clarity and usability of documentation

• Continued integrating Nguyen’s and Elliot’s systems
• Successfully reached a stage where all required terminals were running and no runtime errors were present.

• Robot generated a green path in RViz and the coordinates were being updated correctly. However, the robot did not move in Gazebo.
• This indicated that navigation stack was functioning, path planning was successful but execution was not occurring.
• I reviewed some resources to try to resolve the issue:
  • https://www.youtube.com/watch?v=laWn7_cj434&t=1130s
  • https://www.youtube.com/watch?v=HJAE5Pk8Nyw&t=4664s

• Ngyuyen advised me to run simulation independently i.e run ros2 launch vipnav launch_sim.launch.py and launch navigation stack separately without the bash ./cc command.

• After following this approach the green path stopped appearing in RViz

• Reviewed RViz configuration and behavior using official resources:

  • RViz documentation
  • RViz tutorial
  • RViz User guide

• Focused on understanding proper initialization of robot pose and visualization settings in RViz

• Continued refining documentation. Incorporated screenshots of each terminal and step-by-step execution steps.
• Purpose of this is to improve onboarding experience for new users, ensure reproducibility of setup and execution and reduce setup time and common errors.

• Scheduled a meeting with Nguyen to troubleshoot the issue where the green navigation path was not appearing in RViz.

• During the call, I learned how to properly use:

  • 2D Pose Estimate (to set the robot’s initial pose)
  • 2D Goal Pose (to assign a navigation target)

• Despite correctly using these tools, the issue persisted.

• Upon further discussion, we identified that the root cause was the use of an outdated Docker image.

• The team had updated the environment but I had not been informed of the latest changes.

• As a result, I needed to reconfigure the entire setup using the updated repository: cosim-fault-injection repository

• Nguyen also advised modifying the Dockerfile to fix a known ROS key expiration issue, which prevents apt-get update from working properly.

• Dockerfile Fix (ROS Key Issue) RUN rm -f /usr/share/keyrings/ros-archive-keyring.gpg
  && curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key
  | gpg --dearmor -o /usr/share/keyrings/ros-archive-keyring.gpg
  && echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg]
  http://packages.ros.org/ros2/ubuntu noble main" \

  /etc/apt/sources.list.d/ros2.list

• Docker Setup Commands

  • docker build -t cps_cosim .
  • docker run -d \
  • -v /absolute/path/to/cosim-fault-injection/software:/home/ubuntu/software \
  • -p 8060:80 \
  • --name cps cps_cosim

• Encountered an issue when trying to access the ROS workspace:
  • Error: “No such file or directory” for ~/ros2_ws
• Fix:
  • mkdir -p ~/ros2_ws/src
  • cd ~/ros2_ws
• This manually initializes the ROS2 workspace structure required for building packages.

• While cloning: git clone https://github.com/ros-teleop/twist_mux.git, Git repeatedly prompted for credentials and failed authentication, even with correct login details.
• Root Cause: Git was attempting to use cached credentials or password authentication, which is no longer supported by GitHub.
• Fix:
  • git config --global --unset credential.helper
  • git clone https://github.com/ros-teleop/twist_mux.git
• After clearing the credential helper, the repository cloned successfully.

• No team meeting was held.
• Continued documenting setup steps and troubleshooting procedures for the updated simulation environment.

Spring Break

• Added final touches to the documentation and completed it.
• Need to check with the team on what I can help with next.

• Was advised to upload the documentation to the NAV2 repository.
• Elliot suggested working on documentation for Kalman Filter/SLAM or contributing to SLAM development with Calvin.

• Added the documentation to the NAV2 repository README: https://github.com/cps-vip/NAV2
• Reviewed Calvin and Nguyen's notebook entries to understand their progress and determine where I can contribute next.
• Reached out to Nguyen to see if he needs help documenting background information on Kalman Filter/SLAM.

• Researched SLAM and Kalman Filters to build foundational knowledge. Reviewed the following resources:

  • https://www.mathworks.com/discovery/slam.html
  • https://kalmanfilter.net/
  • https://www.youtube.com/watch?v=IFeCIbljreY
  • Elliot clarified what should be included in the documentation:

• Key Points to Cover:

  • Introduction
  • Explanation of SLAM (what it is and how it works)
  • Overview of navigation algorithms
  • Explanation of Kalman Filtering
  • Discussion of covariance, parameters, topics, and system behavior (including speed considerations)
  • How SLAM and Kalman Filtering relate to the robot we are building

• Next Steps:

  • Start with a deeper understanding of Kalman Filtering before moving on to SLAM

• Watched several videos on SLAM and Kalman filtering:
  • https://www.youtube.com/watch?v=xqjVTE7QvOg
  • https://www.youtube.com/watch?v=ZaiA3hWaRzE
  • https://www.youtube.com/watch?v=mwn8xhgNpFY&list=PLn8PRpmsu08pzi6EMiYnR-076Mh-q3tWr

• Started documenting about SLAM and Kalman Filtering
• Google doc link:Documentation

• Asked Nguyen if he would like me to record a video of the Mission 1 demo for the final presentation.
• Continued working on the documentation for SLAM and Kalman filtering.

• Reviewed the presentation slides: Spring 2026 Slides to determine if I needed to add anything.
• Determined that no additions were necessary, as I was contributing to the documentation for Mission 1 execution.

• Attended first meeting virtually via Discord and learned about Cyber Physical Systems and its sub teams.
• Completed Welcome Quiz and Sub-Team Survey.

• First in-person meeting and went over the project goals, some basics, met team members, etc.
• Learnt about GridLabD, ROS, HELICS and how each of them help in building the robot.
• Briefly discussed about man-in-the-middle attacks and the lack of encryption
• Scheduled for weekly ROS/HELICS sub-team meetings: Wednesday 12.30 pm on Discord.

• Met on Discord to discuss team's semester goals and kickoff presentation guidelines.
• Discussed various sub-teams within ROS/HELICS team and decided to join the Navigation & Fault Detection Integration team.
• Talked about the goal for navigation team which is to send the robot a location to navigate to using the code and let the robot autonomously navigate there.

• Reviewed the slides for kickoff presentation and prepared my part.

• Did the kickoff presentation with ROS/HELICS team where I presented the General Logistics for our team's project work.

• Also discussed about past work and the goals for this semester after receiving feedback from the instructors.

• Link to the presentation: 2025 Kickoff Presentation

• Discussed what new members can start working on/looking at to familiarize themselves with the current project.
• Started to familiarize myself with ROS2 using documentation/tutorial videos shared by Nguyen. I will try to look at them before next week so that it is easier to pick up from there. Link to the videos: ROS tutorial
• Decided to pull down Docker image from container registry by next week so that we can start working on the project ASAP.
• As a starting point, new members were advised to pinpoint a location and map it to the Gazebo simulation.
• Lastly, notebook evaluation is due tomorrow.

• Reviewed few ROS tutorial videos to familiarize myself with it.
• Completed the Notebook self-evaluation assignment.

• Continued watching ROS videos.
• Went over Joseph's notebook for VM and software install.

• Watched ROS tutorials and understood how URDF helps in describing robots.

• Discussed in detail each member's progress and what they need to complete by the class meeting.
• Set up Docker and successfully pulled the CPS VIP Docker image. Initially ran into some issues, but they were resolved after retrying. This is what I used to pull it: Joseph's Notebook
• Tried exploring inside the container but didn’t understand much; I might need some time and help to get comfortable with it.

• Asked Will to check my Docker image to confirm that it was downloaded correctly and contains all the necessary installations.
• Will introduced us to Linux and explained the basics so that we could start getting acquainted with it.

• Discussed about each other's progress and what the newcomers should start looking at.

• Installed Wireshark from https://www.wireshark.org/download.html and then opened and analyzed a packet capture (pcap) file using Wireshark.
• Discussed network connections, and how to interpret packet details.
• Learned how to identify which devices are communicating to each other, the size of data being sent, how devices communicate on local network, etc.
• Here are the images:

• Was advised to replicate the work from last semester to get familiar with how the navigation works, using the documentation in Natalie and Ngyuyen's notebooks.

• Could not attend it due to the timings clashing with one of my midterm exams.
• During the meeting, newcomers were advised to look over the final paper from last semester so that we can edit out midterm paper accordingly.

• Skimmed through the final paper to get an idea of everything. Here is the link to it: https://www.overleaf.com/project/68dd49a8e4c028491a8777b5

• I didn’t have much to add to the final paper, but I was advised to start exploring ways to integrate Safiy’s work on navigation into the current system, which will require me to learn HELICS.
• While opening VSCodium on the VM, I encountered some issues, so Will and I spent the entire class trying to fix them.
• Since the issues couldn’t be resolved, I had to reinstall the VM using the following commands:

docker pull ghcr.io/cps-vip/cps-vip-vm:latest

docker run -p 6080:80 --security-opt seccomp=unconfined --shm-size=512m ghcr.io/cps-vip/cps-vip-vm:latest

• We submitted the midterm paper which was due tonight.

• I was able to resolve the issue with VSCodium not working on the VM on my laptop using the commands I mentioned earlier.

• We didn’t have much to discuss since a few members were unable to attend. The members who were present mainly talked about the midterm presentation.

• I started going through Safiy’s notebook; however, I haven’t made as much progress toward my goal as I had hoped. I am planning to focus on it this weekend.

• We had our midterm presentation, where I once again presented the team logistics. The presentation went well overall, highlighting our progress on waypoint navigation, 3D printing parts and beginning robot assembly, and setting up to perform a Man-in-the-Middle attack.
• Here is the link to our midterm presentation: Presentation
• Peer evaluations are due tomorrow, so I need to complete that as well.

I completed reading Safiy's notebook and made notes of what exactly he made progress on last semester. Notes I made about Safiy's progress:

• Created ROS packages to allow sharing and distribution of code.
• Built and ran both nodes; now the publisher and subscriber can communicate.
• Worked on retrieving data from GridLAB-D into ROS via HELICS.
• Finalized the pseudocode for the two interface options to enable HELICS–ROS integration (Entry 42).
• Addressed various areas of the command and control model. For mission planning, they decided that the ROS/HELICS team will insert a fault into the GridLAB-D substation, which will be processed by the command and control system to send a command to ROS. The ROS robot will then move in Gazebo.
• Planned to 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 specific point X in the substation as a basic proof of concept.
• Injected faults into GridLAB-D using the eventgen object.
• Published integers to the keyboard controller topic to move the robot and complete our proof of concept.

Additionally, I also read few Helics documentations: Helics Documentation1 and Helics documentation2 to understand the fundamentals. I am still bit confused in terms of how exactly to integrate Safiy's work but I will ask about it during the team meeting tomorrow.

I asked the team during the meeting about how to approach my goal, and I was told that integrating Safiy's navigation ROS node with the HELICS co-simulation is mostly transparent and will likely just involve importing a few modules or adding a few lines of code. I will follow up once I review the exact steps. I couldn't work much on it today as I am not feeling well, will start working tomorrow.

I have been facing an issue where VSCodium does not open. It was working after I reinstalled the VM; however, now, when I run the Docker image, open the VM, and click on VSCodium, nothing happens, it does not respond. This issue occurs only with VSCodium; other apps are working. I tried investigating the reason by reading this StackOverflow post, but I could not find a definitive explanation.

I retried opening VSCodium on all the Docker containers I have in the Docker app. It turns out I was opening the wrong container, the old one from before I reinstalled the VM. VSCodium is now working perfectly.

Reviewed this for understanding how to install HELICS. Also, skimmed through this document to learn some HELICS commands.

Gave a standup of my progress. I asked Sabina about how to open Helics and GridLab-D and she advised me to look at the integration example in her notebook (Spring 2024-Week 10 Entry).

Worked on installing HELICS within the ROS2 Docker container:

• Downloaded the latest release of pre-compiled HELICS library on my local machine and then used the docker cp command to transfer it into the container’s /opt directory with the help of this documentation.

• After extracting the files, I verified the installation by running helics_broker --version, which confirmed version 3.5.1 was successfully installed.

• I asked Sabina how to move forward, and she explained that I need to find a way for the control center to send messages to the ROS 2 subscriber and publisher nodes whenever there is a fault in the system.

• With her help, I tried running the setup and build commands for the ROS 2 workspace containing the ros2-helics/simple_gridlabd_example.

• However, we did not make the desired progress. Sabina advised me to follow this guide to run the example, and she also suggested I go through the COSIM fault injection repository to understand the fault injection workflow.

• I started running this guide but I am facing issues when installing Python dependencies like Numpy and PyPower. I am getting ERROR: Could not install packages due to an OSError: [Errno 13] Permission denied error when attempting to install Python dependencies using pip.

• Read https://stackoverflow.com/questions/31512422/pip-install-failing-with-oserror-errno-13-permission-denied-on-directory to find a way to resolve this. It suggested creating a virtual environment which worked successfully!

• Running the minimal publisher and minimal subscriber nodes in separate terminals worked perfectly. The nodes are successfully communicating over the ROS 2 graph.
• While Building HELICS ran into CMake C++ Standard Error. Read this to find a solution.

Following commands resolved the issue: rm -f CMakeCache.txt cmake -DHELICS_BUILD_CXX_SHARED_LIB=ON -DCMAKE_INSTALL_PREFIX=~/software/HELICS -DCMAKE_CXX_STANDARD=20 ../

• Updated everyone about my progress and while talking to Sabina, I realized that I did not have to run the GridLab-D example from scratch, I just had to run the last few commands in this.
• I tried to run the GridLab-D example but I am not able to see the graph as shown in the tutorial.

• I looked through https://github.com/cps-vip/cosim-fault-injection to find about Safiy's progress regarding fault injection and this is what I exactly need to do:

1. Relay federate (sends fault signal)
   • Add a new publication in Relay_config.json
   • Add publication logic in Relay_simulator.py
2. Transmission federate
   • Add a new subscription in Transmission_json.json
   • Update the logic in Transmission_simulator.py
   • Fault checking and reaction logic in main loop
     

• While working on the GridLab-D example, the graph was not displaying correctly, so I debugged the issue with Will. During debugging, we referred to the following resources:
  • MATPOWER d2Sbus_dV2 documentation
  • PYPOWER opf module documentation
  • PYPOWER d2Sbus_dV2 source code
• After reviewing additional references such as this SciPy sparse matrix guide and the SciPy documentation on csr_matrix.H, I found that the issue was related to the SciPy csr_matrix attribute .H, which has been deprecated as of SciPy v1.14.0.
• My virtual machine currently has SciPy v1.16 installed, which caused compatibility issues and prevented the graph from displaying.
• To resolve this, I plan to reinstall an earlier version of SciPy (most likely v1.13) so that the visualization works properly.

• I tried running pip install scipy==1.13.0 but got the following error:
• Read this resource and found that using a virtual environment does work.
• The order of commands to run for installing the older version of SciPy:

1. python3 -m venv myenv
2. source myenv/bin/activate
3. pip install scipy==1.13.0

• I had a few doubts and asked Sabina about them. She clarified exactly what I need to do, since I had been a bit confused. So, my previous logic was incorrect.

1. Find the federate in which the reliability module in GridLAB-D is used to generate a fault.
2. Generate the fault using the reliability module.
3. Modify the CC federate to detect the fault, since CC monitors the federate for fault detection.

Personal Time

• Found out that Distribution is the federate where Safiy had added the reliability module.
• This is the logic in CC where it reads the current and publishes the message “current shift detected,” but it doesn’t actually check whether the current has increased and simply outputs the message.
• Added the lines of code from Safiy’s reliability module to the Docker setup.

• While running the Distribution federate, I encountered a error for “SAIDI” in the power flow metrics object. The simulation successfully generated SAIFI, but failed when accessing SAIDI, and after removing that line temporarily, the same error occurred for CAIDI, ASAI, and MAIFI.
• I verified that the metrics object coming from my code did include the SAIDI field, so the issue was not with SAIDI specifically.
• To investigate further, I used Meld to compare my implementation with Safiy’s working version.
• Learned how to install Meld using this resource: https://askubuntu.com/questions/1302456/how-to-build-meld-on-ubuntu
• The comparison showed I was missing several other lines of code that execute before these metrics are computed, which caused the metric-building function to fail downstream.
• I added the missing code block. Once that logic was restored, the federate successfully computed all reliability metrics without throwing any errors.

• Tried running the simple GridLAB-D example again but still could not see any graph output. I checked the log files to understand what was happening.
• The logs did not show any runtime errors, but I noticed that one of the function calls helicsSubscriptionGetTarget, used in the Transmission federate has been deprecated since HELICS 3.6.1. I decided to fix this to rule it out as a potential issue.
• I first attempted to reinstall an older version of HELICS where helicsSubscriptionGetTarget was still supported, but this resulted in Python version conflicts, so I abandoned that approach and chose to update the function call instead.
• Referred to the following documentation:
  • https://docs.helics.org/en/main/doxygen/group__getValue.html
  • https://docs.helics.org/en/main/references/api-reference/C_API.html
  • https://docs.helics.org/en/main/doxygen/ValueFederate_8h.html
• Replaced the deprecated function helicsSubscriptionGetTarget in Transmission_simulator.py with helicsGetInputTarget. This removed the deprecation warning. However, even after fixing this, I still cannot see the graph in my setup.

• Modified the conditional logic in the CC code to send a signal to ROS2 nodes whenever the current magnitude exceeds the predefined threshold.
• Referenced to https://github.com/user-attachments/assets/833f4425-f428-43a7-ac9f-b2a81ffb9255 for writing the conditional logic code.
• Observed that the fault signal is not propagating to ROS2, indicating further debugging and testing are required.

• Discussed final presentation preparation: team members will finalize work, update slides, and select presentation topics.
• Added two slides summarizing my progress this semester and plans for next semester:

FINAL PRESENTATION

• Presented our project work to the class, highlighting fault detection, navigation integration, physical robot development, and SROS Integration.
• Here is the link to our presentation.

• Created a repository and pushed the code. My GitHub Repo