Repository navigation
Hussein Rmaile Notebook
- The first semester of a new project!
- Our goal is to build a CPS cosimulation of a powergrid in ROS/HELICS w/ gridlab-d.
- Filled out my subteam preference survey and my gitHub username survey for a future github invitation.
- Subteams were finalized in class. I am on the ROS/HELICS subteam, along with Rahil Vasa, Safiy Malik, Isabella Jemal, Suraj Shekar, and Raj Patel.
- Decided when our subteam meetings would be. Every Friday at 3:00pm we will meet to discuss project plans.
- Created a plan for starting research. We are going to research the basics of power grid maintenance as well as currently implemented maintenance solutions and solutions that have been considered but failed for whatever reason. Through the research of these ideas, we will see which one appears to have the most potential to make maintenance more cost efficient and effective, and present why we want to simulate that solution.
Met in library to choose a type of robot to propose as a solution. There were a few options:
-
UAV:
- Pros:
- high vantage point
- highly mobile
- fast
- Cons:
- uses much more fuel
- unnecessary level of mobility in many situations
- can only do surveillance from high, not maintenance
- Pros:
-
UGV:
- Pros:
- highly mobile
- can do some maintenance itself in addition to sensing when maintenance is necessary
- lower fuel usage than some other options
- Cons:
- cannot do all types of maintenance itself
- Pros:
-
Brachiating Robot:
- Pros:
- Can do inspection and maintenance
- Has close to ideal amount of mobility for the task
- 2-in-1 robot
- Cons:
- Complex parts/machinery more likely to fail and harder to calibrate
- Expensive
- Pros:
We chose a brachiating robot as our solution.
-
Kickoff presentations
- I identified required skills for our project, such as:
- Modeling and Simulation:
- Understanding of power systems, including transmission lines and power grid operations.
- Proficiency in C++ for coding tasks related to HELICS software, as well as an openness to improving current skills levels as the project progresses.
- Familiarity with version control systems such as GitHub for collaborative coding and documentation.
- Cost Analysis:
- Analytical skills to calculate and research labor costs for implementing robots in specific areas of the power grid, to ensure any proposed solutions can be feasibly implemented
- Collaboration:
- Effective documentation of research findings and proposed solutions, as well as implemented solutions.
- Strong oral and verbal communication skills as a team when identifying problems and proposing solutions, and good communication when tracking progress and setting deadlines.
- Modeling and Simulation:
- I identified required skills for our project, such as:
-
Decided on research subteams. We split up into a sensing subteam and a ROS/HELICS subteam. I am on the sensing subteam along woth Rahil, Raj, and Suraj.
-
My specific area of interest is the cost efficiency of different types of sensors. I will be finding out how energy intensive each sensor is, as well as how effective it is at improving the robot's required maintenance identification. After finding out these statistics, I will give different sensors an energy efficiency rating, so that the amount of value they add to the robot's inspection ability relative to the amount of energy consumption they have is considered, for more efficient energy usage in the robot.
- Ran HELICS demo in class.
- Was demoed how to run it, use it, what to type into terminal, common issues, etc.
- Changed direction of project
- realized brachiating robot was a cool concept, but maybe not the most feasible solution
- Line Inspection Robot:
- Pros:
- uses much less fuel
- simpler parts/less complex mechanisms
- Cons:
- can't do much maintenance, mostly just inspection
- Pros:
Worked on IPR1 presentations
- Current Transformer Failures Slide
- Significant increase in 230 kV and 400 kV Substation Current Transformer (CT) failures affecting Mexico grids
- GRIDS ARE CRITICAL INFRASTRUCTURE defined by the government
- Disruption of essential services, causing economic losses and public safety risks
- Failures linked to environmental conditions: CTs are susceptible to corrosion, contamination, and insulation degradation due to environmental stress and partial discharges
- Violent failures involve explosions and fires, causing extensive equipment damage
- Solution: Line Inspection Robots monitor environmental factors (humidity, pollution, partial discharge), inspect seals, and collect data for maintenance to enhance CT resilience
- Significant increase in 230 kV and 400 kV Substation Current Transformer (CT) failures affecting Mexico grids
- Roadmap Changes Slide
- Specialized teams
- We needed a more focused as well as efficient approach In the old organization, we just had 2 teams: Research and Coding
- We have a sensing subteam and a ROS/HELICS subteam
- Each subteam has research and coding subtasks
- Clarification of new roles
- In these roles, we can define subtasks and objectives of each team, and how it ties together in the team as a whole
- Final goal clarity
- We will get a better perspective on what our final goal is, since we are researching while sharing our research with one another
- Specialized teams
-
Studied Gridlab-D examples and also presented our research on ROS/HELICS as well as gridlab-D to each other.
-
Got turtlebot simulation running
- IPR1 presentation
- Feedback: Our proposed solution and plan is much more thorough than the one we had in the kickoff presentation. While ambitious, it is a well made plan, and might take longer to execute, but will deliver a satisfactory MVP which the customers liked. Target audience calibration was also good, they really enjoyed hearing the Mexican power grid failures real world example and recommended we go more into detail about real world examples like that.
- Compiled all of our research and findings for the midterm paper.
- I've used latex for CS 3510 and 4510, but never learned how to do citations, Rahil gave us a guide
- I've used latex for CS 3510 and 4510, but never learned how to do citations, Rahil gave us a guide
- Delegated different sections of the midterm paper to different teammates depending on what work they mostly did (shown below):
Research topic: Being able to successfully model a line inspection robot, taking all factors (physical environment, structure, functionality) into consideration.
-
Executive Summary:
- Giving a brief summary of the main findings and contributions of your research. -- Isabella
-
Introduction:
- Introduction to your research topic, its significance, and the objectives of your study. Mention the research questions or hypotheses you aim to address. -- Rahil
-
Previous Work:
- Background research relevant to your topic: o Case studies (Talk about Mexican case study, and 1 more) -- Hussein o HELICS rundown -- Safiya o GridLab-D rundown -- Isabella o ROS rundown -- Raj o Line inspection robot (Talk about the working, the reason we chose this particular robot, constraints faced by it, and its MVP -- Refer to slide 2 of IPR 1 presentation) -- Safiy
-
Research Sections: o ROS & HELICS simulation integration with Gazebo -- Safiya o Sensing Team:
- Sensors on the robot & interaction (Lidar, IRs interaction with current transformer -- Refer to Slide 9 of IPR presentation) -- Suraj
- Pros of using renewable energy on the robot, and how it can be implemented (solar, electromagnetic, etc...) -- Raj
- Testing the model on lines with different voltages, and simulating damage on the robot -- Rahil o Future solutions to challenges in our MVP (refer back to slide 6 in IPR), and physical environment -- Hussein
-
Conclusion:
- Roadmap (including Gantt chart) -- Rahil
-
References
- Everyone include 2 citations down here. Make sure that one citation is an academic article.
Set up a VnC server to try as an option for mac users who can't currently run the simulations because M1 chip incompatability. SSH key wasn't working for everybody though, so we discussed possible alternatives and did some research into trouble shooting.

One alternative we found was installing the VnC server on google cloud, using Safiy's free credits. It worked, but it was very slow when trying to run turtlebot3 sims in ROS 2, and it wasn't a good long term solution anyhow since we had a limited number of credits.
- Turtlebot3 simulations: https://github.com/ROBOTIS-GIT/turtlebot3
We reassigned research to different members to be more efficient, being able to cover more breadth and having team members describe their research to the others during the next team meeting.

-
I did research on VMs
- Virtually access a more powerful machine
- Your device essentially becomes a GUI, other machine you are accessing does computing and processing
- Depending on the VM you choose/set up, many quirks and things specific to each one
-
Running VNC on Google Cloud: https://stackoverflow.com/questions/31104226/installing-vncserver-on-google-cloud-computing-vm-ubuntu
Did more research as a group into simple ROS tutorials, as well as reading through code examples and documentation for ROS to gain more experienece.
- TurtleBot3 (ROS2 Humble): https://github.com/ROBOTIS-GIT/turtlebot3/releases/tag/2.1.5
- ROS Development Studio: https://www.theconstructsim.com/the-ros-development-studio-by-the-construct/
Thanksgiving Break
Discussed final presentation, and delegated sections

Final presentation: https://docs.google.com/presentation/d/1I_N87Nr7LH8UvbbR0zB2Erq3luHvZWur0h_-rJcflmg/edit?usp=sharing
Split up final term paper sections:

My section:

Hussein_Final_Term_Paper_Section.docx
- syllabus week
- first VIP meeting of the Spring 2024 semester
- met all of the new members
- discussed project with new members
-
Split into new members into the subteams based on their preferences from the survey, and met each of them and discussed the goal of the project with them
-
Decided when our subteam meetings would be held
- Every Tuesday from 3:30 - 4:20, since everybody should be free at that time since that is when the VIP meets on Thursdays
-
our team is Quentin, Safiy, Joseph, Isabella, Suraj, and Sabina
-
Docker container was created for running ROS/HELICs to avoid issues with macs/m2 chips, Will shared it with us today
- got the docker container installed and running using this command in terminal: docker run -p 6080:80 --security-opt seccomp=unconfined --shm-size=512m tiryoh/ros2-desktop-vnc:humble


-
Met to discuss kick-off presentation, as well as come up with our new plan for this semester based on how much we were able to accomplish last semester and the skills of the new members joining this semester
-
new member Sabina has some experience working with ROS from her summer 2023 internship, which is great
-
Created a new plan for this semester, taking some inspiration from the generalized plan made last semester for spring 2024
- Gantt Chart of general plan made last semester (created by me for last semester's final presentation)
-

Full Notes from our meeting: https://docs.google.com/document/d/1YrfRtfqJ-8Sp38xcAWemr9T-_OnCfSPBzRrkhOjC2qM/edit
Section regarding our new plan:
Key Items from KickOff Rubric:
What is the big idea and why should you receive funding? • Preliminary Project Roadmap o What tasks are necessary to make progress? Integrate ROS (Gazebo) and HELICS Get working ROS Turtlebot with arm Understand Gridlab-D simulation and how we can merge it with Gazebo o How do these tasks fit into the co-simulation use case?
o How will you measure progress at the first check-in? Weekly subteam meeting and tasks • Which of your peers are helping with which tasks? Subteams: Required Skills: ROS - Course C++ - Learn along with the course, most team members only need to know syntax
Do at least mention all subtasks briefly, even if you don’t think it is the most relevant to the audience.
Plan: Take 3 weeks to complete the course and C++ Split into subteams: Integrating ROS and HELICS ROS prototype GridLab-D (Integrate with Device Modeling Team)
Week 4 to week 8 - Split into subteams ROS/HELICS Integrations - How to get the federates in ROS/Gazebo and publish to the broker ROS prototype - Remote controlled robot, have a moving Gridlab-D - Research on how to integrate device modeling equipment into Gazebo
Week 8 to Week 10 - Merge everything together - get a simulation running, rudimentary communication between cosimulations and try to parallel equipment in gazebo
- We also finalized assigned slides by writing names next to each slide title, with everybody getting 3 slides
Slides Assigned to Me:
- Required Skills
- Roadmap (Timeline)
- Measuring Progress
Finally, we decided we will take a 20 hour course on ROS over the next 3 weeks, to learn the basics and get more comfortable with C++
Worked on and completed my slides in the morning
Slide prep: Kickoff presentation slide prep.docx
- took our loose plan decided yesterday and made a Gantt chart visual for it, also decided what the required skills would be based on our discussion yesterday but also just what would be necessary to accomplish our goal
Finished Slides:
- Required Skills

- Roadmap (Timeline)
Spring Semester Plan Gantt Chart.xlsx
- Measuring Progress

- presented kick-off presentations over discord
- got the talker/listener demo to work from our ROS tutorial in ubuntu


-
The ROS course we were taking ended up asking for a $40 subscription fee, so it was really only a demo
-
We looked at alternate options
- https://youtu.be/Gg25GfA456o?si=o8kbAG6r1MAwmYbB (youtube video found by Suraj)
- https://www.youtube.com/playlist?list=PLK0b4e05LnzYNBzqXNm9vFD9YXWp6honJ (youtube playlist found by Safiy)
- https://foxglove.dev/tutorials (Website with tutorials found by me)
-
We decides to try the tutorials provided in the ROS documentaion:
- https://docs.ros.org/en/humble/Tutorials.html
- We are going to try and finish the tutorial up until Beginner: Client libraries in the next two weeks. Next meeting we will track our collective progress and adjust our plan accordingly

- got the turtle sim running in ubuntu following the Ros documentation tutorial


- also learned about how the nodes in ROS2 interact with each other:
- Nodes have a singular purpose and can send and receive data to other nodes through topics, services, actions, or parameters.
- Publisher nodes can publish a topic which all subscriber nodes can then access
- alternatively, a node can request a service, and another node can provide a response, as shown in the diagram below

- we worked independently today instead of having a meeting due to a member having an emergency
- i ran into an issue building packages with colcon, the code would stop running before all packages were downloaded and error

- Will examined the issue with the colcon packages and postulated that the memory allowed for the docker space might be the issue. After messing with the settings a little, I ended up giving Docker an 8GB memory limit and 4GB of Swap (the max for each). This seemed to fix the issue, and I was able to successfully download all the packages.

- I completed the actions tutorial with the turtlebot, and learned how to use rqt_console to view information on the turtlebots collisions and sensor info.


- Learned how to launch multiple nodes from a single file in Ros tutorials
- using code below, a simple script can be ran with the command "ros2 launch turtlesim multisim.launch.py" in the ubuntu terminal to get multiple sims: `# 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'), ])`

- Nobody was able to reach the point in the ros tutorials we set for today, so the deadline was extended until next team meeting in a week (2/20)
- We also started discussing about subteams within our subteam for research and coding purposes
- Subteams:
- ROS2/HELICS integration:
- Build federate that subscribes to and publishes information within the HELICS co-sim
- Skills: C++, HELICS, ROS2
- Physical environment:
- Use Gazebo to simulate a bot in a controlled virtual setting before developing the real-world application of a Line Inspection Robot.
- Skills: C++, ROS2. GAZEBO, Git
- Nodes/sensors on robot:
- Add different nodes and sensors to the robot to improve functionality (cameras etc.)
- Skills: C++, ROS2. GAZEBO, Git
- Mission and trajectory planning:
- Identify possible obstacles the robot might face in its environment
- Create scenarios in which we anticipate challenges (change in weather, wear/tear) and be prepared to solve them
- ROS2/HELICS integration:
- completed the publisher/subscriber tutorial in the ros documentation
- the publisher in one terminal is able to publish topics, that the subscriber in the other terminal can then read from to receive the messages
- this will likely be very important for our ros/helics integration, and its very good that it was included in the tutorial

-
Had a group meeting with Will and updated our plan for the rest of the semester
-
Decided on how we were going to split up into subteams
-
Subteam delegation:
- ROS2/HELICS integration:
- Isabella
- Sabina
- Physical environment:
- Suraj
- Joseph
- Nodes/sensors on robot:
- Isabella, Saffiy
- Mission and trajectory planning:
- Sabina
- Hussein
- Quintin
- ROS2/HELICS integration:
-
Because of the nature of how some subteams require a foundation built by other subteams to work, initially we will all be working on ROS2/HELICS integration and Physical environment to help speed up the process of getting a basis set up. After that, the Nodes/Sensors and mission/trajectory planning subteams will split off and work on their respective duties.
- discussed how the midterm paper would be split up and agreed to be done with everything by 6:00 pm tomorrow
- made this planning document as a group:
- Midterm paper link:
- adjusted the future plans section of our midterm paper to reflect our new future plans (that was my assigned section)
- created a new gantt chart to match
Previous Semester Future Plans Section:
Future Plans Section (previous semester).docx
New Future Plans Section:
New Gantt Chart:

Mid Semester Plan Gantt Chart.xlsx
- we did a group check in to see how far along in the tutorials everybody was
- making good pace, not sure if we are going to do all the tutorials or not but we might at this point because they are much better than we initially thought they would be
- I had to leave to work on a project for my AI class, didn't work for the full class session today
- split up the slides for our IPR1 presentation
- My Slides:
- Why these Tasks?
- Original Timeline
- New Timeline
- Measuring Progress
- My Slides:
- discussed our plan for the rest of the semester
- our original goal was a bit wishful, so we made a more slow paced, concrete plan (detailed on the slides)
- completed my slides for IPR1

(a look into the thought process and reasoning behind our tasks and why they were chosen over other potential options)

(this is from kickoff presentation)

(this is new, also included in midterm paper)
Mid Semester Plan Gantt Chart.xlsx

(this hasn't changed much)
- presented IPR1 to the class
- got a few bits of feedback:
- change goal of making a working arm to just getting one sensor hooked up that can respond to the environment
- long term plan is good, just underestimating the time it'll take to accomplish
- good progress being made with the tutorials, keep it up
- Joseph got gazebo running, and shared it with us during the group meeting
- I replicated it with some guidance during the meeting
- The classic version of gazebo didn't seem to work in ubuntu, so we had to use the newer up-to-date one found here:
- Then i completed the intro tutorial (https://gazebosim.org/docs/all/getstarted) and was able to display shapes in the simulation, nothing too crazy but it's a start

- Sam and Will showed us how we can deduce information from different aspects of a packet captured using applications such as wireshark
-
overall it was pretty interesting, getting to see why data security is important, and how much info can be gained from just a small packet of info broadcasted and overheard
-

different ip addresses sending and receiving packets from each other

strings can reveal a lot, like here we see Robojackets and A-team in the strings, suggesting this is information relating to robots competing, possibly their instructions/controls or the scoring info
- shared our progress with the ros tutorials
- brainstormed ideas for ros/helics integration
- looked at possible resources that might have information on how it could be integrated using existing infrastructure

Helics Source
- revisited publisher subscriber example to see if anything more could be gleamed from it for trying to integrate ros/helics
- edited bash files and other things to see how everything interacts

~ ~ ~ ~ ~ ~ ~ ~ ~ Spring Break ~ ~ ~ ~ ~ ~ ~ ~ ~
- Sabina shared the revelation that she managed to integrate ROS and HELICS over break with help from her internship team! This is huge progress for our subteam, and one of our biggest goals this semester. She created a new repository detailing the steps and code:
- Decided the next step was to integrate gridlab-d and run the cps-cosimulation-env example

- Talked with Will and Safiy about potential future applications and direction of our work as a subteam
- Sensors:
- Magnetometer: magnetic field has a direct relationship with current, so you can calculate current based off of magnetic field, and also any faults would disturb the magnetic field, so its a reliable data point that can be collected from a distance and is accurate. Also would not be too difficult to model.
- Temperature: Can be collected from a distance and is somewhat useful, and easy to model. This was our original idea, but magnetic fields seem to have all the benefits and more, and are just better than temperature.
- LiDAR: Can be used to map terrain height so the robot doesn't get stuck on debris or uneven terrain. The data modeling would be pretty easy, with LiDAR just being a black box at first, but in order to make it more realistic, it could be difficult to accurately represent LiDAR reflecting off surfaces and accounting for different materials diffraction and such.
- Need to consider more what drives the necessity for an autonomous robot. If it's just for constant surveillance, it would be cheaper and more reliable to just have stationary sensors at every point that don't move. How can we make the autonomous maintenance bot a necessity?
- Sensors:
- Decided as a group to do a mini-hackathon next Monday 4:00-6:00pm to try and replicate the ROS/HELICS integration Sabina was able to do over break on each of our machines
- Mini hackathon today. I followed the steps on Sabina's notebook (https://github.com/cps-vip/cps-cosimulation-env/wiki/Sabina-Sokol's-Notebook) and repository (https://github.com/fizzyforever101/ros2-helics/tree/main), but I wasn't able to get the exact same outputs.

- Sabina integrated the two using an older version of ROS then the one we were using, but after some debugging she found the issue and the correct output was starting to display

- She documented the fix in her notebook and on her repository for future members
- No team meeting today since we had the hackathon yesterday
-
I looked into the flags necessary for integrating gridlab-d and HELICS
-
there is a helics_msg object in the connections module that allows gridlab-d to be run as a federate in HELICS cosimulation

- Doesn't seem too difficult, we just need to get it running on people's machines
- We all checked in with each other on how the progress for our respective subteams was going
- We were mostly all able to run Sabina's ROS/HELICS integration, there were some different minor issues for people, but not too bad
- Need to figure out how to update the integration to use the current version of ROS if possible, or see if there'sa way to keep the rolled back version without too many issues *End of semester is coming up, discussed what we will try and accomplish in the last few weeks
- I shared some of the info on the gridlab-d flags for HELICS integration that i found last work session
- Discussed our progress relative to our semester plan, and what we should try to accomplish next semester (more on that in the final presentation)
- Sabina was able to install a GUI using pip that displayed a graph for the data being passed between ROS/HELICS from her integrated simulation (picture from her notebook below)
- This is good progress for our integration as well, we will likely build upon this more next semester

- Split up the slides for our final presentation
- My slides assignment:
- Why Magnetic Fields?
- Reasoning behind our decision to start with magnetic fields in the simulation next semester
- Simulation Starters
- General Roadmap for the big ideas we will try to implement next semester and the order for them
- Measuring Progress
- How we will ensure everyone stays on track (no changes from IPR1, same slide I made then)
- Why Magnetic Fields?
- My slides assignment:
- completed my slides for the final presentation



- presented our final presentation and got feedback
- Will and Sam liked the roadmap I made
- magnetometer and magnetic field is a good starting sensor, as it will not be too complicated to implement but is still very useful
- LiDAR is a good next sensor, as it will be slightly more difficult but will be able to copy some of the magnetometer code and build upon it, but also a robot that can pathfind to magnetic disturbances and avoid obstacles is a great basis, and can be built upon greatly with those requirements out of the way
- Happy with our progress with ROS/HELICS integration, and discussed possibly making changes to the codebase over summer to different libraries and versions for easier progress next semester (to aid with getting our integration to be easily used without too much modification)
- Will and Sam liked the roadmap I made
- Discussed how we would split up the paper sections to be completed, as well as our future plans for next semester
- I was assigned to the applications and roadmap section with Safiy
- Need to make a new Gantt chart, as well as detail why the roadmap has the assigned tasks and time allotted and what goal we are trying to accomplish
- completed my section of the final paper
- Our next semester roadmap (included in my paper section) is displayed below

- Basically a more in-depth plan of what I put in the simulation starter slide for our final presentation
- Add magnetometer and magnetic field data
- Create algorithm that ripples out magnetic field data accurately from disturbances, and then create pathfinding algorithm that can locate the center of a magnetic disturbance and move toward it
- Add LiDAR and terrain height data
- Modify the pathfinding algorithm created with a reward function that avoids big height variations/prefers flat ground, so the robot doesn't get stuck on debris or uneven terrain
- This will create the basis of the robot that future semesters can more easily build upon, with the basis of the robot already set up and the ROS/HELICS integration mostly set up too (there will likely be changes made later to specify it's implementation more to the sensors being used)
- syllabus week, first class VIP meeting
- completed welcome quiz
-
new subteams for this semester were decided based on interest quiz, so we met the new subteam members
-
chose our sub-team meeting days (Mondays at 1pm)
-
discussed kick-off presentation requirements
- prepared for kickoff presentation over discord chat
- revisited my semester plan i created in spring to decide where to add new subteam members and what to focus on this semester

- decided as a team to have Sabina and Safiy on fault detection, Joseph and Shrayes on physical environment, Isabella and Natalie on Nodes and Sensors, and me and Quentin on Mission and Trajectory planning.
- worked on my slides for the kick-off presentation
- fall 2024 semester plan
- simulation starters/foundational items to add to the simulation
- why magnetic fields are our first choice for sensing
- how we will measure progress
- presented in class our kickoff presentation
- Sam and Will shared as part of our feedback that they liked the semester plan, and were happy to see how far we progress by the end of the semester
- Also said our technical descriptions of everything were improving
- first online subteam meeting
- assigned first tasks for each subteam to work on
- I need to come up with things to physically model, as well as possible weather conditions and other issues that may be location specific
-
did some individual research for my task of looking into what we may have to physically model, as well as weather conditions/other possible issues
-
after checking some resources (mainly wikipedia but also a few others https://en.wikipedia.org/wiki/Substation) I think these are the most important things to consider for our model
- Core Components
- Transformers (power and instrument): For voltage/current adjustment and protection
- Switchgear: Circuit breakers and disconnectors for fault response
- Transmission Lines and Busbars: Power distribution nodes
- Fault and Electrical Modeling
- Simulate faults (short circuits, overheating, voltage surges) for testing.
- Power flow and impedance behavior integrated with HELICS and GridLAB-D.
- Monitoring and Sensors
- Protection relays and sensors (magnetometer, voltage, current) for fault detection
- Real-time data integration with ROS/HELICS and the station gateway using DNP3
- Environmental Factors
- Include weather impacts and obstacles (vegetation, nests, ice) for dynamic fault scenarios
- Core Components
-
some of this goes more into device modeling subteam territory, but it gives a good idea of what we need to work on as we start to try to integrate our progress with the device modeling subteam
-
also looked into possible alternative sensors, but megnetometer and LiDar still seem to be the best, most versatile options currently
-
work day. checked in with team members on how they were progressing with their tasks, everybody seemed to be on pace. My semester plans tend to be a bit packed, so I'm trying to gauge whether we are on pace or not so I can consider it while making next semesters plan.
-
Safiy was debating on how to create an interface for ROS-HELICS
- option 1 involves broadcasting all HELICS federates to ROS by converting them into ROS topics. This method is simple to implement, as other ROS nodes can subscribe directly to the converted topics, making it easy to integrate. However, it is computationally inefficient and could become costly in terms of performance.
- option 2 was to treat each ROS node as its own HELICS federate, subscribing to the necessary data from other HELICS federates. While this approach adds some overhead whenever a ROS node needs to interface with HELICS, it is far more efficient and avoids unnecessary computational waste.
-
This is what I understood from his discussion, basically there's an easy way and there's an efficient way. We likely will start with the easy way at first, and switch to the efficient way down the line while cleaning up our sim/refactoring.
- weekly team meeting full semester weekly standup notes
- my subteam (mission trajectory planning) and the nodes sensors subteam were overlapping a bit, because I was also doing some research on the sensors since it affects what missions we can create. It was decided that I should focus just on the stuff that can be modeled in substations so that the two subteams tasks are more clearly differentiated
- other than that no issues, my research into what could be modeled for a substation was well received and taken into consideration for how we could create a connection point with the device modeling team
- while running Sabina's new scripts for the docker image, I listened in to her debate with Safiy about how all the ros/helics federates should be structured, since the code was building most of the time so I couldn't actively do anything.
- Sabina's idea emphasized a centralized control model, where data from GridLAB-D is funneled through a command and control federate, mirroring how faults are typically detected and managed in real-world systems. This approach involves parsing data from GridLAB-D to identify faults and then relaying commands to the ROS system, either via HELICS or directly through ROS topics. It aligns with the real-world flow of fault detection, where centralized systems aggregate information and issue commands based on detected anomalies, so personally I thought this made more sense to model.
- Safiy's approach focused on direct device-robot communication using sensors such as the magnetometer. He thought this would make more sense to implement, as he saw the maintenace robots more as individual entities than as a hivemind. However, this doesn't quite make sense, as while they are individual entities, for them to be most efficiently distributing work among each other and spaced out best for quickest response times, a higher entity must be communicating with all of them to coordinate their efforts.
- Sam and Will got in on the discussion too, and agreed that device fault detection mechanisms are often designed to send data to a central control system. This led to the decision to integrate fault injection into GridLAB-D using an existing module. By injecting faults and routing the data through a centralized federate, the plan now emphasizes creating a system that identifies faults in GridLAB-D and communicates them effectively to ROS, maintaining alignment with the hierarchical structure of real-world fault detection processes.
- I think this is a big step in the right direction for their subteam, and I'm glad I was able to listen to their discussion as this greatly affects the mission trajectory planning subteam's (my subteam) tasks in the future.
- I continued with Sabina's scripts to try and install the new version of the docker image, but I got stuck. I figured it could be an issue with me not doing it all in one sitting, so I restarted from the beginning and still got stuck at the same part. I will discuss this with her next subteam meeting.




- all of these steps worked up until the gridlab d installation below, which wouldn't install properly. there was no error message, but it would kind of freeze for a bit before finishing, and when chceking the gridlab-d version nothing would be returned.

- brought the installation issue with Sabina's scripts to her attention. As it was an online meeting, we decided to try and resolve it thursday in class.
- Discussed the midterm paper
- meeting ended a bit early as we mostly were just working with our subteams to continue our tasks.
- Quentin hasn't really been active for our subteam, I sent him a message to check up on what he's done so far but he hasn't responded yet.
- due to the hurricane, our class meeting was moved to online.
- Sam and Will helped share resources for the Nodes/Sensors subteam, as well as showed all of us some tools that can be used for diagramming instead of draw.io
this week was pretty busy for me with midterms and projects due in other classes, so my progress was a bit lighter than usual
- Safiy made a midterm paper outline
- We didn't really use it, as the existing paper had a better structure, but it was useful in discussing what new info each of us would add or update to the paper
- I worked on the progress and future plans section as always
- Safiy said he ran into the same issue with Sabina's scripts while trying to install the new container, she's been looking into it and will hopefully have a solution soon.
- finished my section of our midterm paper in the morning
- the gantt chart is the same, as we have been keeping up with the plan currently and are progressing at a proper pace, so no changes needed to be made
- I rewrote the section to discuss our current progress and how we were keeping pace with the chart, and I also fully wrote the conclusion section to reiterate our progress and explain how it fits into our more longterm goals with the VIP, and possible future directions we can take as we progress. midterm paper section.docx
- the gantt chart is the same, as we have been keeping up with the plan currently and are progressing at a proper pace, so no changes needed to be made
- Sabina figured out that the issue with the docker installation had to do with the C-make file locations, and once that was resolved I was able to fully install the new container according to the rest of the instructions
- the full example was able to run now:
- discussed how our midterm presentation slides would be split up
- worked on the midterm presentation
- simulations starters/foundations of the sim
- why magnetic fields
- semester plan
- measuring progress
- my slides didn't really change much, as we were progressing at the correct pace to keep up with our semester plan, so I wrote up talking points/ what I would say during the presentation to give a clearer picture of our overall progress and what our next steps/direction might be afterwards. Here is the document: fall 2024 semester plan justification.docx
- we presented in class today
- feedback was that we need to come up with more specific "missions" for the bot, goals for what it can accomplish. this is my subteams task, so I need to communicate with the device modeling team to see what devices they have that we can interact with for missions
- no subteam meeting because of Fall break at Georgia Tech
- class meeting
- decided to pivot more towards fault injection after discussion with Safiy and the fault injection subteam, as that subteam has been making good progress and the nodes/sensors subteam needs a bit more time (new member and a member with a time conflict, so it makes sense)
- planned to send a survey to the device modeling subteam to better understand what devices they have that might be ready for use in our missions and where we might be able to inject potential faults (this task is for my subteam, agreed that I would have it done by monday for our online subteam meeting)
- created the device modeling questionnaire in a word doc
- made sure it could get a comprehensive understanding of any models, and wrote it in a way where it almost asks too many questions, but will make it clear to the device modeling team that if they don't know the answer yet/a question doesn't apply they don't need to respond to it, just answer as best as they could
- checked up on the progress on tasks assigned last thursday in class (shown below)
- shared the device modeling questionnaire and explained how I purposefully made it more in depth then might be necessary just to be safe, but won't require the device modeling team to answer all the questions if they can't/deem it irrelevant
- everyone liked the questionnaire so i put it in the device modeling subteams discord channel with an explanation
- Safiy also proposed the idea to use Jira to track tasks. It looks kind of confusing/convoluted to me, especially for a team that is only 7 people, but it is industry standard so we all joined and added our current tasks.
- we went over to the device modeling subteam and asked them if they could review our questionnaire and send back a response soon
- they said yes they will get to it asap, and they also have some device .glm files they can send over to supplement our understanding of how they implemented their devices
- I will also try to work with the nodes/sensors subteam on navigation, as it has overlap with my subteam (mission trajectory planning) and I also don't really have any subteam specific tasks to complete currently while I wait for the device modeling team's response to the questionnaire i sent them.
- Since I still don't really have anything subteam specific to do until the questionnaire response comes back, I decided to try running the Gazebo sim
- Using this tutorial that Natalie told me about in class yesterday, I was able to get it running in the docker container:

- met and updated each other on progress towards our respective tasks
- the device modeling team also shared their response to the questionnaire i sent them, so i took a look at it independently after our meeting ended
- I couldn't make it to class today due to a family emergency. I looked over the device modeling subteam's response to our questionnaire though later in the night.
- I summarized their response into a more high level format to further discuss next meeting: Summary of Device Modeling Questionnaire Response.docx
- we didn't meet today due to several other members having time conflicts, and instead just updated each other in the discord channel
- agreed to discuss the device modeling team's response to the questionnaire on Thursday
- reviewed the device modeling subteam's survey response as a team and also shared my high level summary with the team and discussed next steps based on this
- moving further into fault injection as it is a good entry point for integration with the device modeling team
- I was unable to make it to our weekly meeting as my registration time was right before it started, so I couldn't join as I was still registering for classes
- the team met briefly to discuss their progress. we are working towards integration by the presentation next week.
-
I was unable to make it to class today because I had a conflicting job interview to attend
-
informed by team that the final presentation was discussed for a bit, and the rest of the time was about integrating Sabina and Safiy's work
-
this was another very slow week for me, as with class registration, job interview prep, and a midterm, I had very little time for VIP. I did check others notebooks and ask them about their progress on their tasks though, just to stay updated. It seems like we are making good progress, it's not quite matching the semester plan because we shifted focus a bit, but it is good progress and at a similar pace as planned. we also should be integrated sufficiently by our presentation next week.
- quick meeting, we just reiterated what slides each of us would be working on
- Sabina and Safiy also shared that after last meeting, they managed to create a new docker image that has everything integrated and set up already, so anybody can just download and run it without running into the issues with the previous method of building gridlab-d and helics on the base image using her previous instructions. This will be great for future members, as it will be much easier to onboard them and have them able to setup much faster.
- they still are having an issue with the permissions for it, so it can't be used by other team members yet, but once the permissions are resolved anyone can use it
- worked on my slides for the final presentation
- these slides were all the same

(left this one in just to show our original plan for comparison to the new one)



(this one is basically the same except JIRA was added to the bottom as another way to check)
- these are the new slides I added:




- the device modeling summary, challenges in mission trajectory planning, and possible scenarios in mission trajectory planning took a lot of the info from my summary of the device modeling team's response, but I also looked back at the actual response and did some research/brainstorming for the possible scenarios as well as the challenges slide.
- the 2025 plan was created because I really felt as though this plan was too big for one semester, and needed to be spilt over 2. It involves finishing up our pending tasks of simulating the magnetic fields and the varying terrain heights, while also finishing our new task that we shifted focus to of fault injection/integration with the device modeling team
- After the 2025 plan is completed, we will have come to a nice point in our progress where we are almost starting fresh again in a new chapter, as we will finally have a good foundation for the simulation in place with full integration between all different parts, as well as integration between the two team's work. We then have freedom to go in really any direction, but I think the next direction would be to start figuring out how the robot will actually perform maintenance. Currently, and up until next year, our main goal is just getting the robot to be able to sense things in the simulation (and also full integration of the simulation), without actual maintenance at this point. I think we've made great progress this semester though, and it's amazing to see how far we've come from the beginning of this VIP last year. Very excited to see how things continue to progress.
- presented our final presentation in class
- got feedback that we should include a high level diagram illustrating how all the different parts of the simulation are interconnected
- created that diagram here
- I got to class a bit late so I explained my reasoning behind the new 2025 plan to Will as well as went over my slides with him after we finished presenting incase my groupmates didn't explain it properly, so he could have a better picture of our progress and future direction
- He said he likes the plan and the direction, and didn't have any changes to recommend
- we decided not to meet due to thanksgiving break, some people had already flown home as well and were spending time with family
- no class because of thanksgiving break
- our last subteam meeting, we decided to finish our paper draft by Tuesday (tomorrow), and use Wednesday to review and submit it
- we discussed what sections each of us would work on
- wished each other luck with finals and end of the semester!
- worked on my sections of the final paper
- IV. Applications and Roadmap: over half of this section is mine, starting from the third paragraph all the way down to the 2025 plan gantt chart, which was shown in the final presentation as well
- V. Conclusion: This whole section was also written by me, to reiterate our progress and how it fits in to our larger goal, as well as clearly define our next steps and the direction we are headed in
- here are my sections in a separate word document, to make it clearer exactly which part of the paper is mine (it's copied exactly from the paper) final paper section.docx
- updated my notebook to be comprehensive of everything this semester
Active Notebooks
- Aditi Kulkarni's Notebook
- Aly Aadil Salewala's Notebook
- Carter Pattison's Notebook
- Christopher Gossmann's Notebook
- Esha Pansara's Notebook
- Estelle Jung's Notebook
- Favour Adekola's Notebook
- Galadriel Cho's Notebook
- Prisha Baravkar's Notebook
- Rishika Vunnama's Notebook
- Ryosuke Shibuya's notebook
- Txaber Trevino's Notebook
- Zeus Banda's Notebook
Archive
- Adam McAndrews Notebook
- Albert Nguyen Notebook
- Alexander Rice's Notebook
- Amani Bedwa's Notebook
- Aparupa Brahma's Notebook
- Arya Gujarathi's Notebook
- Bermet Talantbekova's Notebook
- Calvin Rioux's Notebook
- Christina Shih Notebook
- Chungman Kim's NoteBook
- Connor McCary's Notebook
- Dhruv Patels Virtual Notebook
- Elliot Kantor's Notebook
- Ethan Lee Notebook
- Filippos Notebook
- Gweneth Smith's Notebook
- Hubert Pan's Notebook
- Hussein Rmaile Notebook
- Isabella Jemal's Notebook
- Joseph Masson's Notebook
- Jude Karaki Notebook
- Kaden McCartney's Notebook
- Maria Cymbalyuk's Notebook
- Natalie Ajemian's Notebook
- Nguyen Nguyen's Notebook
- Nicholas Reed's NoteBook
- Piper Wright's Notebook
- Quintin's notebook
- Rahil's Notebook
- Raj Patel Notebook
- Reva Hajarnis Notebook
- Rick Berglund's Notebook
- Rossy's Notebook
- Sabina Sokol's Notebook
- Safiy Malik Notebook
- Sam Ling's Notebook
- Sam Litchfield Example Notebook
- Shrayes Upadhyayula Notebook
- Soyoung Moon's Notebook
- Suraj Shekar Notebook
- Vidur Modgil's Notebook
- Xin Zhao Notebook
- Xinyan(Rose) Jiang's Notebook
- Zaeem Ahmad Notebook