# Rutuparna Ratnakar Kulkarni > Engineering portfolio for Rutuparna Ratnakar Kulkarni, a Mechatronics & Automation Engineer working across robotics, intelligent systems, controls, perception, embedded engineering and mechanical design. ## Canonical pages - [Portfolio](https://krutuparna.in/) - [Engineering Work](https://krutuparna.in/projects) - [GitHub](https://github.com/K-Rutuparna1087) - [LinkedIn](https://www.linkedin.com/in/krutuparnar) - [Medium](https://medium.com/@k.rutuparna.r) ## Engineering focus Robotics, mechatronics, automation, control systems, computer vision and perception, embedded systems, mechanical design, simulation, intelligent systems and physical AI. ## Documentation model Projects are documented using the ORBIT method: Outline, Research, Build, Iterate and Transform. Each project page is the canonical source for its documented scope, technologies, evidence, results and limitations. The machine-readable project descriptions below are derived directly from the portfolio's project inventory. ## Engineering projects ### [Screw Tightening Bot](https://krutuparna.in/projects/screw-tightening-bot) - Subtitle: Vision-guided Cartesian gantry for automated screw-driving in simulation. - Status: Prototype / In Progress - Type: Type C — Complex Engineering System - Domains: Robotics, Control, Perception, Systems Engineering - Technologies: ROS 2 Jazzy, Gazebo Sim, URDF, RViz2, Python, TCP / JSON - Summary: A 3-DOF Cartesian gantry workcell designed around a detect → target → move → drive → retract automation loop. Vision detections are bridged over TCP into ROS 2 and consumed by a motion state machine. - ORBIT documentation: 01 OUTLINE: Problem: Automate screw positioning and tightening from an external vision process without requiring a physical robot for the first integration stage. Objectives: Model the gantry, implement a tightening-cycle state machine, bridge vision detections into ROS 2, and demonstrate the industrial automation flow in simulation. Constraints: Simulation only. The URDF is visual-only with no inertial or collision definitions, so the system does not claim physical dynamics or hardware validation. 02 RESEARCH: Background: ROS 2 Jazzy, Gazebo Sim and the ros_gz_sim integration provide the simulation stack. TCP/JSON was selected as the external vision bridge. Engineering Decisions: A socket bridge was chosen over a direct DDS integration to keep the external vision process simple and decoupled from ROS. Trade-offs: The simulation provides fast integration feedback but does not represent actuator dynamics, collision response, or physical tightening torque. 03 BUILD: Architecture: Vision process → TCP receiver → /target_xy → motion state machine → /joint_states → robot_state_publisher / Gazebo. Robot Model: Three prismatic axes: X and Y travel ±0.2 m; Z travels −0.15 to 0 m. The tightening target is z = −0.10 m. Motion Control: IDLE → MOVE_XY → Z_DOWN → HOLD → Z_UP → IDLE. HOLD is approximately 3 seconds using a 10 Hz timer. Vision Bridge: Two receiver generations exist: an older {x,y} schema and a newer line-delimited detections[] schema using offset_x/offset_y. 04 ITERATE: Experiments: Gazebo spawning, TF export, deterministic target sequences and repeated colcon builds were used to validate the ROS graph and simulation scaffolding. Failures: The last logged motion_node run exited with code 1. The live vision → motion path was not closed, and the two socket schemas were not reconciled. Changes: The receiver evolved from a blocking single-target socket node to a threaded line-delimited receiver matching the intended screw detector output. 05 TRANSFORM: Results: The workspace builds and the simulation scaffolding runs. The architecture demonstrates the intended industrial automation pipeline, but no closed-loop execution metric was recorded. Limitations: No physical hardware, no dynamics, no positioning accuracy measurement, unfinished vision-to-motion integration and unresolved socket protocol divergence. Future Work: Reconcile the socket contract, restore the motion node in the main launch path, add inertia/collision, then validate the closed loop. - Evidence: URDF and ROS 2 packages; motion_node.py / target_node.py / receiver.py; Gazebo launch and TF export; colcon build and ROS runtime logs - References: PROJECT_INVENTORY.md; Source project documentation; Official library/tool documentation where applicable - Related projects: 3-Axis Gantry Robot; Gear Defect Detector ### [3-Axis Gantry Robot](https://krutuparna.in/projects/3-axis-gantry-robot) - Subtitle: Parametric Cartesian robot model with staged trajectory generation. - Status: Working / Superseded - Type: Type B — Standard Engineering System - Domains: Robotics, Control, Mechanical - Technologies: ROS 2 Jazzy, xacro, URDF, RViz2, colcon, Python - Summary: A reusable 3-DOF Cartesian gantry workspace that converts a target point into a staged Y → X → Z → hold → retract trajectory and visualizes the robot in RViz. - ORBIT documentation: 01 OUTLINE: Problem: Create a clean ROS 2 workspace for a Cartesian gantry and make its motion graph easy to exercise and inspect. Objectives: Author a parametric xacro/URDF, publish joint trajectories, provide a fake target generator and package a repeatable RViz launch. Constraints: Visual/kinematic simulation only. No ros2_control, inertial model or Gazebo dynamics in this workspace. 02 RESEARCH: Background: ROS 2 trajectory_msgs, JointTrajectory, xacro and standard robot_state_publisher workflows. Modeling Decision: A parametric xacro model was used instead of exporting a solid CAD assembly so dimensions and links remain easy to modify. 03 BUILD: Robot Model: base_link, y_frame, left_limb, z_frame and tool_head with Y, Z and X prismatic joints. Controller: controller_node.py consumes /target_pose and publishes a three-joint JointTrajectory through five ordered stages. Test Harness: fake_target.py publishes random X/Y targets every 3 seconds inside the ±0.05 m range. 04 ITERATE: Validation: The workspace was built repeatedly and RViz sessions were recorded. Limitations: The published JointTrajectory is not consumed by a ros2_control controller; the robot remains visual-only. 05 TRANSFORM: Results: Sixteen successive colcon build logs and repeated RViz sessions support the working kinematic demonstration. Future Work: Add ros2_control, Gazebo physics, collision/inertial properties and a physical demo. - Evidence: gantry.xacro / gantry.urdf; controller_node.py / fake_target.py; launch and RViz configuration; 16 colcon build logs - References: PROJECT_INVENTORY.md; Source project documentation; Official library/tool documentation where applicable - Related projects: Screw Tightening Bot ### [Bolt Turn Counter](https://krutuparna.in/projects/bolt-turn-counter) - Subtitle: Real-time ratchet-aware turn counting from hand landmarks. - Status: Working / Active Research - Type: Type D — Research / Measurement Tool - Domains: Perception, Robot Intelligence, Controls - Technologies: MediaPipe Tasks, scikit-learn, Random Forest, OpenCV, NumPy, Python - Summary: A webcam-based measurement tool that classifies tightening grips and accumulates clockwise fingertip rotation while ignoring ratchet return strokes. - ORBIT documentation: 01 OUTLINE: Problem: Manual bolt tightening is difficult to quantify consistently from an ordinary camera feed. Objectives: Count tightening turns, ignore counter-clockwise return strokes, classify tightening state and preserve auditable session logs. 02 RESEARCH: Hypothesis: Finger landmark geometry can provide a stable signal for grip classification while angular motion around the palm can represent tightening turns. References: MediaPipe HandLandmarker and scikit-learn Random Forest form the core perception stack; the tool is also Case Study 1 in the manufacturing-skill-development manuscript. 03 BUILD: Feature Engineering: A 75-dimensional vector combines 63 wrist-normalized landmark coordinates with 12 fingertip-distance features. Classifier: RandomForestClassifier with 300 trees and max_depth 18. Synthetic training covers four grip classes across 0–360° rotations. Ratchet Logic: Signed angular deltas handle wraparound; changes below 0.8° are ignored; only clockwise sweep contributes to cw_total and turns = cw_total / 360°. 04 ITERATE: Validation: Held-out synthetic rotation angles produced 95.21% grip-classifier accuracy. Earlier runs recorded 94.79%. Validation Gap: No independent ground-truth experiment was found for end-to-end physical turn-count accuracy. Limitations: Supervision is synthetic and the classifier is rebuilt at startup rather than using persistent model weights. 05 TRANSFORM: Result: A working real-time measurement instrument with session logging, HUD feedback and a repeatable classifier evaluation path. Future Work: Collect real grip data, validate turn counts against instrumented tightening hardware and integrate with the robot workcell. - Evidence: accuracy CSVs; session CSV logs; ml_classifier.py / turn_tracker.py / main.py; hand_landmarker.task - References: JMS manufacturing-skill-development manuscript; MediaPipe HandLandmarker documentation; scikit-learn documentation - Related projects: Transformer Assembly AR Training Tool; Gear Defect Detector ### [Gear Defect Detector](https://krutuparna.in/projects/gear-defect-detector) - Subtitle: YOLOv8 detection, tracking and HSV component-vision pipeline. - Status: In Progress / Interrupted - Type: Type F — Prototype / Experiment - Domains: Perception, AI, Robotics - Technologies: YOLOv8, Ultralytics, OpenCV, SORT, PyTorch, CUDA - Summary: A computer-vision pipeline assembled around a two-class gear dataset, YOLOv8n training, multi-object tracking and an HSV screw/component detector intended to feed the Screw Tightening Bot. - ORBIT documentation: 01 OUTLINE: Problem: Detect gear defects and provide a vision feed for downstream automation. Objectives: Train a lightweight detector, run inference/tracking and provide a complementary color-based component detector. 02 RESEARCH: Dataset: Roboflow export with defect and gear classes: 830 train, 20 validation and 99 test images. Stack: YOLOv8n for detection, custom nearest-centroid tracking plus vendored SORT, and HSV segmentation for screws/components. 03 BUILD: Training: src/train.py configures YOLOv8n for 50 epochs at 640 px with the recorded training configuration. Tracking: track.py contains a lightweight centroid tracker and the vendored SORT implementation. Screw Detection: HSV segmentation uses color masks, morphology and contours to output bounding boxes and centroids for the intended robot bridge. 04 ITERATE: Primary Failure: The training directory exists but best.pt and last.pt are missing. Therefore no detection metric is claimed. Integration Gap: The tracker currently hard-codes DEFECT for tracked boxes and the screw-detector socket integration remains unfinished. 05 TRANSFORM: Result: The pipeline architecture, dataset configuration and inference/tracking code are in place, but the trained detector is not available for a defensible performance claim. Future Work: Re-run training, preserve weights, benchmark mAP/precision/recall, fix class propagation and close the Screw Bot bridge. - Evidence: dataset split and labels; train.py / detect.py / track.py; training args.yaml; screw_detection.py - References: Roboflow dataset export (CC BY 4.0); Ultralytics YOLO documentation; SORT repository / implementation - Related projects: Screw Tightening Bot ### [AI Gear Failure Prediction System](https://krutuparna.in/projects/gear-failure-prediction) - Subtitle: Multi-output XGBoost system for gear failure stress and crack depth. - Status: Completed / Deliverable - Type: Type E — Deployed / Interactive - Domains: AI, Mechanical, Controls - Technologies: XGBoost, scikit-learn, Streamlit, Plotly, Pandas, NumPy - Summary: A predictive-maintenance dashboard that estimates gear failure stress and crack depth from geometry, classifies a maintenance state and generates engineering recommendations. - ORBIT documentation: 01 OUTLINE: Problem: Turn basic gear geometry into a fast, quantifiable failure-risk estimate for predictive maintenance. Objectives: Train multi-output models, classify failure modes and expose the result through an operator-oriented dashboard. 02 RESEARCH: Feature Engineering: Raw module, face width and tooth count are augmented with module×teeth, width×module and width/(teeth+1). Modeling: MultiOutputRegressor with XGBRegressor learns failure depth and normalized failure stress. A deterministic rule maps predicted values to maintenance states. 03 BUILD: Models: Driver and driven models use 1,000 estimators, learning_rate 0.01, max_depth 8, subsample 0.8 and colsample_bytree 0.8. Dashboard: Streamlit provides sliders, engineered-feature inspection, Plotly stress gauge, diagnosis and recommendations, with a deterministic fallback if model loading fails. 04 ITERATE: Measured Results: The persisted classification report covers 1,607 samples. Important Caveat: Failure classes are derived from the same predicted stress/depth values used by the rule, so 91% is not independent field-validation accuracy. Evidence Gaps: Regression R²/MAE were printed during training but were not persisted; dataset provenance is also undocumented. 05 TRANSFORM: Result: A functional, styled engineering dashboard that connects ML predictions to an inspectable maintenance decision path. Future Work: Validate against real telemetry, preserve regression metrics, document dataset provenance and expand failure classes. - Evidence: model_driver.pkl / model_driven.pkl; 1,607-row driver and driven datasets; classification_report.txt; app.py and training scripts - References: XGBoost documentation; scikit-learn documentation; Streamlit / Plotly documentation - Related projects: Gear Contact Mechanics ML; Turbofan RUL Prediction ### [Gear Contact Mechanics ML](https://krutuparna.in/projects/gear-contact-mechanics-ml) - Subtitle: GearAnalyst Pro: ML prediction of contact stress and crack depth. - Status: Completed - Type: Type C — Complex Engineering Analysis - Domains: Mechanical, AI, Controls - Technologies: scikit-learn, Python, Streamlit, Plotly, pandas, NumPy - Summary: A refactored ML pipeline that cleans material-pair data, engineers an equivalent stiffness feature, benchmarks multiple model families and packages the analysis as an engineering dashboard. - ORBIT documentation: 01 OUTLINE: Problem: Predict contact stress and crack-propagation depth from gear material properties and load. Objectives: Build a reproducible cleaning/feature pipeline, compare regressors and classifiers, and ship the analysis as GearAnalyst Pro. 02 RESEARCH: Background: The pipeline combines driver/driven Young’s modulus, Poisson ratio, proportional limits, load and face width. Model Comparison: Linear Regression, Random Forest, Gradient Boosting and SVR are compared under a fixed 80/20 split with random_state 42. 03 BUILD: Data Pipeline: Messy material-pair inputs are normalized, parsed, coerced to numeric and transformed into a 100-row, 13-column processed dataset. Models: Stress and depth use multiple regressors; failure classification uses Logistic Regression, Random Forest, Gradient Boosting and SVM. Engineering Tool: GearAnalyst Pro exposes material/load inputs, predictions, geometry factor and out-of-range warnings. 04 ITERATE: Stress Benchmark: Linear Regression is the strongest stress model. Depth Benchmark: SVR is the strongest depth model. Negative Result: SVR performs poorly on stress with R² = −0.096, demonstrating model-family sensitivity. 05 TRANSFORM: Result: The investigation became an inspectable engineering tool with persisted models, metrics and plots rather than a notebook-only experiment. Limitations: Only 100 processed samples are available; failure labels are derived from stress bins and the raw-data provenance is undocumented. Future Work: Validate against strain-gauge data and quantify generalization outside the training distribution. - Evidence: final_dataset.csv; metrics.csv / final_metrics.csv; saved model .pkl artifacts; plots and app.py - References: scikit-learn documentation; Streamlit / Plotly documentation; Source project datasets and scripts - Related projects: Gear Failure Prediction System ### [Knee Joint Dynamics Extraction Pipeline](https://krutuparna.in/projects/knee-joint-dynamics) - Subtitle: IMU-to-mechanics system identification for a spring-mass-damper knee model. - Status: Completed - Type: Type D — Research / Scientific - Domains: Mechanical, Controls, AI, Signal Processing - Technologies: Python, NumPy, SciPy, pandas, matplotlib - Summary: A reusable pipeline that converts 6-axis IMU leg-swing recordings into frequency, damping, stiffness, torque and ACL/PCL stiffness estimates using a second-order model. - ORBIT documentation: 01 OUTLINE: Problem: Extract physically meaningful knee dynamics from free leg-swing IMU recordings. Objectives: Filter signals, detect oscillations, estimate frequency/damping/stiffness/torque and split total stiffness between ACL and PCL. Assumptions: Leg mass 4.5 kg, leg length 0.4 m and a 45/55 ACL/PCL split are fixed model assumptions. 02 RESEARCH: Signal Processing: Moving average, Butterworth low-pass and Savitzky-Golay filters are compared before peak-based parameter estimation. Mechanical Model: A second-order spring-mass-damper formulation maps oscillation period and log decrement to frequency, damping and stiffness. 03 BUILD: Pipeline: Raw IMU CSV → preprocessing → filter → peak detection → frequency/damping → parameter estimation → motion/torque reconstruction → JSON/CSV/plots. Implementation: The preprocessing, signal-analysis, motion, ligament-split, parameter-estimation, loader and reporting modules were authored for the project. 04 ITERATE: Measured Segment: The reference segment produced consistent mechanical estimates. Cross-Axis Check: A Z-gyro result gave approximately 1.840 Hz and 601.8 N/m, supporting cross-axis consistency for that segment. Failure Modes: Some paths produce NaN damping when successive peaks do not decay monotonically; segments with fewer than two peaks are skipped. 05 TRANSFORM: Result: The pipeline turns raw sensor time series into reusable mechanical parameters and persisted analysis artifacts across multiple trials. Limitations: The model is a simplified biomechanical approximation and validation is synthetic/model-based rather than clinical. Future Work: Correlate estimates with real biomechanical measurements and explore real-time feedback control. - Evidence: raw and processed IMU CSVs; results.json files; plots and motion_features.csv; source modules - References: SciPy documentation; NumPy / pandas documentation; Source project README and reports - Related projects: NeuroLog EEG Acquisition ### [Transformer Assembly AR Training Tool](https://krutuparna.in/projects/transformer-assembly-ar) - Subtitle: Image-classification-assisted augmented reality training for transformer assembly. - Status: Built / Prototype - Type: Type E — Deployed / Interactive Prototype - Domains: Mechanical, Perception, Robotics, Electrical - Technologies: SolidWorks, Teachable Machine, TensorFlow Lite, Unity, Vuforia - Summary: An AR-guided assembly trainer combining SolidWorks parts, a lightweight image classifier and Unity/Vuforia overlays. It was developed as Case Study 2 for the manufacturing research manuscript. - ORBIT documentation: 01 OUTLINE: Problem: Manual transformer-assembly guides are not interactive and can make technical training harder to follow. Objectives: Create an AR-guided trainer using mechanical CAD, image classification and Unity/Vuforia overlays. 02 RESEARCH: Background: The system combines SolidWorks CAD, Teachable Machine image classification and Vuforia image-target workflows. Design Decision: Vuforia Model Target Generator was evaluated and rejected for this context; the prototype used a basic image-target/classifier approach. 03 BUILD: Mechanical / CAD: Four SolidWorks parts were documented: Case, final transformer, core and case, and plate variants. Intelligence: A Teachable Machine model is stored as model.tflite with labels.txt. AR Deployment: Unity + Vuforia produced fast and slow demonstration videos rather than a live deployed application. 04 ITERATE: Experiment: AR demonstrations were produced and the Vuforia MTG path was evaluated and rejected as insufficiently robust. Limitations: No measured AR usability metric or classifier accuracy is recorded, and no live deployment URL exists. 05 TRANSFORM: Result: Four CAD parts, a deployable TFLite model and two AR demonstration videos form a complete prototype case study. Future Work: Run real usability studies, train a custom model and add explicit assembly-step sequencing. - Evidence: 4 SLDPRT files; model.tflite / labels.txt; 2 MP4 demo videos; rejected MTG artifacts - References: JMS Journal Manuscript; SolidWorks documentation; Google Teachable Machine; TensorFlow Lite; Unity / Vuforia - Related projects: Bolt Turn Counter; Screw Tightening Bot ### [KrushiAksh](https://krutuparna.in/projects/krushiaksh) - Subtitle: Crop suitability recommendation pipeline with portable ONNX inference. - Status: Completed - Type: Type B — Standard ML Pipeline - Domains: AI, Mechanical / 3D, Robotics - Technologies: scikit-learn, Random Forest, skl2onnx, ONNX Runtime, Blender, NumPy / pandas - Summary: A crop-recommendation pipeline that maps soil N/P/K conditions to suitable crops, exports the model to ONNX and pairs the inference workflow with Blender assets. - ORBIT documentation: 01 OUTLINE: Problem: Match soil nutrient conditions to suitable crop recommendations. Objectives: Train a Random Forest recommender, export it through skl2onnx and preserve 3D crop assets. 02 RESEARCH: Background: The project explores soil-crop suitability and portable ONNX Runtime inference. Pipeline Decision: The workflow is sklearn → skl2onnx → onnxruntime, with a large grid sweep used to preserve recommendation outcomes. 03 BUILD: Model: crop_model.onnx is the exported inference artifact. Inference: train.py and predict.py implement training and ONNX Runtime inference. 3D Assets: Blender .blend/.fbx assets include maize and rice models. 04 ITERATE: Validation: The ONNX inference path and grid-sweep results were preserved. Scale: The heavy result CSV covers approximately 3.2 million nutrient combinations. 05 TRANSFORM: Result: A complete train → ONNX → predict pipeline with accompanying 3D assets. Limitations: Dataset coverage is the main stated limitation; no live web demo is documented. Future Work: Deploy as an embedded/mobile inference endpoint and add crop classes. - Evidence: crop_model.onnx; data.csv; success_results_heavy.csv; train.py / predict.py; Blender .blend/.fbx - References: scikit-learn documentation; skl2onnx documentation; ONNX Runtime documentation; Source project report - Related projects: Gear Contact Mechanics ML ### [NeuroLog](https://krutuparna.in/projects/neurolog-eeg) - Subtitle: Desktop EEG acquisition and session-logging application. - Status: Working - Type: Type C — Hardware Data Acquisition - Domains: Electrical, Embedded, AI / Signal - Technologies: Python, PyQt6, websocket-client, MNE, NumPy, matplotlib - Summary: A desktop application for real-time EEG acquisition from an Emotiv EPOC X+, live waveform display, session logging and export to CSV, NPY and FIF formats. - ORBIT documentation: 01 OUTLINE: Problem: Real-time EEG acquisition from the Emotiv headset needs a practical desktop interface for sessions and data capture. Objectives: Provide a PyQt6 GUI, live waveform display, session logging and research-friendly exports. 02 RESEARCH: Hardware Interface: The application connects to the Emotiv Cortex WebSocket API at the local wss endpoint. Data Strategy: MNE-compatible FIF plus CSV and NPY exports keep the captured signal useful for downstream analysis. 03 BUILD: Software: app.py, api.py, gui.py and recorder.py separate acquisition, interface and persistence responsibilities. Hardware: Emotiv EPOC X+ provides 14 channels at 256 Hz. Recorded Sessions: Seven real sessions were captured and accompanied by per-session metadata JSON. 04 ITERATE: Validation: Real recordings and session metadata demonstrate that the acquisition path is operational. Changes: Manual markers were added and export formats expanded. Scope Boundary: Signal classification and higher-level processing are intentionally not yet part of the current application. 05 TRANSFORM: Result: A working desktop EEG acquisition system with real recorded data. Future Work: Add real-time feature extraction and classification, then expose the data through a web dashboard if appropriate. - Evidence: app.py / api.py / gui.py / recorder.py; 7 session recording sets; CSV / NPY / FIF exports - References: Emotiv Cortex documentation; MNE documentation; PyQt6 / websocket-client documentation - Related projects: Knee Joint Dynamics ### [Turbofan RUL Prediction](https://krutuparna.in/projects/turbofan-rul) - Subtitle: NASA CMAPSS remaining-useful-life prediction baseline and transfer-learning study. - Status: Completed - Type: Type D — ML Research / Predictive Maintenance - Domains: AI, Controls, Mechanical - Technologies: Keras, TensorFlow, NASA CMAPSS - Summary: A coursework-level predictive-maintenance project comparing a Keras baseline with a transfer-learning variant for turbofan remaining useful life prediction. - ORBIT documentation: 01 OUTLINE: Problem: Predict remaining useful life of turbofan engines from multivariate sensor data. Objectives: Train a baseline and transfer-learning variant while preserving trained weights and benchmark data. 02 RESEARCH: Dataset: NASA CMAPSS FD001–FD004 train/test data and RUL target files form the benchmark. Comparison: Baseline and transfer-learning architectures were considered as the main experimental contrast. 03 BUILD: Model: baseline_model.h5 preserves trained weights; TL_Model.py contains the transfer-learning variant. Implementation: Baseline_model.py and supporting data files preserve the reproducible coursework artifact set. 04 ITERATE: Validation: The trained weights and full benchmark dataset evidence remain available. Metrics Boundary: The source inventory does not contain a persisted metrics report, so no numeric performance claim is made here. 05 TRANSFORM: Result: A completed baseline/TL predictive-maintenance study with trained artifacts and benchmark data. Limitations: Coursework-level scope, no live deployment and no extended validation beyond the documented dataset split. Future Work: Integrate live sensor feeds and expose the model through an API or dashboard. - Evidence: baseline_model.h5; Baseline_model.py / TL_Model.py; FD001–FD004 datasets and RUL files - References: NASA CMAPSS documentation; Keras / TensorFlow documentation; Damage-propagation paper included with source - Related projects: Gear Failure Prediction ### [IRA](https://krutuparna.in/projects/ira-llm-cli) - Subtitle: Persona-based LLM agent CLI with persistent SQLite memory. - Status: Complete — v0.1.0 - Type: Type B — Software / AI Agent System - Domains: Robot Intelligence, AI - Technologies: Python, google-genai, Groq, Click, PyYAML, SQLite - Summary: A command-line LLM agent with persona/runtime contracts, persistent SQLite memory and dual Gemini/Groq backends. - ORBIT documentation: 01 OUTLINE: Problem: Build a local agent interface that retains persona-oriented context between CLI sessions. Objectives: Provide a CLI, persistent memory, multiple model backends and a structured runtime/persona contract. 02 RESEARCH: Background: The design combines CLI agent patterns, SQLite persistence and YAML-based persona/runtime configuration. Architecture Decision: Click provides the CLI surface; Gemini and Groq provide interchangeable model backends. 03 BUILD: Package: pyproject.toml exposes the ira console entry point. Memory: Persistent state is stored in a local SQLite memory database. Runtime Contract: A YAML contract defines persona/runtime behavior separately from implementation code. 04 ITERATE: Validation: The package is installed in its virtual environment with egg-info and the runtime contract present. Scope Boundary: It is a software/AI project rather than a robotics deliverable and is not deployed as a server/API. 05 TRANSFORM: Result: A functional local agent CLI with persistent memory and dual backend support. Future Work: Add a tool-use framework and deploy the agent as a server when required. - Evidence: IRA package source; pyproject.toml; runtime_contract.yaml; egg-info and environment artifacts - References: Click documentation; Google GenAI documentation; Groq documentation; SQLite / PyYAML documentation - Related projects: Bolt Turn Counter; Gear Defect Detector ### [ros_gz CLI](https://krutuparna.in/projects/ros-gz-scaffold) - Subtitle: ROS 2–Gazebo scaffolding CLI for repeatable package creation. - Status: Released — v0.1.0 - Type: Type A — Micro / Developer Tool - Domains: Robotics, Controls & Automation - Technologies: Python, Click, setuptools, ROS 2, Gazebo - Summary: A small CLI that generates ROS 2–Gazebo package structures for ament_cmake, ament_python and ament_pyc projects. - ORBIT documentation: 01 OUTLINE: Problem: Creating standard ROS 2 package trees repeatedly is mechanical and error-prone. Objectives: Expose a simple ros_gz