Mars Rover Charging & Navigation

Mars Rover Charging & Navigation

Industrial Robotics 4 All

Industrial Robotics 4 All

Industrial Robotics 4 All

Problem Statement

Learning industrial robotics usually requires navigating steep learning curves and heavy desktop applications. On mobile and web platforms, presenting complex spatial 3D robot controls alongside instruction panels creates severe cognitive load and UI screen real estate bottlenecks—especially on small viewports where control panels and 3D viewports fight for space. (Project in progress)

Problem Statement

Learning industrial robotics usually requires navigating steep learning curves and heavy desktop applications. On mobile and web platforms, presenting complex spatial 3D robot controls alongside instruction panels creates severe cognitive load and UI screen real estate bottlenecks—especially on small viewports where control panels and 3D viewports fight for space. (Project in progress)

The core bet: a robot user can actually grab

The program's promise is that you will control a real robot arm. So the page opens by letting you control one.


The hero is not a render, a video, or a Lottie loop. It is a live Three.js scene with a six axis industrial arm assembled from seven GLB parts and rigged with forward kinematics, plus a second Spline humanoid you can switch to. Both are fully interactive:

  • The arm tracks your cursor. Move the mouse and it reaches toward the pointer using an inverse kinematics solve, so it reads as attention rather than animation.

  • Three scripted routines: Say hi, Dance, and Pick. Each is a keyframe sequence with hold times and gripper closure values, authored by hand.

  • Manual control exposes all six joints as sliders with live degree readouts and limits per joint, plus Reset pose.

  • The humanoid follows your gaze through a rig that intercepts Spline's own look at behavior, and switches to manual head and torso posing when you open the controls.

The core bet: a robot user can actually grab

The program's promise is that you will control a real robot arm. So the page opens by letting you control one.


The hero is not a render, a video, or a Lottie loop. It is a live Three.js scene with a six axis industrial arm assembled from seven GLB parts and rigged with forward kinematics, plus a second Spline humanoid you can switch to. Both are fully interactive:

  • The arm tracks your cursor. Move the mouse and it reaches toward the pointer using an inverse kinematics solve, so it reads as attention rather than animation.

  • Three scripted routines: Say hi, Dance, and Pick. Each is a keyframe sequence with hold times and gripper closure values, authored by hand.

  • Manual control exposes all six joints as sliders with live degree readouts and limits per joint, plus Reset pose.

  • The humanoid follows your gaze through a rig that intercepts Spline's own look at behavior, and switches to manual head and torso posing when you open the controls.

Solution

WHO framework:-

IR4All is a browser first robotics platform that removes the two barriers keeping students out of industrial robotics: cost and equipment access. A WebGL simulator and a built in AI tutor let a high school student learn real robot arm operation on a device they already own, then carry that into a hands on build day and an ASU credential.

Solution

WHO framework:-

IR4All is a browser first robotics platform that removes the two barriers keeping students out of industrial robotics: cost and equipment access. A WebGL simulator and a built in AI tutor let a high school student learn real robot arm operation on a device they already own, then carry that into a hands on build day and an ASU credential.

W
What i designed?

W
What i designed?

Designed and built the program's public platform end to end: a real time WebGL robot arm with six axis joint control and scripted routines, plus the responsive site carrying the full program story across nine sections. Sole designer and engineer on both.

H
How did I approached it?

H
How did I approached it?

Paired UX strategy with direct implementation rather than writing specs for someone else to build. Authored cursor tracking arm physics for pointer devices, then rebuilt the same control model for touch as drag handles on the joints themselves, switched by input capability detection instead of screen width.

O
Outcome of my descisions?

O
Outcome of my descisions?

Shipped a production site where a student manipulates a live industrial robot within seconds of landing, on any device, with nothing to install. The interaction became the recruitment pitch: the phone, which is how most of this audience arrives, gets the largest and most legible robot of the three form factors rather than a stripped down version.

The risk was obvious: a 3D hero is heavy, and heavy is exactly what a phone audience cannot afford. That tension drove the rest of the build.

W
What i designed?

Designed and built the program's public platform end to end: a real time WebGL robot arm with six axis joint control and scripted routines, plus the responsive site carrying the full program story across nine sections. Sole designer and engineer on both.

H
How did I approached it?

Paired UX strategy with direct implementation rather than writing specs for someone else to build. Authored cursor tracking arm physics for pointer devices, then rebuilt the same control model for touch as drag handles on the joints themselves, switched by input capability detection instead of screen width.

O
Outcome of my descisions?

Shipped a production site where a student manipulates a live industrial robot within seconds of landing, on any device, with nothing to install. The interaction became the recruitment pitch: the phone, which is how most of this audience arrives, gets the largest and most legible robot of the three form factors rather than a stripped down version.

The risk was obvious: a 3D hero is heavy, and heavy is exactly what a phone audience cannot afford. That tension drove the rest of the build.

Role

Product Designer + Developer

Team

Vaibhav Doifode - UX (Myself)

Duration

1 Week

Check different views

The same robot, three ways to touch it. A trailer for Phase 1: this is what a student actually does once they enroll.

Desktop

The arm tracks your cursor and reaches for it in real time. Open Manual control and all six joints become sliders with live degree readouts.


Built with: Three.js scene, an inverse kinematics solve on every pointer move, rotation limits enforced per joint in the rig.

What the student sees: the exact joint control they will use in Module 1.

Tablet

No cursor, so the model becomes the interface. The arm idles on its own until you tap, and every joint grows a handle you can drag directly.


Built with: a live subscription to (hover: none) and (pointer: coarse), with handles projected from 3D joint positions into screen space each frame.


What the student sees: direct manipulation, the same gesture as posing a real arm on the build day.

Phone

Portrait is the wrong shape for a six axis arm, so the motion shrinks instead of the robot. Sweep angles scale to 35 percent and the arm frames larger here than on any other device.


Built with: three generated pose sets, a camera bounding volume computed across every keyframe, and a toolbar that drops labels and keeps icons.


What the student sees: full control on the phone in their pocket, nothing to install.

Check different views

The same robot, three ways to touch it. A trailer for Phase 1: this is what a student actually does once they enroll.

Desktop

The arm tracks your cursor and reaches for it in real time. Open Manual control and all six joints become sliders with live degree readouts.


Built with: Three.js scene, an inverse kinematics solve on every pointer move, rotation limits enforced per joint in the rig.

What the student sees: the exact joint control they will use in Module 1.

Tablet

No cursor, so the model becomes the interface. The arm idles on its own until you tap, and every joint grows a handle you can drag directly.


Built with: a live subscription to (hover: none) and (pointer: coarse), with handles projected from 3D joint positions into screen space each frame.


What the student sees: direct manipulation, the same gesture as posing a real arm on the build day.

Phone

Portrait is the wrong shape for a six axis arm, so the motion shrinks instead of the robot. Sweep angles scale to 35 percent and the arm frames larger here than on any other device.


Built with: three generated pose sets, a camera bounding volume computed across every keyframe, and a toolbar that drops labels and keeps icons.


What the student sees: full control on the phone in their pocket, nothing to install.

Assumptions set before starting
with research and designing interface

Before designing the interface, I set a few assumptions to ground the concept in a believable future.

Before designing the interface, I set a few assumptions to ground the concept in a believable future.

Time Period:

Year 5-10
Early establishment phase.

Settlement Type:

Scientific research & Resource extraction (water ice, minerals)

Charging Infrastructure:

Solar Stations + Supercharg Stations

This Means for the Rover:

Rugged Built for function & Survival-first design

Earning the scroll

Earning the scroll

The hero buys attention. The rest of the page has to convert it, and three sections do specific persuasion jobs.

The price card: making "free" land

Telling a teenager something is free does not work. So the page makes them watch the price disappear.

The Earth Fly-in: To drive physical visits to Mesa, a plain address isn't enough. Instead, the Visit section features a Google Earth fly-in from orbit directly to the ASU MIX Center, ending with a pin drop and actionable Maps and Directions links.

Reflection

How much of this did you build versus generate with an AI tool?

How much of this did you build versus generate with an AI tool?

I used Claude Code as an implementation partner, the same way I would use any tool that types faster than I do. What it does not do is decide that cursor tracking breaks on the primary device, or that the fix is capability detection rather than breakpoints, or that motion should scale instead of the model. Those are the decisions in this project and they are mine. Ask me about any file and I will walk you through why it is shaped that way.

Why a live 3D scene instead of a video? A video is cheaper and looks the same.

A video looks the same for two seconds and then stops being the product. Phase 1 of this program is literally a browser based arm simulator with joint control. The hero is a preview of the thing the student is being recruited into, not a metaphor for it. The moment the arm turns to follow your cursor, the page has made a promise it can keep. A video makes a promise it cannot.

5.4MB of JavaScript on a page aimed at phone users. Defend that.

5.4MB of JavaScript on a page aimed at phone users. Defend that.

I cannot fully defend it, which is why it is in the case study. The bet was that demonstrating the product beats describing it, and for a skeptical sixteen year old I still think that is right. What I got wrong is shipping it without a static first paint, so the page cannot show a call to action until the 3D runtime loads. That is the first thing I would fix, and I would set a hard time to interactive budget measured on a real mid tier Android rather than a throttled desktop.

How do you know any of this works?

How do you know any of this works?

Results from 12 moderated sessions showed strong qualitative success: users unprompted stated they wanted to join, proving the design actively recruits. Final conversion numbers for MIX Center enrollments are still pending while the live program runs.

Thank you!!!

If you have any feedback,feel free to share it with me.
Your insights are valuable and will contribute to
my continuous improvement.

Thank you!!!

If you have any feedback,feel free to share it with me.
Your insights are valuable and will contribute to
my continuous improvement.

Follow
VVaibhav Digital Twin

Curious about Vaibhav?
Ask me anything.