Professional Summary
Hi! I'm Yasmine, a Computer Engineering student at UC Santa Cruz concentrating in systems programming. I like learning new tools, understanding how systems work, and writing embedded software.
Most of my current work is with the Braingeneers research lab, where I work as a tester and developer of the engineering systems behind an autonomous brain-organoid experiment platform. I help build, integrate, and validate the hardware and software that keep the experiment running, including embedded firmware, sensors, fluidics, distributed control, automation logic, and fault handling. A lot of my role is making separate pieces of hardware behave as one reliable system.
Before that, I worked as a Business Systems Analyst at Lam Research, where I wrote automation and reporting tools for operational workflows. I also have done work for Formula Slug, UCSC's SAE EV racing team, where I have contributed to dashboard-screen software and sensor firmware for the car. I like being able to move between different parts of a project, pick up new skills, and solve whatever problem is in front of me. Below is a video of the autonomous research system I am currently working on!
If you have any questions, project ideas, or inquiries, feel free to reach out at ysiala@ucsc.edu.
- The pump drives the sample through the fluidic path toward the Automaton device.
- A liquid sensor detects the arriving sample and triggers the bypass valve, allowing a controlled sample drop to enter the PDMS chip.
- After sample delivery, the pump begins its cleanup/rinse sequence while the Automaton Pi takes over the device-side process.
- The Pi controls sample preparation, mixing, incubation, valve states, and measurement sequencing inside the Automaton device.
- The optics PC is then triggered for laser/DAQ control, coordinating optical acquisition with the Automaton measurement stage.
This autonomous research system is being developed in collaboration with Yoehi Rosen, MD, PhD and Ravipa Losakul. The project is still pre-publication, so this portfolio focuses on the architecture, engineering approach, and supporting modules I can share publicly. We are continuing experimental validation now, with the goal of publishing the full autonomous system and results soon :)
Sensing & Fluidic Hardware
The hardware side of the system is built around automated sample handling. The autosampler prepares and positions vials, while the pump, solenoids, and sensors move fluid through the rest of the experiment.
Autosampler Device
> NOTE: This clip shows the autosampler motion only. No liquid lines are connected in this test.
I developed the autosampler to move sample vials through the positions needed for dispensing and aspiration without manual handling. It combines an actuator, servo-driven motion, and an optical sensor for position feedback. I also worked on the PCB design and embedded electronics that tie the sensor, motion hardware, and controller together.
Pump & Solenoid Fluidics
I integrated the pump and solenoid valves that handle sample transfer, dye routing, waste, and cleaning. The fluidic path is controlled in software, but liquid sensors provide the feedback, so the system reacts to where the fluid actually is instead of only relying on timing.
Sensors Used So Far:
- Optical sensor: custom sensing hardware used by the autosampler for position/state feedback.
- Liquid sensors: detect sample and dye arrival so the controller can trigger bypass-valve actions at the right time.
- Device-state feedback: pump, relay, servo, and controller status are checked alongside sensor readings for safer sequencing and fault handling.
Software & Firmware
Most of my work lives here. The autonomous research system is distributed across a main PC, Raspberry Pi controller, an optics PC, STM32 nodes, a Tecan pump, sensors, relays, and motion hardware. I designed the control software so those pieces can run concurrently without stepping on each other, while still enforcing the dependencies that matter to the experiment.
threading.Event gates coordinate sample handoff,
mixing, optics, aborts, and shutdown.
Integrated Controller & System Architecture
I helped write the main Python controller as the orchestration layer for the full experiment. The pump/fluidics stage, Pi mixing & measurement stage, and optics stage each run in their own threads, so independent work can overlap instead of forcing the entire system through one long blocking sequence.
The threads are synchronized with explicit
threading.Event handoffs. For example, the Pi
waits for the sample-delivery event, optics waits for
mixing/incubation to finish, and the Automaton measurement
waits until optical acquisition has started. I also use a
shared abort event so a failure in one stage can immediately
release anything waiting downstream and stop the rest of the
run cleanly instead of deadlocking it.
Because several threads can report failures at the same
time, I protect the shared error list with a
threading.Lock. Device commands are pushed
through scheduler worker queues rather than called directly
from every stage, and the CAN-connected devices share a
transmit lock so concurrent subsystems do not write onto the
bus at the same time.
I added timeouts around command dispatch and hardware state changes, a background pump-heartbeat watchdog, sensor retry loops with small corrective pushes, safe relay cleanup in failure paths, and subsystem flags that let me run culture, pump, Pi, optics, or bypass logic independently during bring-up.
Autosampler Firmware
I helped write the autosampler firmware that handles homing, vial indexing, dispense positioning, aspiration setup, motion state, and error reporting. The firmware turns higher-level commands from the PC into actual servo and actuator behavior, then reports status back so the controller knows when it is safe to move on.
The optical sensor is part of that control loop, so the firmware is not just issuing timed motion commands. It uses hardware feedback to confirm position/state and keep the mechanical sequence synchronized with pump power and fluidic operations.
Closed-Loop Experiment Automation
I built the experiment logic around hardware feedback instead of assuming every command succeeds on the first try. Liquid detection triggers bypass actions, missing liquid can trigger a small corrective pump push and another sensor check, and later stages wait for explicit completion events before they start.
This is where a lot of the reliability work lives. Deciding which failures should stop the run, which ones can be retried, and what every valve, pump, or actuator should do if something upstream fails.
Embedded Communication & Device Interfaces
I implemented the communication layer that lets the PC, STM32 nodes, pump, Pi, optics system, sensors, and actuators exchange commands and status. Most inter-device control runs over CAN, with custom message handling for commands, telemetry, heartbeat/status checks, and fault reporting.
On the embedded side I also work directly with SPI, I2C, UART, GPIO, ADC, and PWM for sensor acquisition, peripheral control, and board bring-up. When something fails, I debug from both directions: software logs and protocol behavior on one side, and the actual electrical signals with a scope or logic analyzer on the other.
Data Analytics
Before this research project, I worked in Business Systems Analytics at Lam Research. The work was different from embedded systems, but I was still doing the same kind of thing I like doing now: finding a repetitive or messy process and writing software to make it faster and more reliable.
Automated Duty-Free Reporting
I wrote a script that generated the daily duty-free reporting list and automatically sent it out each day. It replaced a repetitive manual task, made the report faster to produce, and reduced the chance of reporting mistakes. This script is now run daily by Lam Research Gloabl Operations.
Shipment Tracking & Delay Flagging
I built a script and supporting dashboard that let the team track outbound shipments and immediately flag anything that had taken more than a day to leave the facility. This decreased warehouse delays by up to 80% and increased visibility for trade teams.
Additional Projects
I built interactive games in Verilog on a Basys 3 FPGA, including player input, movement, scoring, display timing, and finite-state-machine logic. This project gave me hands-on experience thinking in hardware instead of software: designing synchronous logic, working with clocks and counters, building state machines, and understanding how logic maps onto real digital hardware.
I built a small Python pipeline for testing machine learning models on historical market data from Yahoo Finance. The project handled data collection, feature generation, train/test splitting, model training, and simple backtesting to compare predictions against actual price movement.