Editorial: remove generic promotional language from portfolio

src/_includes/base.njk

@@ -96,7 +96,7 @@
 
   <footer class="site-footer">
     <div class="container footer-grid">
-      <p>© <span id="year"></span> {{ site.name }}. Built with Eleventy and stubborn engineering taste.</p>
+      <p>© <span id="year"></span> {{ site.name }}. Built with Eleventy.</p>
       <a href="#page-top">Back to top ↑</a>
     </div>
   </footer>

src/index.njk

@@ -11,7 +11,7 @@ heroCanvas: true
       <div class="hero-copy">
         <p class="eyebrow">Mechatronics Engineering Student · Muscat, Oman</p>
         <p class="status-pill"><span class="status-dot" aria-hidden="true"></span>Currently: Research Assistant — soft robotic rehabilitation, SQU</p>
-        <h1>Embedded control, electropneumatics, and robotics that <em class="grad-text">survive the bench</em>.</h1>
+        <h1>Embedded control, electropneumatics, and <em class="grad-text">robotics</em>.</h1>
         <p class="hero-lede">
           I am a Mechatronics Engineering student at Sultan Qaboos University focused on practical hardware-software systems: soft robotics, sensor feedback, pneumatic actuation, control logic, CAD design, and technical documentation.
         </p>
@@ -62,11 +62,11 @@ heroCanvas: true
     <div class="container split-section">
       <div class="section-heading" data-reveal="left">
         <p class="eyebrow">About</p>
-        <h2>Engineering is where ideas meet wiring, tolerances, and inconvenient reality.</h2>
+        <h2>Embedded control, pneumatic actuation, and mechanical design.</h2>
       </div>
       <div class="content-stack" data-reveal>
-        <p>My work sits at the intersection of mechanical design, embedded firmware, controls, and pneumatic actuation. I enjoy building systems that move, sense, respond, and provide measurable feedback rather than remaining as clean diagrams on paper.</p>
-        <p>I value clear documentation, practical testing, and honest limitations. A design that works only in a slide deck is decoration; a design that survives troubleshooting earns respect.</p>
+        <p>I develop controller firmware, sensor interfaces, pneumatic actuation systems, and mechanical designs. My projects include physical prototypes, simulations, and measurement-based testing.</p>
+        <p>I document system architectures, test setups, measurements, and limitations alongside the designs.</p>
         <div class="signal-row" aria-label="Research interests">
           <span>Soft robotic actuation</span>
           <span>Tele-rehabilitation</span>
@@ -81,7 +81,7 @@ heroCanvas: true
     <div class="container">
       <div class="section-heading wide" data-reveal>
         <p class="eyebrow">Selected Engineering Projects</p>
-        <h2>A few representative builds — hardware, firmware, CAD, testing, and documentation.</h2>
+        <h2>Selected projects in controls, robotics, and mechanical design.</h2>
       </div>
 
       <div class="project-grid">
@@ -123,7 +123,7 @@ heroCanvas: true
     <div class="container split-section">
       <div class="section-heading" data-reveal="left">
         <p class="eyebrow">Research &amp; Leadership</p>
-        <h2>Research and student leadership with real technical responsibility.</h2>
+        <h2>Research and student leadership.</h2>
       </div>
       <div class="timeline">
         <article class="timeline-item" data-reveal>
@@ -154,7 +154,7 @@ heroCanvas: true
     <div class="container">
       <div class="section-heading wide" data-reveal>
         <p class="eyebrow">Technical Stack</p>
-        <h2>Skills grouped by how they are used in real systems.</h2>
+        <h2>Firmware, control, modelling, and design.</h2>
       </div>
       <div class="skills-grid">
         <article class="skill-card" data-reveal style="--si: 0"><h3>Embedded &amp; Control</h3><p>C/C++, Python, MATLAB, ESP32, Arduino, AVR, ROS 2, micro-ROS, serial telemetry, sensor interfacing, finite-state machines, control systems.</p></article>
@@ -187,8 +187,8 @@ heroCanvas: true
   <section class="section-pad contact-section" id="contact">
     <div class="container contact-card" data-reveal="scale">
       <p class="eyebrow">Contact</p>
-      <h2>Interested in embedded systems, robotics, controls, or research collaboration?</h2>
-      <p>I'm open to graduate research opportunities and collaborations in robotics, control, and soft-robotic systems. Reach me by email, LinkedIn, or GitHub — phone is kept off the public site to spare it from spam bots.</p>
+      <h2>Research and engineering collaboration.</h2>
+      <p>I'm open to graduate research and collaborations in robotics, control, and soft robotic systems. Contact me by email, LinkedIn, or GitHub.</p>
       <div class="contact-actions">
         <a class="button button-primary" href="mailto:{{ site.email }}">Email me</a>
         <button class="button button-secondary copy-email" type="button" data-email="{{ site.email }}" data-label="Copy email" aria-live="polite">Copy email</button>

src/projects/data-acquisition.md

@@ -24,7 +24,7 @@ facts:
     detail: "AC-bridge analysis, linearity-error budget, analog signal-conditioning design."
 sections:
   - eyebrow: Brief
-    heading: "A voltage is not a measurement until you design the whole chain."
+    heading: "AC-bridge displacement measurement and signal conditioning."
     body: |
       The task was to take a **non-contact displacement transducer (NCDT)** — whose inductance
       shifts only slightly as a target moves — and design the full instrumentation path that
@@ -47,7 +47,7 @@ sections:
       sinusoidal source. The differential output works out to `V₀ = Vₛ · kx / (1 − (kx)²)`,
       which for small displacement collapses to the clean linear law **`V₀ ≈ Vₛ · kx`**.
   - eyebrow: Error Budget
-    heading: "Quantify the nonlinearity instead of hand-waving it."
+    heading: "Estimate the bridge's nonlinearity."
     body: |
       Linearity is treated as a number, not an adjective. The small-displacement approximation
       contributes ≈ **1.01%** error at `kx = 0.1`; air-gap reluctance adds a magnetic
@@ -65,10 +65,4 @@ sections:
         displacement maps to the target **100 mV**;
       - a **2nd-order active low-pass filter (f_c = 20 Hz)** strips the AC carrier ripple and
         high-frequency noise, leaving a steady DC reading.
-  - eyebrow: Value
-    heading: "Measurement fundamentals, done properly."
-    body: |
-      Sensor modelling, bridge analysis, an explicit error budget, and a complete
-      conditioning chain — the unglamorous core of instrumentation, and the difference between
-      *reading* a sensor and actually *measuring* something with it.
 ---

src/projects/glove-dashboard.md

@@ -26,7 +26,7 @@ facts:
     detail: "The Soft Robotic Rehabilitation Glove controller project."
 sections:
   - eyebrow: Brief
-    heading: "Turn a dense design report into something you can click through."
+    heading: "Interactive requirements and concept-selection dashboard."
     body: |
       The soft-glove design report carries a lot of decisions — customer requirements, a QFD
       ranking, weighted concept selection, and a final architecture. This project distils that
@@ -48,17 +48,10 @@ sections:
       - **Overview** — the project facts, joint motion targets, and the open → flex → hold →
         release assist cycle at a glance.
   - eyebrow: Engineering
-    heading: "A small, honest front-end built around the report's data."
+    heading: "React dashboard based on the design report."
     body: |
       Built with **React + Vite**, charts with **Recharts**, motion with **Framer Motion**, and
-      a component kit (shadcn/ui + Lucide). The interactive plot is driven by a **semi-empirical
-      model**, not live hardware telemetry — the goal is to communicate the design and let a
-      reviewer feel the trade-offs, not to claim a real-time link to the glove. It is the
+      a component kit (shadcn/ui + Lucide). The interactive plot uses a **semi-empirical model** rather than live hardware
+      telemetry. It demonstrates the proposed motion behaviour without a real-time glove link. It is the
       front-end companion to the [embedded controller](/projects/soft-robotic-glove/).
-  - eyebrow: Value
-    heading: "The portfolio's clearest piece of software engineering."
-    body: |
-      Most of my projects are hardware-first; this one is the opposite — interface design,
-      state management, and data visualisation. It also doubles as a presentation tool for the
-      glove work, which is exactly what a design review needs.
 ---

src/projects/half-car-suspension.md

@@ -45,10 +45,4 @@ sections:
       and velocity** shows the suspension doing its job: an initial deflection that rings down
       and settles, rather than a harsh single jolt. The state-space form makes it easy to swap
       in different spring/damper values and compare the resulting ride.
-  - eyebrow: Value
-    heading: "From equations on paper to a model you can tune."
-    body: |
-      The project connects derivation, linear-systems theory, and simulation into one
-      workflow — a model you can actually push road inputs through and read ride comfort off
-      of, which is the point of modelling a suspension in the first place.
 ---

src/projects/index.njk

@@ -2,8 +2,8 @@
 layout: base.njk
 permalink: /projects/
 title: "Projects | Rashid Al-Ma'awali"
-description: "Engineering projects by Rashid Al-Ma'awali — embedded control, robotics, mechanical CAD, signals, instrumentation, and software, each carried through to hardware, firmware, testing, and documentation."
-ogDescription: "Hardware, firmware, CAD, signals, and software — engineering projects carried through to testing and documentation."
+description: "Engineering projects by Rashid Al-Ma'awali in embedded control, robotics, mechanical CAD, signals, and instrumentation."
+ogDescription: "Projects in embedded control, robotics, CAD, instrumentation, and simulation."
 ---
 <main id="main" class="section-pad">
   <div class="container">
@@ -15,8 +15,8 @@ ogDescription: "Hardware, firmware, CAD, signals, and software — engineering p
 
     <div class="section-heading wide" data-reveal>
       <p class="eyebrow">Engineering Projects</p>
-      <h1>Every project carried through to hardware, firmware, CAD, testing, and documentation.</h1>
-      <p class="hero-lede">A working set of course, research, and self-directed builds across embedded control, robotics, mechanical design, signals, instrumentation, and software. Filter by area, or open any one for the full case study.</p>
+      <h1>Projects in controls, robotics, CAD, and instrumentation.</h1>
+      <p class="hero-lede">Course, research, and independent projects. Filter by discipline or open a case study for its design, methods, and results.</p>
     </div>
 
     <div class="project-filters" role="group" aria-label="Filter projects by area">

src/projects/numerical-methods.md

@@ -57,11 +57,4 @@ sections:
     body: |
       Definite integrals are evaluated with the **composite Simpson's 1/3 rule**, choosing the
       number of intervals to balance truncation error against effort.
-  - eyebrow: Value
-    heading: "A reusable, verified reference for later engineering work."
-    body: |
-      The result is a small library of trustworthy, well-understood routines — the same methods
-      that sit underneath the control, signal-processing, and modelling work elsewhere in this
-      portfolio. Implementing them from first principles turns their failure modes — pivoting,
-      convergence, step size — into something concrete rather than abstract.
 ---

src/projects/secure-access-box.md

@@ -49,7 +49,7 @@ sections:
       and a serial log (`System Ready`, `Warning: Proximity!`, `ALARM: Vibration!`,
       `Wrong PIN`) — so the box's behaviour is observable while it runs.
   - eyebrow: Schematic & Simulation
-    heading: "Designed and proven in Proteus."
+    heading: "Schematic design and Proteus simulation."
     image: "./src/_images/projects/secure-access-box/proteus-simulation.png"
     imageAlt: "Proteus schematic of the access box: an ATmega8 wired to a 4×4 keypad, 16×2 LCD showing ENTER PIN, HC-SR04 ultrasonic sensor, vibration sensor, buzzer, RFID reader, and red/green status LEDs, with a virtual terminal logging system events."
     caption: "Proteus capture & simulation — ATmega8 driving the keypad, LCD, ultrasonic and vibration sensors, RFID, buzzer, and status LEDs, validated before any wiring."
@@ -59,18 +59,12 @@ sections:
       vibration alarm — so the firmware and wiring were verified on virtual hardware before
       committing to physical parts.
   - eyebrow: Bench Build
-    heading: "Then built and tested for real."
+    heading: "Bench assembly and testing."
     image: "./src/_images/projects/secure-access-box/bench-build.jpg"
     imageAlt: "Breadboard prototype of the access box on the lab bench: ATmega8 with an AVR programmer, a 4×4 keypad, a 16×2 LCD, an HC-SR04 ultrasonic sensor, jumper wiring, and a servo-actuated cardboard enclosure standing in for the locked box."
     caption: "The breadboard prototype on the bench — ATmega8, keypad, LCD, ultrasonic sensor, and a servo-actuated enclosure, matching the simulated design."
     body: |
       The design didn't stop at simulation. It was **wired up on a breadboard** and run on real
       hardware — keypad, LCD, ultrasonic and vibration sensors, and a servo actuating a physical
       enclosure — closing the loop from a Proteus schematic to a working prototype.
-  - eyebrow: Value
-    heading: "The embedded basics that everything else builds on."
-    body: |
-      Port I/O, SPI, timing, interrupts, and actuator control on a constrained 8-bit
-      microcontroller — taken all the way from schematic to a tested bench prototype. This is
-      the groundwork the later ESP32 glove controller scales up from.
 ---

src/projects/signals-systems-dsp.md

@@ -38,10 +38,4 @@ sections:
       Implementing filtering in MATLAB and comparing input against output closes the loop
       between theory and result: a designed operation, applied to data, with the effect you
       can see rather than just derive.
-  - eyebrow: Value
-    heading: "The bridge from signals theory to DSP practice."
-    body: |
-      It's the project where signals-and-systems becomes a tool — the foundation for the
-      sensor filtering and telemetry that show up in the embedded work elsewhere in this
-      portfolio.
 ---

src/projects/soft-robotic-glove.md

@@ -33,17 +33,16 @@ facts:
     detail: "Bench-validated research platform. Not clinically approved and not human-tested."
 sections:
   - eyebrow: Context
-    heading: "A course project that earned its way into funded research."
+    heading: "From course controller to funded research."
     body: |
       This started as the **MCTE5255 Mechatronics Engineering Design** project — a four-person
       team building a controller for a *provided* soft robotic rehabilitation glove. I led the
       detailed control-system design. After the course, I was recruited as a **Research
       Assistant** in the College of Engineering to take the controller further under a funded
       grant on soft robotic actuators for tele-rehabilitation.
 
-      The brief was narrow on purpose: don't redesign the glove, design the controller that
-      makes it move *safely, repeatably, and observably* — and prove it on the bench before
-      anyone talks about a patient.
+      The project scope was the controller rather than the glove hardware: actuator sequencing,
+      sensor feedback, safety limits, and repeatable bench tests.
   - eyebrow: Problem
     heading: "Pneumatic soft actuators are nonlinear; open-loop timing can't be trusted."
     body: |
@@ -111,9 +110,9 @@ sections:
       gets a normally-open **2/2 isolation valve**: as a finger reaches its target angle its
       valve closes and holds, while pressure keeps driving the fingers that haven't arrived yet.
 
-      This is an honest match to the shared-air hardware — the system inflates fingers together,
-      vacuums them together, and isolates each one once it is done. It deliberately does **not**
-      claim independent per-finger pressure, which this pneumatic path cannot deliver.
+      With a shared pneumatic line, the fingers inflate or extend together, while individual
+      valves isolate each finger at its target angle. The system does **not** provide
+      independent pressure control for each finger.
 
       | Line | Board | Control | Telemetry |
       | --- | --- | --- | --- |
@@ -127,10 +126,9 @@ sections:
       a safety-and-validation checklist — in the
       [public portfolio repository](https://github.com/AstroMyth101/Soft-Robotic-Glove-Portfolio).
   - eyebrow: Host-Side Tooling
-    heading: "A small toolchain so the bench data is trustworthy, not just captured."
+    heading: "Serial logging, schema validation, and step-response analysis."
     body: |
-      The controller is only half the system; the other half is the **host-side tooling** that
-      makes its bench data reliable and reviewable:
+      Host-side tools capture, validate, and analyse controller telemetry:
 
       - **Serial logger / console** — records the CSV telemetry stream to timestamped files while
         letting the operator issue motion, gain, and calibration commands in the same session, so

src/projects/speed-reduction-gearbox.md

@@ -36,7 +36,7 @@ sections:
       four disconnected homework problems, and every component targets a design factor of
       safety of **2.5** for infinite life.
   - eyebrow: The Load
-    heading: "A reciprocating compressor delivers a brutal, fluctuating torque."
+    heading: "Compressor torque varies throughout each crank cycle."
     image: "./src/_images/projects/gearbox/torque-cycle.png"
     imageAlt: "Compressor torque versus crank angle for one cycle: a large positive peak near 575 lb-in, a negative dip near -175 lb-in, and a smaller secondary peak."
     caption: "Compressor torque over one cycle — the alternating load that drives the fatigue design (Tmax 585, Tmin −175 lb-in)."
@@ -91,10 +91,10 @@ sections:
       by side with shared material properties, so a change in load or material is a one-cell
       edit instead of a page of re-derivation.
   - eyebrow: Outcome
-    heading: "An integrated drivetrain, every component above the 2.5 target."
+    heading: "Integrated drivetrain sizing and reported safety factors."
     body: |
-      The result is a complete, manufacturable gearbox: standard shaft and bearing sizes,
-      a single well-characterized gear pair, and a sealed compressor joint — each verified
-      against the same infinite-life design factor. The components were modelled in SOLIDWORKS
-      and Fusion 360 to confirm fit and assembly.
+      The design specifies shaft and bearing sizes, a 32:81 spur-gear pair, and compressor
+      head bolts. The reported shaft fatigue factors exceed the 2.5 target; the pinion
+      contact safety factor (≈2.1) and bolt fatigue factor (≈1.68) are below it. The assembly
+      was modelled in SOLIDWORKS and Fusion 360 to check geometry and fit.
 ---

src/projects/sumo-robot.md

@@ -50,7 +50,7 @@ sections:
       than blind, pre-programmed motion. It's the same sensor-feedback thinking that runs through
       the rest of my work, shrunk down to a 20 cm box.
   - eyebrow: The Build
-    heading: "From panels to a robot that actually pushes."
+    heading: "Chassis assembly and bench build."
     image: "./src/_images/projects/sumo-robot/robot-built.jpg"
     imageAlt: "The built sumo robot: an aluminium base plate carrying two yellow cylindrical infrared proximity sensors at the front and wiring, with a low box body and a temporary cardboard top cover."
     caption: "The built robot — an aluminium base with the forward IR proximity sensors and drive, under a low box body (the top here is a temporary working cover)."
@@ -59,10 +59,4 @@ sections:
       sensors, a low wheeled drive, and the panel body — shown here mid-build with a temporary
       cover. Rough edges and all, it's a working robot rather than a render: the point of a
       sumo bot is that it has to survive contact and keep pushing.
-  - eyebrow: Value
-    heading: "A complete small robot, design through build."
-    body: |
-      Mechanical CAD, sensor selection, and a physical build that had to work under contact —
-      a compact end-to-end robotics project that ties mechanical design to sensor-driven
-      behaviour.
 ---