How does Tesla's Roadster fly? Exploring the physics

Jayanta Phadikar — Mon, 19 Oct 2026 14:39:35 +0000

Introduction

A car climbs a curved ramp until its wheels are above its roof. It leaves the overhang upside down, rolls through the air, and lands on its wheels. In a second stunt, it launches from the ground, completes a full barrel roll over a line of parked vehicles, and touches down on the other side. These are the two sequences we will explore from Tesla’s October 15, 2026 Roadster demonstration. [1–3]

At first sight, the motions seem to belong to a spacecraft rather than a car. But the underlying ingredients are familiar: pressure differences, Newton’s laws, angular momentum, and feedback control. The interesting part is how these ingredients cooperate. The force that attaches the car to a surface is different from the force that supports it in the air. And the jets that rotate the car also change the path of its center of mass.

In this post, we will build an intuitive picture of that mechanism, derive a manageable set of equations, and use Wolfram Language to reconstruct both stunts. The animations are numerical illustrations based on the accompanying package. Vehicle mass, ramp dimensions, gas inventory, thrust capacity, and controller settings are explicit modeling assumptions; the calculated trajectories are not measurements of Tesla’s car.

How the forces work

The forces have three jobs. Attachment comes from a pressure difference that holds the car against the ramp and keeps the tires loaded. Rotation comes from a difference between the left and right jet forces. Landing requires enough upward thrust, delivered while the car is upright and still has stopping distance.

Our route through the calculation follows the motion. First ask how a car can stay on an inverted surface. Then release it and ask how the same four jets change both its orientation and its trajectory. Finally ask whether enough thrust remains to land. Each equation answers one of these questions; the second stunt reuses the same machinery with a different starting condition.

You can read the physical story first and run the code afterward. The final section provides a six-step workflow: load, inspect, change one assumption, compare outcomes, plot the forces, and export a new animation. It includes a deliberately inadequate fan so that we can see what a failed physical assumption looks like in the audit.

Tesla describes a fan and ground-sealing system, together with cold-gas thrusters. [1] They give us two different ways of producing force.

The fan system removes air from the region beneath the car. If the surrounding pressure is higher than the pressure in that region, the resulting pressure difference pushes the car toward the surface. Think of a suction cup on glass: it is the surrounding air pressure that supplies the push. The fan continually renews that pressure difference. The sealing skirt matters because air continuously tries to leak back in. The fans must remove that incoming air to maintain the pressure difference.

The cold-gas system releases stored, pressurized gas through nozzles. The gas acquires momentum in one direction, and the vehicle receives a reaction force in the opposite direction. Combustion is not required. Unlike suction attachment, this reaction force can operate after the car has left the ramp.

This distinction also explains why the direction of a force matters. Suction always acts toward the nearby surface in our contact model. Jet thrust acts along a direction fixed in the car. As the car rolls, that direction rotates in the world. A jet that provides lift when the car is upright can push it downward when the car is inverted.

We use four corner lift nozzles, represented by two independently throttled banks, one on each side. Each bank contains a front and a rear nozzle. The left pair each supplies

/2; the right pair each supplies

/2. Equal bank thrust produces a net force. Unequal bank thrust produces both force and roll torque. This is a plausible simplified arrangement, not a claim about Tesla’s exact nozzle layout.

Figure 1. A body-frame schematic of the four lift nozzles used by the model and its renderer. Cyan denotes the left bank and violet the right bank. The circles mark thrust toward the viewer when the car is upright. Perspective can hide the far pair in a 3D view; two visible plumes do not imply that the car has only two nozzles. During a roll, one bank can also be off, leaving only two nozzles firing.

Stunt 1: The inverted ramp

The notebook shows a sharp still preview of each stunt. Keep the assets folder beside the notebook and evaluate the Import cell beneath a preview to load its full GIF. The "AnimatedImage" import element opens the GIF as a playable animation. The two GIFs are separate files, each smaller than 6 MB.

Watch the first loop for the motion. Follow the climb, the upside-down departure, the half-turn, and the landing. The camera eases closer during the climb and release; the fixed side elevation keeps the full height visible when the main view is close.

Watch the second loop for the forces. Amber marks suction. The four circles in the body-frame map are the four physical nozzles: front at the top, left bank in cyan, right bank in violet. Each number is the thrust of one nozzle, not the whole bank. Brightness shows its fraction of the capacity available at that instant. The panel above the nozzle map changes roles at release. During contact it reports suction demand, wheel load, and fan power. In flight it compares the world-vertical jet force with weight: the amber arrow is gravity, the cyan arrow is the signed vertical jet reaction. The numerical jet value is

/(mg). A value of +1 balances weight before drag; a negative value adds a downward force. Arrow length is capped when necessary, with a visible note, while the numerical value remains uncapped.

Notice the crucial handoff: suction disappears at the lip, bank imbalance turns the car, and nearly balanced jets later brake its descent. The phase caption explains the current job. The clock is physical time; the playback slows down only to make the flight easier to inspect.

Snapshot at t = 10.83 s. Evaluate the following cell to load the full GIF (2.90 MB). Keep the assets folder beside this notebook.

Import[FileNameJoin[{NotebookDirectory[],"roadster_inverted_ramp.gif"}],"AnimatedImage"]

Animation 1. Suction-assisted climb, inverted release, half-roll, descent braking, and rollout. Climb plays at 2× physical speed, flight at 0.45×, and rollout at 1×. The clock always shows physical simulation time. Plume shapes and ground mist are schematic; the exhaust stops at the road plane, and nozzle readouts use the modeled individual forces. Cyan and violet identify the two banks, while amber identifies suction on the car and weight in the force guide. The small side elevation has a fixed scale within this stunt, and its dot marks the center of mass.

Pause near release, at 10.74 s on the clock. The car has horizontal velocity, but no longer has a ceiling reaction. The jets initially point in the wrong direction to support its weight. Predict a downward-curving path before looking at the equations below. Later, watch for a negative vertical velocity together with a jet-force ratio above +1: the vehicle is still descending, but the thrust is slowing that descent.

How suction holds the car up

Imagine first holding the car motionless against a horizontal ceiling. Gravity pulls it away from the ceiling, while suction pushes it toward the ceiling. The ceiling’s contact reaction also points away from the ceiling. If S is the suction force and N is the wheel reaction, equilibrium requires

Smg+N

A helpful way to read this is to imagine gradually increasing suction. At S = mg the car is only just supported: the wheel load is zero, so the tires have no friction budget. Suction must therefore do more than cancel weight if we want a positive wheel load. With the assumed initial mass of 1700 kg and a 1500 N preload, S = 18.18 kN. Spread over a sealed area of 2.5 m², that corresponds to a pressure difference of about 7.27 kPa. The large force comes from applying a moderate pressure difference over a substantial area.

Climbing the curved ramp

The curved ramp adds centripetal acceleration. Let θ be the angle of the path tangent above horizontal, κ its curvature, and v the speed along it. Choose the normal pointing from the road toward the car’s roof. Resolving Newton’s law along this normal and along the tangent gives

N-Sm

κ+gcos(θ)

parallel

m(

′

(t)+gsin(θ))

Check the limiting cases before trusting the signs. On a flat floor, θ = 0 and κ = 0, so N = mg + S. On the horizontal ceiling, θ = π, giving N = S − mg. On the vertical section, gravity contributes no normal component, but the tires must still generate an upward tangential force to climb.

In a Coulomb-friction approximation, the available tire force is limited by μN. The package therefore asks for enough normal load to satisfy both a small preload and the traction demand:

target

max

preload



parallel



req

max0,

target

-m

κ+gcos(θ)

Near the upper curved section, the car can simultaneously need traction, attachment, and a changing direction of motion. That is why the largest suction demand need not occur on the flat ceiling. For these defaults, the sampled peak is about 19.67 kN.

The contact path itself is prescribed: two quarter-circle arcs, a short vertical section, an approach, and an overhang. A smooth speed ramp leads to the assumed 4 m/s cruising speed. We calculate the forces needed to follow this path and check whether the assumed tires and fans can supply them. This is an inverse force calculation, rather than a multibody simulation of four tires negotiating the ramp. The example proceeds continuously to release; it does not reconstruct the preliminary stop and reversal shown in the event footage.

Seal leakage and fan power

Pressure difference alone does not determine fan power. The fans must also move the air entering through leaks. If

leak

is the effective leakage area and

leak

a discharge coefficient, an orifice approximation gives

Δp

seal

Q

leak

2Δp

fan



ΔpQ

Here Q is volumetric flow and η is fan efficiency. For a fixed seal geometry, power grows as

3/2

(Δp)

. Doubling the leakage area doubles the power needed to maintain the same suction. A seal can therefore be as important as a powerful fan.

With the assumed leakage area of 0.055 m², coefficient 0.65, and efficiency 0.55, peak fan demand is approximately 58.0 kW. The assumed limit is 80 kW. If we reduce that limit, the code still draws the prescribed contact path, but the contact-feasibility audit can fail. Such a failed trajectory must not be presented as a physically supported climb.

Leaving the ramp upside down

At release, the surface reaction and suction disappear from the flight equations. The car initially moves horizontally at about 4 m/s. That velocity does not vanish at the lip: the car continues along the tangent while gravity begins bending its path downward. The corner jets request a half-roll, φ: 0 → π.

Calculating the motion

We now need two linked descriptions: where the car is going, and which way its jets point. Let the position of the center of mass be r = (x, y, z), with z measured upward, and let v be its velocity. Write

and

for the two bank forces and n for the car’s roof-normal direction. Once the wheels leave the surface, Newton’s second law becomes

′

(t)v(t)

m(t)

′

(t)(

)n-m(t)g

Av(t)v(t)

The first force is jet reaction, the second is gravity, and the final term is a simple quadratic drag model. Here ρ is air density and

A is the effective drag area. Thrust already includes the momentum carried away by the expelled gas; adding another exhaust-momentum term to this equation would count the same effect twice.

We solve three-dimensional translation but retain only one rotational degree of freedom: roll about the car’s front-to-rear axis. Airborne pitch and yaw are fixed. If b is the lateral distance from the centerline to either bank, the reduced roll equations are

′

(t)ω(t)

ℐ

(t)

′

(t)b(

)

This is a lumped rotational closure. The package scales

with the remaining vehicle mass and uses torque divided by that instantaneous inertia. It does not resolve moving gas inside the tanks or the angular-momentum flux of the exhaust. Thus it should not be interpreted as a complete variable-mass rigid-body model.

The geometry gives an especially useful insight. For the fleet jump, φ = 0 is upright and

fleet

{0,-sin(ϕ),cos(ϕ)}

ramp

{0,-sin(ϕ),-cos(ϕ)}

The ramp expression starts from an inverted vehicle facing the opposite longitudinal direction. There, φ = 0 is inverted and φ = π is upright. In the fleet jump, the corresponding target is φ = 2π.

Read the force in the world frame. For the fleet model, the upward component of thrust is (

) cos φ. Halfway through its roll, cos φ = −1: firing the corner jets then accelerates the car downward. At a quarter-turn, the same thrust is horizontal. We therefore cannot prescribe a pretty rotation and independently draw a convenient flight path. The rotation and translation have to be integrated together.

Carattitude	Jetreactionintheworld	Whattoexpect
Upright	Upward	Cansupportweightorslowadescent
Sideways	Horizontal	Changeslateralvelocity,withnodirectlift
Inverted	Downward	Addstogravitywhilecontributingrolltorque

This table describes the force, not the direction of travel. A rising car can have downward acceleration and continue rising for a while. A falling car can have upward acceleration and continue falling while it slows. In the animations, compare the vertical-force guide with the signed vertical-velocity readout: positive velocity means rising; negative means falling. Ignoring drag for a moment,

/(mg) − 1 is the vertical acceleration in units of g. Thus a ratio of +1.5 means an upward acceleration of 0.5g, regardless of whether the car is currently rising or falling. The guide omits drag; the integrated equations retain it.

Why use four nozzles?

Four nozzles distributed around the center of mass give a natural way to control lift, roll, and pitch if their thrusts can be varied independently. The front/rear balance deserves particular care. If the front nozzles lie

ahead of the center of mass and the rear ones

behind it, their combined pitch moment is



(

)

Here the first subscript identifies front or rear, and the second identifies left or right. In our symmetric geometry,

= 1.90 m. Splitting each side’s thrust equally between its front and rear nozzles makes this pitch moment zero even while the two side banks produce a roll torque. That is a nominal pitch balance, not an active pitch controller. Four nozzles alone do not guarantee balance: their moment arms, individual forces, and feedback matter. A shifted center of mass, unequal nozzle performance, or a pitch disturbance would require front/rear feedback and a fuller attitude model. Four parallel lift jets also provide no direct yaw torque in this idealization. Rear acceleration jets and yaw jets are outside the flight dynamics considered here.

Controlling the roll

The target angle is built from a quintic polynomial:

q(u)10

-15

(t)πq(u)

uClip

,{0,1}

Here t is time since release and

is the desired roll time. The polynomial starts and ends with zero angular velocity and zero angular acceleration. The code uses its derivatives only inside the maneuver interval and zero derivatives outside it.

A feedback law requests the torque needed to follow that target:



ℐ



′′

(t)+2ζ

(

′

(t)-ω)+

(

(t)-ϕ)

The first term anticipates the target acceleration. The second damps angular-velocity error, and the third corrects angle error. If this torque were delivered exactly, the tracking error would obey a familiar damped second-order equation. The numerical model instead integrates the torque that the pressure-limited jets actually deliver.

For a requested total thrust

and torque

, the unsaturated allocation is



≥





Each force is then clipped to the interval [0,

max

]. The lower bound is essential: a nozzle can push but cannot pull. Think of the bank sum as the translation command and the bank difference as the rotation command. They are linked because neither bank can be negative. Even when the controller asks only for rotation, these two parallel banks must produce some net thrust to generate a torque. During the first part of the inverted recovery, that thrust can worsen the fall or create sideways drift.

Put numbers on the sum and difference. Suppose the left bank delivers 12 kN and the right bank 8 kN. The car receives 20 kN along its roof normal, while a 0.90 m lever arm gives a roll torque of 3.6 kN m. The four individual nozzles read 6, 6, 4, and 4 kN. If both banks are reduced by the same amount, the torque initially stays the same but the net force falls. The process stops when the weaker bank reaches zero; any further reduction would require a nozzle to pull. This is the origin of the inequality in the allocation equation.

Reducing

is therefore costly. Since the target angular acceleration scales as

-2

, halving the roll time requires roughly four times the feedforward torque at the same inertia. A faster requested roll can saturate a bank and make the actual rotation slower than intended.

Slowing the descent

Once the car is sufficiently upright, the jets can oppose its downward velocity. A useful estimate comes from the elementary relation between speed, acceleration, and stopping distance. At height z, with touchdown center-of-mass height h and desired downward speed

land

, the required constant upward net acceleration would be



land

2(z-h)

≈

m(g+

)

The model recomputes this demand continuously, uses a small floor on the remaining height, and enables it only while descending with

> 0.8. It also limits how negative a braking demand may become. For the ramp, braking is allowed after an assumed 1.35 s delay from release. Available pressure still limits the actual force.

Try a stopping-distance estimate. At a downward speed of 8 m/s, with 4 m left and a desired touchdown speed of 0.8 m/s, the formula gives

= 7.92 m/s². An upright car then needs about 1.81 times its weight in thrust, before drag. With only 2 m left, the required net acceleration doubles and the thrust rises to about 2.61 times weight. At

= 0.8, divide those thrust demands by 0.8 again. This is why an almost-upright car can still run out of braking authority.

A useful prediction: at the same downward speed, halving the remaining stopping distance doubles the required net braking acceleration. The total thrust also has to support the weight. As the remaining height shrinks, the required braking force rises rapidly. Finishing the roll is therefore only part of the problem: it must finish early enough to leave room to stop the fall.

For the defaults, flight lasts 2.67 s, the downward touchdown speed is about 0.86 m/s, and gas use is about 109 kg. The horizontal touchdown speed is still about 4.48 m/s; “gentle landing” here refers to the vertical component. A separate friction rollout brings the vehicle to rest. The modeled sideways displacement is about 4.48 m, which shows the consequence of retaining the lateral thrust component while omitting a yaw or lateral-control system.

Stunt 2: A barrel roll over parked cars

The second stunt begins upright on the ground. The car already has forward speed, receives an upward launch impulse, completes a full roll, and brakes before returning to the road. We can now predict what each phase needs before watching it.

Watch launch, rotation, and braking separately. At launch, all four nozzles share the upward push. During the roll, compare the two sides of the nozzle map: the imbalance first adds angular speed and then removes it. During descent, compare the upward cyan force arrow with the still-negative vertical velocity. Upward acceleration reduces the downward speed before it can reverse it. The fixed side elevation shows the obstacle locations while the camera follows the car.

Snapshot at t = 2.01 s. Evaluate the following cell to load the full GIF (2.94 MB). Keep the assets folder beside this notebook.

Import[FileNameJoin[{NotebookDirectory[],"roadster_fleet_jump.gif"}],"AnimatedImage"]

Animation 2. The model passes five schematic obstacles while executing a 360° roll. Flight plays at 0.45× physical speed; ground motion plays at 1×. The camera moves smoothly toward launch and rotation, follows the descent, and eases wider near touchdown. Parked-vehicle dimensions and spacing are illustrative.

Three moments to compare on the physical clock: launch begins at 1.00 s; the full-roll target is reached at 2.65 s; touchdown occurs near 4.25 s. These are different events with different objectives. At launch the bank sum matters most. During rotation the bank difference matters. Before touchdown the remaining upward force and stopping distance matter together. The fixed overview helps distinguish actual displacement from camera movement.

Launching upward

The default run-in speed is 11 m/s. The model then requests 60 kN of total upward thrust for 0.30 s. At the initial mass, that is about 3.60 times the vehicle’s weight. Subtracting gravity gives the approximate initial net upward acceleration



60000

1700

-9.81≈25.5

m/s

If this acceleration remained constant for the entire burn, the car would gain approximately 7.65 m/s of upward velocity. A subsequent thrust-free ballistic rise would add roughly 2.98 m above the burn-end height. These are useful scale estimates, not the full trajectory: in the simulation, mass and pressure change, and the roll maneuver itself adds vertical and lateral impulse.

Horizontal momentum carries the car across the fleet. With no modeled rear acceleration jets in flight, forward speed changes only through drag. Forward speed and vertical impulse therefore play different roles: one sets how quickly the car crosses the obstacles; the other helps determine how long it has before touchdown.

Completing a full roll

After the launch burn, the target becomes

(t)2πqClip

launch

,{0,1}

The default

is 1.35 s. The same feedback law and bank allocator apply. Early torque spins the car up; later torque removes the angular velocity so it can approach the ground upright with little residual roll rate.

Add the two nozzle readouts on each side of the map to obtain the bank thrust. The difference between banks drives the rotation, while their sum accelerates the center of mass along the changing roof normal. A car can be rising even when the instantaneous jet force points downward, because velocity records the accumulated effect of earlier forces. Likewise, an upward jet force does not immediately reverse a descent; it first reduces the downward speed.

The full numerical trajectory reaches a sampled center-of-mass height of about 6.91 m and travels 35.58 m during 3.25 s of flight. The simulation begins descent braking after the target roll interval has ended, once the center of mass is below h + 3.5 m and the thrust direction is sufficiently upward.

Clearing the parked cars

The center of mass being above a truck does not guarantee that a wheel, roof edge, or body corner clears it. A rolling car changes its vertical extent.

The audit surrounds the car with a conservative box. Let

be its half-width and [

min

max

] its local vertical bounds relative to the center of mass. For roll angle φ, the lowest point of this box has world height

bottom

z-

sin(ϕ)+min(

min

cos(ϕ),

max

cos(ϕ))

For every obstacle, we check this height throughout the interval when the two objects overlap longitudinally. The implementation assumes lateral overlap even when the modeled car drifts sideways, making this clearance calculation conservative with respect to lateral separation. It samples 1001 times over each complete overlap interval, including the endpoints.

The minimum sampled clearance for the defaults is approximately 0.70 m, above the audit’s 0.05 m requirement. This is a sampled geometric check, not continuous collision detection. There is no contact response if the car strikes an obstacle; a failed clearance check invalidates the proposed overflight.

Gas consumption

For a nozzle, momentum flow and exit pressure contribute to the thrust. The standard relation is [4]

F



out

)

The package absorbs these effects into an assumed effective exhaust speed

eff

, so the total gas consumption is

′

(t)-

eff

m

dry

As the reservoir empties, its pressure falls and so does the available thrust. A simple adiabatic blowdown approximation provides a useful coupling. For a well-mixed ideal gas in a rigid, insulated tank, the energy balance is d(

T)/dt =

/dt. Combining this with pV =

R T gives



γ-1



The reconstruction uses these normalized laws to reduce both bank capacity and effective exhaust speed:

max



max,0

eff



γ-1

The default γ = 1.4 is a diatomic-gas approximation. At high storage pressure, real-gas effects, heat transfer, and nozzle details would matter. We use the normalized law as a transparent model of declining authority, without inferring the gas charge from a claimed tank volume and an ideal-gas calculation.

Now connect this to the two landings. The relevant quantity is the remaining thrust-to-weight ratio, 2

max

/(mg), rather than the initial tank pressure alone. If this ratio falls below one, even an upright car cannot maintain its height with these lift jets. Braking a fall requires still more force. This immediately suggests a practical limitation: a maneuver can have plenty of thrust at launch and much less available when it needs to brake. A controller must work with the pressure that remains. For the defaults, the upright capacity-to-weight ratio falls from about 4.20 initially to about 2.01 at ramp touchdown and 1.80 at fleet touchdown. These are available capacities, not the actual thrust commands. The car becomes lighter, but the loss of tank pressure is the larger effect.

Simulation results

The following values come from the supplied reconstruction, using one common initial mass and gas charge for both stunts.

Modelresult	Invertedramp	Fleetjump
Airborneduration	2.67s	3.25s
Gasconsumed	108.98kg	120.45kg
Gasremaining	141.02kg	129.55kg
Finalmodeledpressure	309.33bar	274.68bar
Downwardtouchdownspeed	0.862m/s	0.851m/s
Horizontaltouchdownspeed	4.48m/s	10.88m/s
Magnitudeoflateraldisplacement	4.48m	1.19m

Both models reach an upright touchdown with negligible residual roll rate under the chosen controller. The landing test allows at most 2° tilt, 0.1 rad/s roll rate, and 1.5 m/s vertical speed. Once these conditions are met, the model switches to a simple Coulomb-friction rollout. Suspension compression, impact loads, and tire deformation are not resolved.

The large modeled gas consumption helps explain why a short airborne stunt and sustained flight are very different tasks. At the initial mass and assumed effective exhaust speed of 500 m/s, merely supporting the weight would consume roughly mg/

= 33.4 kg/s. An optimistic constant-mass, constant-exhaust-speed estimate would spend 250 kg in about 7.5 s. That estimate is not a hover prediction: real pressure limits, cooling, changing mass, and control requirements alter the result. It simply exposes the scale of the gas-flow problem.

Run the model yourself

Step 1 — load the package and solve both defaults. Keep FlyingRoadster_Community.wl beside the notebook and keep the assets folder alongside both files. The notebook contains the post, two sharp snapshots, and cells that import the full GIFs. Load the accompanying package with Get, then evaluate the model and analysis cells in order. The same three lines work in a fresh notebook saved in that folder:

Get[FileNameJoin[{NotebookDirectory[],"FlyingRoadster_Community.wl"}]];

ramp=RoadsterModel["Ramp"];

fleet=RoadsterModel["Kickflip"];

Step 2 — inspect one instant before changing anything. Each model is an Association. It contains its parameters, phase times, diagnostics, interpolating solutions, and functions that return the state at a chosen time. NDSolveValue integrates the nine airborne variables: three positions, three velocities, roll angle, roll rate, and remaining gas. A descending ground-height event ends the flight. [5]

ramp["Parameters"]

Mass1700.,GasMass250.,Gravity9.81,CGHeight0.64,CeilingHeight21.,RampRadius9.5,ApproachLength7.,OverhangLength3.,CruiseSpeed4.,AccelerationTime1.2,RollTime1.,BrakeStart1.35,HalfTrack0.9,RollInertia800.,BankForce35000.,PressureBar689.5,ExhaustSpeed500.,GasGamma1.4,AirDensity1.225,DragArea0.75,LandingSpeed0.8,GroundFriction0.75,TireFriction1.1,WheelPreload1500.,FanPowerLimit80000.,SealArea2.5,LeakArea0.055,LeakCoefficient0.65,FanEfficiency0.55,RestTime1.2,RollControlFrequency10.,RollDampingRatio1.,FlightTimeLimit10.,InitialMass1700.,DryMass1450.,VerticalLength0.72,ReleaseHeight20.36

fleet["PhaseTimes"]

Start0.,Release1.,LaunchEnd1.3,RollCompleteTarget2.65,BrakeStart3.40011,Touchdown4.25218,Stopped5.73119,End6.93119

fleet["Diagnostics"]

TouchdownReachedTrue,ContactFeasibleTrue,MaxSuctionN0.,SuctionCapacityN0.,MaxFanPowerW0.,PeakBankForceN30000.,GasUsedKg120.452,GasRemainingKg129.548,FinalPressureBar274.675,LandingVerticalSpeed-0.850834,LandingHorizontalSpeed10.8818,LandingRollErrorDegrees-3.56222×

-13

,LandingTiltDegrees0.,LandingFeasibleTrue,LandingRollRate4.14935×

-14

,LateralDriftM-1.19203,LandingVerticalEnergyJ571.732,FlightDuration3.25218,ApexHeightM6.90957,FlightRangeM35.581,ModelTypeIntegrated finite-thrust launch, variable-mass 3D translation and one-axis full roll; positive corner-bank thrust; adiabatic normalized blowdown; Coulomb-friction rollout.

fleet["State"][2.`]

ThrustLeft0.,ThrustRight1648.19,ThrustVector{0.,356.412,-1609.19},RollTorque-1483.37,PressureBar497.539,Mass1648.03,BankCapacity25255.8,DesiredRoll3.35956,ExhaustSpeed477.228,ThrustDemand1648.19,BrakingFalse,Position{-4.01864,-0.656205,6.12758},Velocity{10.9622,-2.23822,3.52801},Rotation{{1.,0.,0.},{0.,-0.976339,0.216245},{0.,-0.216245,-0.976339}},Pitch0.,Roll3.35956,RollRate8.70272,GasMass198.025,GasUsed51.9746,Suction0.,SuctionRequired0.,NormalForce0.,FanPower0.,FanPowerRequired0.,Speed11.7315,VerticalSpeed3.52801,PhaseAirborne full roll,ContactFalse,Time2.

RoadsterPostFrame[fleet,2.`,ImageSize900]

State uses time measured from the start of the complete scene. FlightState uses time measured from release or launch. For example, these evaluate the same instant:

fleet["State"][fleet["ContactEnd"]+0.5`]

ThrustLeft15942.8,ThrustRight0.,ThrustVector{0.,-2565.,15735.1},RollTorque14348.5,PressureBar539.385,Mass1659.78,BankCapacity27380.,DesiredRoll0.16159,ExhaustSpeed482.766,ThrustDemand15942.8,BrakingFalse,Position{-9.50447,-0.00262035,3.21442},Velocity{10.9814,-0.0713902,6.85056},Rotation{{1.,0.,0.},{0.,0.986973,-0.160888},{0.,0.160888,0.986973}},Pitch0.,Roll0.16159,RollRate2.22376,GasMass209.784,GasUsed40.2161,Suction0.,SuctionRequired0.,NormalForce0.,FanPower0.,FanPowerRequired0.,Speed12.9432,VerticalSpeed6.85056,PhaseAirborne full roll,ContactFalse,Time1.5

fleet["FlightState"][0.5`]

Connect one animation frame to the equations. Inspect the fleet model at 3.9 s, during descent braking. The following cell reports the signed vertical velocity, the actual vertical jet force divided by weight, and the available upright thrust divided by weight. The first tells us how the car is moving; the second helps explain how that motion is changing; the third tells us how much authority the controller has left.

With{s=fleet["State"][3.9`],p=fleet["Parameters"]},Association"VerticalVelocityMPerS"s["VerticalSpeed"],"VerticalJetForceOverWeight"

s["ThrustVector"]〚3〛

s["Mass"]p["Gravity"]

,"UprightCapacityOverWeight"

2p["BankForce"]

p["GasGamma"]

s["GasMass"]

p["GasMass"]

s["Mass"]p["Gravity"]



VerticalVelocityMPerS-3.48894,VerticalJetForceOverWeight1.77782,UprightCapacityOverWeight2.20593

Change the parameters

Supply overrides as an association in the second argument of RoadsterModel. Numbers use SI units except "PressureBar", which is in bar. "Mass" includes the initial gas charge; dry mass is computed as "Mass" - "GasMass".

Parameter	Default	Whatitchanges
"Mass"	1700kg	Initialtotalmass
"GasMass"	250kg	Initialgasinventory
"BankForce"	35000N	Initialcapacityofeachsidebank
"ExhaustSpeed"	500m/s	Initialeffectivethrustperunitmassflow
"PressureBar"	689.5bar	Initialpressurelabelinthenormalizedmodel
"RollInertia"	800kgm²	Initialrollinertia
"HalfTrack"	0.90m	Lateraljetleverarm;alsoscalesthedrawnwidthandclearanceenvelope
"RollTime"	1.00/1.35s	Targetramp/fleetrollduration
"CruiseSpeed"	4/11m/s	Ramp/fleetapproachspeed
"FanPowerLimit"	80000W	Rampfan-powerceiling
"LeakArea"	0.055m²	Rampsealleakagearea
"LaunchForce"	60000N	Fleettotallaunch-thrustrequest
"LaunchDuration"	0.30s	Fleetlaunch-burnduration
"BrakeHeight"	3.5m	Fleetdescent-brakingheightabovetouchdownheight

All these numerical defaults are reconstruction assumptions. The initial pressure is a reporting scale: changing "PressureBar" alone does not increase force, because capacity uses p/

. Change "BankForce" when exploring initial thrust authority. Similarly, increasing "GasMass" at fixed "Mass" reduces the implied dry mass. To add gas while keeping dry mass fixed, increase both by the same amount.

Step 3 — make a prediction, then rerun. Increase the ramp vehicle’s mass by 100 kg while retaining the same gas inventory. Predict larger attachment and braking demands. Build a new model and inspect its audit before rendering it:

heavierRamp=RoadsterModel["Ramp",Association["Mass"1800.`]];

If[FailureQ[heavierRamp],heavierRamp,RoadsterValidation[Association["Heavier ramp"heavierRamp]]]

Next, allow the fleet roll 1.50 s instead of 1.35 s. Predict lower peak target angular acceleration; do not assume the apex will stay fixed, because the jets also accelerate the center of mass. Change the parameter and solve again. The old solution does not update when a parameter is edited elsewhere. Reevaluate the RoadsterModel assignment to integrate the new equations, then reevaluate the audit and any frame or plot that uses the new model.

changedFleet=RoadsterModel["Kickflip",Association["RollTime"1.5`]];

If[FailureQ[changedFleet],changedFleet,RoadsterValidation[Association["Changed fleet"changedFleet]]]

The code checks names and numerical domains before integration. A typo such as "Rolltime" is reported as an unknown parameter instead of being silently ignored. Parameters must be finite real numbers in their stated physical domains. For example, gas mass must be smaller than total mass, and fan efficiency must lie between zero and one. Some choices return a Failure before a complete model can be built, for example if launch thrust is insufficient or landing is too fast. Other choices build a trajectory but fail a contact or obstacle-clearance audit. These are meaningful results. They show that a requested maneuver is incompatible with the chosen assumptions and controller.

Step 4 — compare a small family of solutions. Here is a small parameter study that records those outcomes rather than silently discarding them:

rollStudy=Table[Module[{m,audit},m=RoadsterModel["Kickflip",Association["RollTime"tr]];If[FailureQ[m],Association["RollTime"tr,"Result"m],audit=RoadsterValidation[Association["Trial"m]]["Trial"];Association["RollTime"tr,"Passed"audit["Passed"],"GasUsedKg"m["Diagnostics"]["GasUsedKg"],"ApexHeightM"m["Diagnostics"]["ApexHeightM"]]]],{tr,{1.2`,1.35`,1.5`}}];

Dataset[rollStudy]

RollTime	Passed	GasUsedKg	ApexHeightM
1.2	True	122.174	7.85971
1.35	True	120.452	6.90957
1.5	True	117.9	6.4328

For these three runs, shortening the target roll from 1.50 s to 1.20 s raises the sampled apex from 6.43 m to 7.86 m and increases gas use from 117.90 kg to 122.17 kg. All three pass the current audit. The changing apex is a direct consequence of the additional jet impulse during rotation; it would be missed by a model that assigned the flight path independently of the roll.

Try a controlled failure. Lower only the fan-power limit to 20 kW. Predict that the prescribed ramp path will still be drawn, but that attachment and traction will no longer be supported everywhere. Ask the audit specifically about the contact loads:

weakFan=RoadsterModel["Ramp",Association["FanPowerLimit"20000.`]];

If[FailureQ[weakFan],weakFan,RoadsterValidation[Association["Weak fan"weakFan]]["Weak fan"]["Checks"]["RoadContactLoadsFeasible"]]

False

The result is False. This is a useful distinction between solving a prescribed motion and showing that the available actuators can produce it. Restore the fan limit before treating the animation as a feasible reconstruction.

Step 5 — use a plot to explain what the animation shows. It is also useful to examine the physical histories directly. This plot shows how bank imbalance produces the roll:

PlotEvaluate

{fleet["FlightState"][t]["ThrustLeft"],fleet["FlightState"][t]["ThrustRight"]}

1000

,{t,0.`,fleet["Diagnostics"]["FlightDuration"]},



	Left bank
	Right bank

Step 6 — export only after the audit passes. Finally, regenerate a GIF after a successful audit. Export is explicit because rendering the animation takes longer than integrating the equations.

The GIF export below is a Program cell. Copy it into an Input cell and evaluate when you want to render a new animation.

If[!FailureQ[changedFleet],
audit = RoadsterValidation[<|"Trial" -> changedFleet|>]["Trial"];
If[TrueQ[audit["Passed"]],
RoadsterPostGIF[
FileNameJoin[{NotebookDirectory[], "my_fleet_jump.gif"}],
changedFleet, "Width" -> 960, "FramesPerSecond" -> 16,
"CacheDirectory" -> FileNameJoin[{NotebookDirectory[], "frame_cache"}]],
audit["Checks"]]]

"Width" and "FramesPerSecond" control display quality and file size. "FlightPlaybackRate" controls slow motion; the default 0.45 means that 0.45 seconds of physical flight is shown per second of playback. Camera moves use smooth quintic transitions and do not alter the physical solution. The exporter stores cached frames in a separate fingerprinted folder for each combination of model parameters, timing, image width, quality, and renderer version. You can therefore reuse the same cache directory when changing a parameter; frames from the old solution will not be mistaken for the new one. The exporter checks both cached image dimensions, retries transient rendering failures, and writes through a temporary file before replacing an existing GIF. It reports a Failure if rendering or saving does not succeed. RoadsterPostFrame clamps times outside the scene to its first or last frame, consistently with State. To inspect a static scene without the publication layout, use RoadsterScene[model, time, "Camera" -> "Wide"] or "Follow".

Model checks and limitations

Run the numerical audit on the models already computed:

checks=RoadsterValidation[Association["Ramp"ramp,"Fleet"fleet]];

(#1["Passed"]&)/@checks

RampTrue,FleetTrue

Both defaults pass the package’s 20 checks. These cover finite states, proper rotation matrices, nonnegative and declining gas inventory, pressure-dependent thrust limits, force and torque allocation, zero airborne suction, contact feasibility, continuity at release and touchdown, landing attitude and speed, final stopping, gas-flow bookkeeping, and fleet clearance where applicable.

One check compares the integrated mass flow with the decrease in stored gas. Their differences are about 0.000094 kg for the ramp and 0.000459 kg for the fleet. This tests numerical consistency within the chosen gas model. It does not calibrate that model against a real reservoir. Several other checks verify identities built into the implementation; passing them catches mistakes but does not independently establish physical accuracy.

The decisive simplifications are the prescribed ramp path, the single rotational degree of freedom, the lumped gas law, and the simple touchdown/rollout model. Geometry is procedural and approximate. The ramp deck is shortened near the lip to accommodate release, without resolving individual wheel loads through detachment. Aerodynamic lift, wind, actuator delay, suspension impact, full attitude control, and real-gas thermodynamics would all be natural extensions.

What the reconstruction does reveal is the coupling that makes these stunts interesting. Suction supplies the wheel load required to negotiate an inverted surface. Differential thrust supplies roll torque, but necessarily also changes the translational motion. A finite gas supply reduces the force available later in the flight. Landing then becomes a coordinated problem of attitude, pressure, velocity, and remaining height.

Changing a few parameters and rerunning the model makes these relationships visible. A heavier car needs more attachment and braking force. A shorter roll time demands more torque. A leakier seal consumes more fan power. A later braking command leaves less distance to remove the downward speed. The spectacle becomes an understandable sequence of force balances—and a useful example of how Wolfram Language can connect a physical argument, a numerical model, and an animation.

References

[1] Tesla. Roadster product page. Manufacturer description of the fan, sealing, and cold-gas systems. Accessed October 19, 2026.

[2] Tesla. The Ramp | Roadster, and Roadster Event. Manufacturer footage of the ramp and recovery sequence, October 2026.

[3] Tesla. The Kickflip | Roadster. Manufacturer footage of the fleet jump and barrel roll, October 2026.

[4] NASA Glenn Research Center. Rocket thrust equations. Momentum and nozzle-pressure contributions to reaction thrust.

[5] Wolfram Research. NDSolveValue, WhenEvent, AnimatedImage, and GIF import and export. Wolfram Language documentation.

For the engineering background, see Hagerty’s interview with Tesla’s Lars Moravy. The reconstruction’s numerical assumptions should not be read as a transcription of that vehicle’s specifications.

CITE THIS NOTEBOOK

How does Tesla's Roadster fly? Exploring the physics
by Jayanta Phadikar
Wolfram Community, STAFF PICKS, October 19, 2026
https://community.wolfram.com/t/28368

" sandbox="allow-same-origin" style="height: 17281px; max-height: none;" frameborder="0" scrolling="no">

FlyingRoadster_Community.wl (99.6 KB)

DOWNLOAD-DESKTOP-NOTEBOOK.nb (638.0 KB)

Read full topic