A useful position has to reach the experiment
In this system, detecting a fly is one step in a larger task. Its position must become a visual cue in the right place, while the researcher can still inspect what the software is doing. The engineering work connects acquisition, image analysis, controller state, calibration, and display.
In the lab’s published experiments, rotating pinwheel patterns guide walking through the fly’s response to visual motion. This gives the software a way to influence movement using light, as explained in the lab’s illustrated Harvard research overview.
I helped integrate this processing path within the lab’s existing software. Acquisition and tracking run together in a background worker. Separate queues and interface timers handle preview images and stimulus commands. The preview limits how many frames are waiting; that limit does not apply to every queue in the system.
Connecting camera and projector coordinates
The recovered image-processing path subtracts a saved background, finds contours that match the expected fly size, and derives their centers. Those centers are measured in camera coordinates. The stimulus system uses a calibration lookup to relate camera positions to projector positions before generating cue commands.
The original grid capture below shows the calibration problem concretely: known projected points appear in the camera image, and their correspondence is used to align the two coordinate systems. This is part of the lab infrastructure my integration work depended on.
A moving blue cue for one fly
My moving-blue-dot experiment used one CsChrimson fly in a square arena. The “Follow a blue dot” loop above illustrates that single-fly setup; its path, motion, and playback speed are illustrative. This was an unpublished experiment, separate from the lab’s published pinwheel-guidance study.
Exploring how a group could share a cue
My Heckman presentation also describes group-control experiments with aggregation and transport, local recovery, and mechanical coupling. That broader group work included 2-, 5-, and 10-fly configurations; the mechanical-coupling experiment specifically used two flies connected by a single flexible glass fiber. The other three loops illustrate these approaches, with further detail in the research notes.
For the main pinwheel in the gathering and recovery approaches, I considered two alternative centering rules. One uses the group’s geometric centroid, calculated from the fly positions. The other places the pinwheel on the actual fly nearest that centroid and reselects that fly as the group changes. Both centers can move; the second can also switch which fly serves as the center. The figure lets you compare these two ideas within either group approach. They are alternative rules, not successive phases or a measured performance comparison.
The recovered software archive gives a closer view of one controller variant. It finds flies within a search region around the previous center, updates the group center, and positions a fixed-size main pinwheel there. Flies outside the search region receive secondary cues toward the updated center.
Within the group search region
Use the included flies' positions to update the group center. Heading histories inform the next turning command toward the target.
Outside the group search region
Issue a secondary cue toward the group center, then reconsider membership on the next update.
That particular code snapshot is configured for a two-fly simulation. It explains one implementation path within the broader experimental work described in my presentation; it does not establish a tested comparison of the two centering ideas. The presentation’s qualitative observations, historical sketches, and recovered code have different scopes. The animations explain the approaches and centering ideas rather than reproduce recorded experimental trajectories.
Separating the different kinds of delay
A central challenge in my work was distinguishing image-processing time from acquisition and display effects. The software exposes several different timing quantities. They answer different questions, so a slow update alone does not identify the cause.
- Update interval
- How much time passed between entries into the tracking update?
- Extraction time
- How long did the position-extraction call take within that update?
- Display cadence
- How frequently did the interface display a queued observation?
My Python and MATLAB diagnostic work focused on inspecting the relationship between observations, trajectories, and timing. These stage measurements help frame the investigation; none alone measures the complete camera-to-projector delay.
Lab context and related materials
The published apparatus figure below provides context for the camera, projector, arena, and visual cues. My contribution combined experimental software integration with experiments in single-fly cueing and cohesive moving-group control in that research setting.
- The fruit fly as a microrobotics platform · PNAS The lab's published platform and experiments. I am not an author of this paper.
- Rayshubskiy Lab people The lab's team and alumni, including my Northeastern research-fellow affiliation.
- Fly–object interaction study · Current Biology A related lab study that acknowledges me for helpful discussions; I am not a co-author.
- Public analysis code for the fly–object study The authors' MATLAB analysis repository for that related study, separate from the tracking prototype described here.
- Related lab video abstract The fly–object study's visual explanation, linked by Harvard. This is the authors' research video, not a recording of my prototype.


