AI Human Activity Recognition for On-board BAS Experiments

The receipts 🧾

Every red flag on this statement, in full. These are the four places it bites.

1. Exhibit A

   Teams generate their own dataset, so the model only learns the one procedure you recorded and generalisation from a small custom set is weak

2. It gets worse

   The orientation-agnostic microgravity tracking that makes this genuinely space-relevant is research-grade and left optional, so most teams demo an Earth-oriented version

3. Still reading?

   Reliable step recognition from pose and hand-object interaction is harder than it looks when steps are visually similar

4. And the finisher

   An ISRO judge will ask how this transfers to actual microgravity conditions your Earth-recorded dataset cannot capture

The damage report 📉

Every score this statement earned, and what each one actually costs you.

• Feasibility

  2/5

  You have picked a fight with physics, procurement, or both. One of them always wins.

  The component techniques exist, but the description requires teams to build their own dataset by recording a procedure, and training reliable step-recognition with pose and hand-object interaction from a small custom dataset is hard — the optional orientation-agnostic 3D human mesh recovery in microgravity is a research-grade addition on top.

• Innovation scope

  4/5

  There is something genuinely new here. Do not bury it under another dashboard.

  Sequence validation of a procedure from activity recognition, with next-step guidance and out-of-order detection, is a genuinely interesting framing, and the orientation-agnostic tracking relative to the payload rack rather than the floor is a real open problem.

• Clarity

  4/5

  The ask is unambiguous, which quietly removes your favourite excuse.

  The description specifies the inputs, the required capabilities including next-step suggestion, skip and out-of-order voice alerts and the structured log, and marks the orientation-agnostic part optional, so the target is clear even though the dataset is self-generated.

• Acceptance potential

  3/5

  Middle of the pack. This statement will not win the room for you — you will have to.

  The framing is compelling and the sequence-validation-with-guidance angle is genuinely useful, but the self-generated dataset means the model only learns the procedure you recorded, generalisation is weak from a small custom set, and the microgravity-orientation challenge that makes it space-relevant is exactly the hard part left optional.

• Effort

  Massive

  A semester of work wearing a hackathon costume. Something is getting cut; decide what now, not in week five.

  Generating a custom dataset, training object detection plus pose plus hand-object interaction, building the sequence-tracking and alerting logic, and running it at the edge is a large multi-part effort.

• Demo-ability

  Easy

  Easy to demo — and so is everyone else's. Working is the floor here, not the achievement.

  Performing a procedure and watching the system guide, catch a skipped step by voice, and log the run is a concrete, self-explanatory demo you can script exactly.

The demo they will have already seen 🪞

Somewhere around 150–340 teams are heading here, and the description is doing the choosing for most of them. They will read the same brief, reach the same architecture, and build a version of the same demo you are planning. Being correct is the floor. If your five minutes could be swapped with the team before you and nobody in the room would notice, you have not picked badly — you have built predictably, which costs exactly the same and hurts more.

What survives 🛡️

The ground worth standing on when the questions start.

• Scripting a procedure and catching a deliberately skipped step with a voice alert is a concrete, self-explanatory demo you fully control
• Pose and hand-object interaction have mature open libraries like MediaPipe and MMPose to build on
• The next-step-guidance and out-of-order-detection framing is genuinely useful beyond the space context