Technical Stack
-Skills grouped by how they are used in real systems.
+Firmware, control, modelling, and design.
Embedded & Control
C/C++, Python, MATLAB, ESP32, Arduino, AVR, ROS 2, micro-ROS, serial telemetry, sensor interfacing, finite-state machines, control systems.
Contact
-Interested in embedded systems, robotics, controls, or research collaboration?
-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.
+Research and engineering collaboration.
+I'm open to graduate research and collaborations in robotics, control, and soft robotic systems. Contact me by email, LinkedIn, or GitHub.
Email me
diff --git a/src/projects/data-acquisition.md b/src/projects/data-acquisition.md
index 93b742b..ad0475a 100644
--- a/src/projects/data-acquisition.md
+++ b/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.
---
diff --git a/src/projects/glove-dashboard.md b/src/projects/glove-dashboard.md
index d03f169..7e8d492 100644
--- a/src/projects/glove-dashboard.md
+++ b/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.
---
diff --git a/src/projects/half-car-suspension.md b/src/projects/half-car-suspension.md
index aa4af76..01df854 100644
--- a/src/projects/half-car-suspension.md
+++ b/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.
---
diff --git a/src/projects/index.njk b/src/projects/index.njk
index c7bc574..7d35629 100644
--- a/src/projects/index.njk
+++ b/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."
---
@@ -15,8 +15,8 @@ ogDescription: "Hardware, firmware, CAD, signals, and software — engineering p
Engineering Projects
-Every project carried through to hardware, firmware, CAD, testing, and documentation.
-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.
+Projects in controls, robotics, CAD, and instrumentation.
+Course, research, and independent projects. Filter by discipline or open a case study for its design, methods, and results.
diff --git a/src/projects/numerical-methods.md b/src/projects/numerical-methods.md
index 2922598..7a6173b 100644
--- a/src/projects/numerical-methods.md
+++ b/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.
---
diff --git a/src/projects/secure-access-box.md b/src/projects/secure-access-box.md
index a147db8..46ce6e5 100644
--- a/src/projects/secure-access-box.md
+++ b/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,7 +59,7 @@ 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."
@@ -67,10 +67,4 @@ sections:
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.
---
diff --git a/src/projects/signals-systems-dsp.md b/src/projects/signals-systems-dsp.md
index 9e9233a..0056094 100644
--- a/src/projects/signals-systems-dsp.md
+++ b/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.
---
diff --git a/src/projects/soft-robotic-glove.md b/src/projects/soft-robotic-glove.md
index c333ec2..01e680c 100644
--- a/src/projects/soft-robotic-glove.md
+++ b/src/projects/soft-robotic-glove.md
@@ -33,7 +33,7 @@ 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
@@ -41,9 +41,8 @@ sections:
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
diff --git a/src/projects/speed-reduction-gearbox.md b/src/projects/speed-reduction-gearbox.md
index 125462a..d2e6147 100644
--- a/src/projects/speed-reduction-gearbox.md
+++ b/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.
---
diff --git a/src/projects/sumo-robot.md b/src/projects/sumo-robot.md
index 697f36f..01685a5 100644
--- a/src/projects/sumo-robot.md
+++ b/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.
---