인공지능과 함께 만든 아이디어,
실행 가능한 서비스가 됩니다.

Three-Body Lab is an interactive browser simulator of the classical three-body problem. It uses the same dark sidebar-and-canvas layout as the Physics Playground.

Configurations

• Figure-Eight: a stable periodic orbit where three equal masses share one curve (Moore 1993, Chenciner & Montgomery 2000).
• Lagrange Triangle: an equilateral arrangement that rotates rigidly. It is unstable with equal masses and stable when one mass dominates.
• Butterfly I: an unstable periodic orbit found by Šuvakov & Dmitrašinović in 2013.
• Pythagorean: Burrau’s problem. Masses 3, 4 and 5 start at rest, go through chaotic close encounters, and one body is ejected.
• Hierarchical: a star, planet and moon, showing how a close pair with a distant third stays stable.
• Random Start: random initial conditions that usually turn chaotic.

Features

• Ghost twin: a copy of the system nudged by a tiny amount (1e-6 by default). A log-scale graph tracks how fast the two copies diverge, which shows chaos directly.
• Edit mode: pause the simulation, then drag bodies to move them and drag the arrow tips to set their velocities.
• Controls: speed, trail length, gravitational softening, twin nudge size, and a mass multiplier for each body.
• Live readouts: time, energy and its conservation error, angular momentum, closest separation, steps per frame, and twin separation.
• Navigation: the view auto-fits by default. You can also zoom with the scroll wheel and pan by dragging empty space. Bodies that leave the screen get an edge arrow with their distance.
• Shortcuts: Space to play or pause, R to reset.

Physics: the simulator uses Newtonian gravity with G = 1 and a leapfrog integrator. The time step shrinks automatically when bodies come close. A short note in the sidebar explains the history: Poincaré showed that no general closed-form solution exists, so the problem can only be solved numerically.

Microduck Simulator is an interactive 3D simulator of Pollen Robotics’ Microduck, a bipedal duck robot about 25 cm tall and 800 g. It is built on specifications taken from the official microduck runtime and microduck_rl training repositories.

Real robot details used

• Servos: 15 Dynamixel XL330s. IDs are 20–24 for the left leg, 30–34 for the neck, head and beak, and 10–14 for the right leg. The beak (ID 34) is excluded from every policy’s actions.
• Pose and limits: the actual HOME pose and joint limits. Sliders use the real robot convention (radians, signs as in HOME).
• Policy loop: runs at 50 Hz with a 61-D observation (angular velocity, gravity, joint positions, joint velocities, last action, commands) and a 14-D action, both shown live as a heatmap.
• Training settings: velocity command ranges of vx ±0.4 m/s, vy ±0.3 m/s and ωz ±1.0 rad/s; an air-time reward window of 0.125–0.3 s; 2 cm foot clearance; battery voltage from 6.5 to 8.2 V; ±1° backlash; and a ±0.3 m/s push range.
• Policy names: the top bar shows the real task ID for each mode, such as Mjlab-Velocity-Flat-MicroDuck.

Behaviours

• Walk: drive with the on-screen joystick or W A S D / Q E, and adjust body pose and head commands. Lengthening the gait period pushes air time out of the reward window.
• Roller skates: passive wheels under the feet and a swizzle glide with no foot lift.
• Sit · stand (Y): switched by a posture-flag command.
• Beak pick (G): the phase-encoded command can be seen circling in the observation panel. The duck can pick up the block and carry it while walking.
• Ball kick (K / L): shifts weight onto the support foot, then kicks a 70 mm ball.
• Forward roll (R): rolls over the head and lands back on its feet.
• Falls and stand-up: a push that moves the capture point past 62 mm knocks the robot over, and it gets back up by itself.
• Joint control: sliders for all 15 servos, plus the SIT and FOLD keyframes as presets.
• Quack (Space): opens the beak and plays a sound.

Panels

• Live readout: state, commanded and actual speed, trunk tilt, support, capture point and battery.
• Policy I/O: the 61-D observation and 14-D action.
• Foot contact: a contact timeline and the last air time for each foot.
• Servo table: target, actual and error for all 15 servos.
• Controls and overlays: camera presets, a support-polygon and centre-of-mass overlay, backlash and battery settings, and time scale.

Limitations: the motion comes from a kinematic generator (gait phases plus inverse kinematics), not from the trained ONNX policy or MuJoCo physics. Leg geometry is approximate, so poses can differ somewhat from the real robot, especially when the real SIT and FOLD keyframe values are applied directly.

Verified: headless Chromium ran every mode without script errors. Walking air time was 180 ms, inside the reward window. Push → fall → stand-up, block pickup and ball kick all worked, and there is no horizontal scroll at phone width.

Sources:

• pollen-robotics/microduck
• pollen-robotics/microduck_rl

It has four lessons. All numbers are in arbitrary units, and the page states that it is a toy model, not a forecast.

1. The Loop: each lap of the animation is one generation (research → build → test → deploy). You can set how much better each generation is at research and what share of the R&D work the AI does. While humans still do part of the work, each lap has a minimum time (Amdahl’s law); once the work is almost fully automated, each lap is faster than the last.
2. Returns: shows how the exponent α changes growth in the model dI/dt = c·Iᵅ. Below 1, growth slows over time; at 1, it is exponential; above 1, it reaches infinity in finite time (a “hard takeoff”). The analytic solution and the blow-up time are shown.
3. Bottlenecks: switch on, one at a time, compute (combined with ideas as a Cobb–Douglas production function), serial work that can’t be automated, and physical limits. With the same α, the “software only” curve blows up, while the bottlenecked curve bends down to follow the growth of compute.
4. Oversight: each generation’s goals drift slightly, and errors compound. When an evaluation catches a drift, the system rolls back and fixes it before continuing. If oversight does not scale with the model, the detection rate falls with each generation and more drifts slip through. The lesson also introduces safety research ideas: evaluations, interpretability, scalable oversight and staged deployment.

Laser Mosquito Fence is an interactive simulator of a laser mosquito-control device, inspired by the Photonic Fence research project. It models the decision logic (which insect to zap, and when), not the laser hardware.

How it works (five-stage pipeline)

1. Detect: insects flying in front of an LED backlight on the far side show up to the camera as dark shadows.
2. Classify: each insect’s species is judged from wingbeat frequency and size. Female mosquitoes beat at about 450–600 Hz, males at 650–900 Hz and honeybees at about 230 Hz. Confidence rises as observations accumulate.
3. Track: a steering mirror turns toward where the insect will be after the system latency. The mirror has a limited turning speed.
4. Safety: the whole beam path is checked. If a person is nearby, or a protected insect such as a bee is on the beam line, the shot is held.
5. Zap: only biting female mosquitoes get a short pulse. If a shot misses, the system tries again.

Four scenarios

• Evening garden: a mix of insects, the baseline case.
• Mosquito swarm: a throughput test with many mosquitoes queuing for the single mirror.
• Pollinator day: lots of bees, testing whether classification avoids hitting the wrong target.
• Someone walks by: the safety interlock when a person crosses the curtain.

Controls and display

• Sliders: confidence threshold, latency, mirror speed, sensor noise and safety margin.
• Buttons: slow motion, add a person or insects, and disarm.
• Wingbeat spectrum: click any insect to see its spectrum against the frequency bands of each species.
• Results panel: precision (share of zaps that hit female mosquitoes), mosquitoes that escaped, misses, safety holds and zaps per minute.
• Decision log: every zap, miss and hold, with the reason.

Verified: each scenario ran for 15 seconds in a headless browser with no script errors. At default settings, precision was 100% with no male mosquitoes or bees hit, and the person scenario held fire seven times. Raising sensor noise to 100% and lowering the confidence threshold to 50% caused a male mosquito to be hit by mistake and many more misses, which shows how the threshold and sensor noise affect the results.

All numbers are illustrative approximations.

Reed–Solomon Lab is an interactive browser simulator of Reed–Solomon error correction. It runs a real encoder and decoder over GF(2⁸), and every step of the repair updates live as you damage bytes.

Pipeline (top to bottom)

• Status and budget bar: shows how much of the correction budget 2e + s ≤ n − k is used. Errors cost 2 slots and erasures cost 1. The result is labeled Clean, Corrected, Decoder failure or Miscorrected.
• Step 1 – Encode: message bytes plus parity bytes form the codeword. The generator polynomial g(x) is shown.
• Step 2 – Channel: click received bytes to add errors (random values) or erasures (flagged positions). You can also add random hits or bursts.
• Step 3 – Syndromes: non-zero syndromes show that damage was detected.
• Step 4 – Berlekamp–Massey: computes the error locator Λ(x), plus the erasure locator Γ(x) when erasures are present.
• Step 5 – Chien search: a bar chart of |Λ| per byte position. Roots, which mark the error locations, are highlighted green.
• Step 6 – Forney: a table of error values and the XOR fix applied at each position.
• Step 7 – Decoded: repaired bytes are highlighted, and the sent, received and decoded text are compared side by side.

Scenarios: Sandbox, QR Code 1-M RS(26,16), Audio CD C2 RS(28,24), DVB-T RS(204,188) and Deep Space RS(255,223). Each comes with notes on how that code is used in practice. You can also edit the message and the number of parity symbols.

Verified: 4,000 random fuzz tests within the correction limit all decoded exactly. Damage beyond the limit never crashes the decoder; it is reported as a failure or a miscorrection.

AI Image Forensics is a browser-based tool that looks for evidence of whether an image was generated by AI or captured by a camera. It runs entirely in your browser and never uploads the image anywhere.

What it analyzes

• Metadata. It reads EXIF (camera make and model, lens, exposure, GPS, software), XMP, IPTC and JPEG comments. For PNG files it also reads text chunks, where tools such as Stable Diffusion WebUI and ComfyUI often store the prompt, sampler, seed and workflow.
• C2PA (Content Credentials). It detects whether a C2PA manifest is embedded. It then reads the claim generator, the recorded actions and the digital source type. A source type of trainedAlgorithmicMedia means the image was declared as AI-generated.
• File structure. It lists every JPEG segment, PNG chunk, WebP chunk or HEIF/AVIF box. For JPEG files it also estimates the compression quality.
• FFT frequency spectrum. It shows the 2D spectrum of the image’s noise residual (or its luminance), along with an azimuthally averaged power curve. Regular bright peaks can be traces of upsampling in generative models. Peaks on the JPEG 8×8 grid are marked separately, because they come from compression, not generation.
• Noise residual. It subtracts a 3×3 median-filtered copy from the original to reveal the noise layer. Camera sensor noise is usually spread evenly across the frame. Generated images may show little noise, inconsistent texture between regions, or repeating patterns.
• ELA (error level analysis). It re-saves the image as JPEG and amplifies the difference from the original. This is mainly useful for spotting locally edited or pasted-in regions in JPEG files.

How to read the results

The tool does not give an “AI or not” verdict. Instead, it lists each piece of evidence it finds and rates its strength:

• Strong: AI generation declared in C2PA or XMP, or generation parameters found in the file.
• Moderate: a generator or editing tool named in the metadata.
• Weak: camera EXIF alone, a resolution commonly used by generators, or periodic peaks in the spectrum.
• Inconclusive: no metadata at all. This is common for both generated images and photos that have been through social media or messengers.

The guiding principle is asymmetric. Evidence that is present is meaningful, while evidence that is absent tells you very little, because metadata is easily stripped or forged.

Limitations

• C2PA signatures are not verified. Use contentcredentials.org/verify for that.
• Invisible watermarks such as Google’s SynthID cannot be detected without the vendor’s own detector.
• Images that were shared through social media or messengers, re-compressed, or captured as screenshots lose most of their metadata and much of their signal-level evidence.