Python Type Checker for Robot Race Conditions

ISEF Category: Systems Software

Subcategory: Languages and Operating Systems  ·  Difficulty: Advanced  ·  Setup: University Lab  ·  Time: Full Year

The Hook

One bad sensor read can send a robot the wrong way. In a school bot script, that kind of bug can hide until the robot bumps a wall or misses a turn. Your project asks a sharp question: can a type checker catch those mistakes before the robot moves?

What Is It?

This project focuses on a safer slice of Python for robotics code. A type checker is a tool that checks whether code follows rules before it runs. Your version would look for concurrency bugs, especially cases where two parts of a program touch the same sensor or actuator at the same time.

Think of it like a traffic cop for code. If two drivers try to use one lane at once, crashes happen. If two threads or tasks read and write the same robot resource without coordination, the robot can behave in ways that are hard to predict. A mypy plugin can extend Python's type checks so those risky patterns get flagged early.

You would study how well that checker catches real mistakes in existing robot repos, such as Roomba or EV3 code. You would also see whether the checker creates useful warnings without blocking too much safe code.

Why This Is a Good Topic

This is a strong science fair topic because you can test it with real code, clear rules, and measurable results. You can count bugs caught, false alarms, and missed cases. The topic connects to software safety, robotics reliability, and tools that help people write better code. A student can learn static analysis, software design, GitHub-based research, and basic evaluation methods.

Research Questions

• How does a mypy plugin affect the number of shared-sensor race conditions caught in robotics scripts?
• What is the effect of different type rules on false positive warnings in EV3 or Roomba code?
• Does the checker catch more concurrency bugs than a baseline linter or standard mypy run?
• To what extent does the checker flag unsafe access patterns in open-source robotics repos?
• Which classes of robot code bugs are easiest or hardest for the plugin to detect?
• How does replaying buggy code on test inputs change the measured safety of the type system?

Basic Materials

• Laptop or desktop computer with Python installed.
• Git and a GitHub account for collecting open-source robot repos.
• mypy and a code editor such as VS Code.
• Spreadsheet software for logging bug counts and warning types.
• A small set of robotics scripts from GitHub, such as EV3 or Roomba examples.
• Text notes or a lab notebook for recording test cases and results.

Advanced Materials

• University workstation or strong personal computer for batch analysis.
• Python type checker development environment.
• mypy source code and plugin development setup.
• Larger corpus of robotics repositories from GitHub and GitHub Archive search.
• Test harness for replaying code on saved inputs or traces.
• Optional static analysis tools for comparison, such as pylint or pyright.
• Statistics software for precision, recall, and confusion-matrix analysis.

Software & Tools

• Python: Runs the type checker, analysis scripts, and data-processing code.
• mypy: Provides the type-checking base that your plugin extends.
• VS Code: Helps you inspect robotics code and debug the plugin.
• GitHub: Gives you real robotics repositories to mine and replay.
• Pandas: Organizes warning counts, bug labels, and evaluation tables.
• ImageJ: Not needed for this topic, so skip it unless you adapt the project to vision-based robotics data.

Experiment Steps

1. Define the exact robot concurrency bug pattern you want to catch, such as unsafe shared-sensor access.
2. Choose a small rule set that your type checker can enforce without making normal code unusable.
3. Collect a labeled set of robotics scripts with known safe and unsafe patterns.
4. Build a baseline by running plain mypy and a simple linter on the same code set.
5. Design an evaluation plan that counts true positives, false positives, and missed bugs.
6. Compare results across codebases and decide which rule changes improve safety without too many false alarms.

Common Pitfalls

• Treating every repeated sensor read as a race, which creates false alarms that hide the real bugs.
• Testing only polished demo code, which makes the checker look stronger than it is on messy student repos.
• Ignoring threading, callbacks, and async code paths, which leaves the main failure mode untested.
• Labeling code as safe just because it runs once without crashing, which misses timing bugs that appear later.
• Comparing against a baseline with different rules, which makes the evaluation unfair and hard to interpret.

What Makes This Competitive

A stronger version of this project would go beyond a simple yes-or-no checker. You could compare several rule designs and measure which one gives the best balance of safety and false alarms. You could also test on a larger, messier set of real robotics repos and break results down by bug type. That kind of careful evaluation shows real systems thinking.

Project Variations

• Test the checker on Arduino or Raspberry Pi robot control scripts instead of EV3 code.
• Focus on unsafe access to shared camera frames, motor commands, or battery state instead of sensors.
• Compare a mypy plugin against a custom linter or abstract interpretation tool on the same bug set.

Learn More

• mypy documentation: Read the plugin and type system docs on the official mypy site.
• Python documentation: Review Python's typing and concurrency basics in the standard docs.
• GitHub Search: Find open-source robotics repositories and trace buggy patterns through commit history.
• PubMed: Search for review articles on software defects in robotics or safety-critical systems.
• MIT OpenCourseWare: Look for free courses on software analysis, programming languages, or static analysis.
• ACM Digital Library: Search peer-reviewed papers on type systems and static analysis for concurrency bugs.