About Me
I am studying Computer Science and Psychology at the University of
Wisconsin–Madison. My interests include robotics, autonomous systems,
embedded systems, and systems software.
I work on autonomous vehicle software with Wisconsin Autonomous,
human–robot interaction in the People and Robots Laboratory,
and neural encoding models in the Rosenberg Lab.
Around this site
If you're a recruiter, start with
Projects for what I've
built, my role, and examples of the work. My
Education section
covers my academic background and coursework.
If you're a researcher or potential collaborator,
Research & Experience
covers my work in human–robot interaction, and computational neuroscience.
If you're a friend or just looking around, you can
browse what I've been reading or take a look at
my summer at Peking University.
Education
University of Wisconsin
Madison, WI · September 2024 – expected May 2028
B.S. in Computer Science & Psychology.
Completed coursework
- COMP SCI 537 — Introduction to Operating Systems: Process scheduling, memory virtualization, resource management, and the interaction between software and hardware.
- COMP SCI 559 — Computer Graphics: Geometric transformations, rendering, animation, and representing objects and images in two and three dimensions.
- COMP SCI 354 — Machine Organization and Programming: C and assembly programming, memory allocation, caching, and how low-level system organization affects performance.
- E C E 352 — Digital System Fundamentals: Boolean logic, combinational and sequential circuits, and the building blocks of digital computer systems.
- COMP SCI 400 — Programming III: Trees, graphs, hash tables, complexity analysis, and building maintainable software with advanced data structures.
In progress — Fall 2026
- COMP SCI 580 — Intelligent Robotics: Robot perception, state estimation, motion planning, kinematics, learning, and control.
- COMP SCI 577 — Introduction to Algorithms: Algorithm design through greedy methods, divide-and-conquer, dynamic programming, and reasoning about computational limits.
- COMP SCI 620 — Computer Sciences Capstone: Team software development for a corporate client, from design through testing, documentation, and delivery.
Course descriptions adapted from UW–Madison's
Computer Sciences catalog
and Electrical and Computer Engineering catalog.
Peking University
Beijing, China · Summer 2025
Advanced Topics in Computer Science
A summer program at Peking University's School of Computer
Science. The program introduced
current research across computing, alongside opportunities to meet
faculty and students and explore China's technology industry and culture.
Academic focus
The program covered ubiquitous computing, computer vision,
and embodied AI, along with the following topics:
- Visual computing, computational imaging, and context-aware systems.
- Programming-language research, open-source analytics, and AI-oriented databases.
- AI systems practice, hardware/software optimization, adaptive computing,
and distributed systems.
Program format
The schedule combined lectures with lab and technology-company visits,
student exchanges, and cultural activities. These describe the program's
published offerings.
Official PKU Summer 2025 program and curriculum.
Life at the program
For a closer look at the program's activities, student interactions,
and campus experience, see
PKU's overview and photos from the summer school.
Research & Experience
Wisconsin Autonomous — SAE AutoDrive / EcoCAR
Infrastructure Team Member; Team Lead since September 2026 · Madison, WI
September 2024 – Present
-
Interviewed, selected, and onboarded more than 10 team members,
introducing them to team workflows, in-house tools, and
cross-functional collaboration with other sub-teams.
-
Developed localization and path-planning nodes for a Level 4
autonomous vehicle that placed 2nd overall in Year 5 of the
SAE AutoDrive Challenge II.
-
Contributing to the migration of the autonomy stack to the
Chevrolet Blazer for the EcoCAR Innovation Challenge.
Rosenberg Lab
Undergraduate Researcher · Madison, WI
September 2026 – Present
I select and develop neural encoding models in PyTorch to characterize
relationships between six-degree-of-freedom head pose, eye-tracking
features, and neuronal firing activity in macaque monkeys.
I also collaborate within a 10-member Agile team using Jira to build
a tablet-based behavioral experiment platform. The platform integrates
Pupil Core eye tracking, real-time experimental control, and data
collection to distinguish neurodiverse behavioral subgroups.
People and Robots Laboratory
Undergraduate Research Assistant · Madison, WI
April 2026 – Present
How should a household robot recognize danger and respond in a way
that makes sense to the people living there? Embodied AI operates in
physical spaces, where mistakes can cause harm, yet its safety awareness
is often evaluated in simulation. Our research brings that evaluation
into real homes, asking whether AI responses reflect residents' concerns
and expectations for help.
We combined robot-assisted home tours with web-based hazard documentation.
Residents identified risks in their own homes, rated their severity,
frequency, and personal concern, and evaluated responses from three
multimodal AI models. This let us compare model-generated safety advice
with the judgments of people who know the household context.
What we learned
Residents could recognize the potential for serious injury while still
feeling little personal concern about a familiar hazard. They wanted
robots to support existing safety practices and offer additional ways
to manage risks, but model responses did not always meet their
expectations. The work highlights why detecting a hazard alone is
insufficient: useful assistance must also account for the resident,
the intended audience, and what can be done about the risk.
Study sessions
I independently conducted 60 remote participant sessions, guiding
residents through documenting household risks and evaluating
AI-generated responses. I also helped conduct 13 in-person sessions
in collaboration with a graduate student and another undergraduate.
The broader study included 113 participants and 1,133 documented
household risk entries.
Analysis and supplementary materials
I corrected the study transcripts, extracted key quotations, coded
the data, and performed quantitative analysis. I also formatted all
supplementary materials and created the study's mappings, contributing
to the organization and presentation of the research.
Current status
I am a co-author of the resulting paper, submitted to the CHI 2027
Papers track and currently under anonymous review.
Publications / Writing
Co-author of a human–robot interaction paper submitted to the
CHI 2027 Papers track; currently under anonymous review.
Projects
Autonomous Vehicle Localization
Wisconsin Autonomous · SAE AutoDrive
Technologies: C++, ROS 2, CAN, IMU, extended Kalman filtering, and Foxglove Studio.
Motivation
Localization provides the vehicle-state estimate needed by our control
stack. In SAE AutoDrive's localization challenge, GPS is intentionally
made unavailable, and the vehicle must estimate its position while
completing a course. This was my first project with Wisconsin Autonomous.
My contribution
I developed both the wheel-odometry and IMU localization nodes in
C++/ROS 2. Working with my team lead, I also contributed to combining
their estimates through an extended Kalman filter (EKF). Both nodes
run on the vehicle. A separate GPS-reliability detection node, developed
by another team member, supplies an input to the localization system.
How it works
The wheel-odometry node uses CAN-derived encoder and steering data with
Ackermann geometry to estimate vehicle motion. The IMU node uses inertial
measurements, and the EKF combines the two sources to support localization
when GPS becomes unreliable. Sensor noise and variations in wheel-road
interaction make this estimation challenging.
I used recorded ROS bags and Foxglove Studio to compare the estimated
trajectories against GPS reference data and guide improvements. Across
multiple ROS bags, the final-position error was approximately three
meters. This measures the ending position, rather than an average error
along the full route. The team placed third out of ten in the localization
challenge.
Lessons learned
This project taught me how to collaborate within a mature
codebase and learn unfamiliar tools while working with real hardware.
Many questions depended on our particular sensors, interfaces, and
vehicle setup, so progress required working with teammates and tracing
the existing system rather than relying on a generic online answer.
Autonomous Vehicle Mid-Level Planner
Wisconsin Autonomous · SAE AutoDrive
Technologies: Python, ROS 2, NumPy, and Frenet-frame planning.
Motivation
Our previous midplanner relied on a growing set of states with complex
transitions between them. As we added driving situations, that approach
became difficult to extend. A more robust perception stack also made
lane-line detections available, creating an opportunity to rewrite the
planner around the geometry the vehicle could observe.
My contribution
I helped select the planning algorithm and collaborated with my lead,
Patrick Chen, to write and test the new mid-level planner as part of
a roughly three-person planning effort. Our work connected localization,
perception, and high-level route information to the vehicle's control
stack. A separate subteam developed the model predictive controller
(MPC) that consumes the planner's output.
How it works
The planner uses Frenet coordinates: distance along a reference route
and lateral offset from it. It combines route guidance with detected
lanes and active restrictions, evaluates candidate paths, and produces
a reference trajectory with headings and a speed profile for MPC.
This gives us a way to respond to changing lane geometry and constraints
without encoding every combination as a separate driving state.
Algorithm selection was closely tied to testing logistics. Our course
in Columbus is about a forty-minute drive away, and access must be
scheduled around police training because we share the facility.
Simulation was therefore central to exploring and refining planning
ideas before spending limited time testing on the vehicle.
Lessons learned
This project deepened my understanding of control theory, testing,
and integration across an autonomous vehicle stack. It also showed
me how access to hardware shapes engineering decisions: simulation
helped us refine ideas before scheduled course tests, while vehicle
testing exposed integration issues that needed the full system.
The rewrite gave us a more maintainable foundation for extending
planning behavior as perception capabilities improved.
Midplanner Prototyping Simulator
Wisconsin Autonomous · Early planning prototype
Technologies: C++17, raylib, raygui, and CMake.
Motivation
We built this 2D simulator to explore a mid-level planning rewrite
while our perception stack was unavailable. Raycasting against
generated lane geometry gave us simulated lane detections, allowing
us to develop lane-following logic before integrating live perception.
The competition's low-speed context, approximately five miles per hour,
motivated a simplified speed policy rather than a detailed vehicle model.
My contribution
I developed the mid-level planning and control logic. My Wisconsin
Autonomous teammate, Adrian Luo, focused on the simulator and
road generation, and we worked together on the simulated high-level
planner. The road-generation controls let us vary the seed, grid size,
row and column counts, and junction probability to explore different layouts.
How it works
Rays cast from the simulated vehicle intersect lane markings to produce
lane-detection points. The midplanner uses these points to estimate a
lane-following heading and outputs a desired orientation and speed.
At intersections, where lane markings may be unavailable, it falls
back to the remaining high-level route to estimate the heading.
A line perpendicular to the vehicle's heading separates passed route
points from those ahead; points behind it are removed as the vehicle
progresses. A simplified vehicle controller directly updates heading
and position. In the actual vehicle system, the midplanner's desired
orientation and speed instead feed a downstream model predictive
controller (MPC).
Lessons learned
The simulator let us explore planning ideas without waiting for perception.
Our early state/behavior-based approach became increasingly complicated
as we added driving cases and transitions. We ultimately chose a different
final planning algorithm, but this iteration helped us examine the handoff
between lane following and route-based guidance. It documents a prototyping
step, rather than validation of the final vehicle planner.