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

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

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.

Snow Formation Lab is an interactive simulator that follows one snowflake from rising air to the ground in four stages.

Stage 1 · Rising Air

• Set surface temperature, dew point, environmental lapse rate and lift height, and watch an air parcel rise and turn into cloud.
• Below the cloud base the parcel cools at the dry adiabatic rate (9.8 °C/km); inside the cloud it cools at the moist adiabatic rate, computed from the full formula.
• The scene marks the cloud base, 0 °C, −10 °C (ice nuclei become active), the dendritic growth zone (−12 to −18 °C) and −38 °C (droplets freeze on their own).
• Based on cloud-top temperature, the cloud is classed as warm, supercooled or mixed-phase (snow-producing).
• Presets: winter front, summer storm, dry day.

Stage 2 · Ice vs Droplets (Bergeron process)

• A microscope view shows vapor moving from supercooled droplets onto ice crystals. The droplets shrink, and the crystals grow until they are heavy enough to fall.
• A chart plots saturation vapor pressure over water and over ice, and marks where the gap between them peaks, near −11.8 °C.
• You can seed the cloud by clicking or with silver iodide (AgI). Below −38 °C every droplet freezes spontaneously.

Stage 3 · Crystal Growth

• Click a temperature and supersaturation on the Nakaya diagram and that crystal grows live.
• Plate crystals grow on Reiter’s (2005) hexagonal diffusion model. As conditions change they progress from hexagonal plates to sectored plates, broad-branched stars, stellar dendrites and fern-like dendrites, and you can see vapor being used up around the crystal.
• Needles and columns, including hollow columns, are drawn as 3D prisms.
• Presets: dendrite, plate, needle, sector, column, fern.

Stage 4 · The Fall

• Drag points on the temperature profile from the 3 km cloud base down to the ground. Humidity sets the wet-bulb temperature, which decides whether flakes melt or refreeze.
• The ground result is classified as snow, wet snow, sleet (ice pellets), freezing rain or rain, and shown as accumulated snow, icicles or puddles.
• Each of the five presets (snow, rain, sleet, freezing rain, and snow at +2 °C in dry air) gives its expected result 100% of the time.

Verified: all four stages ran in a headless browser with no script errors and no horizontal scroll at phone width.

Limitations

• Crystal shapes come from mapping Reiter-model parameters onto regions of the Nakaya diagram, not from an empirical growth formula.
• Melting and refreezing in the fall stage are simplified for teaching.
• Rounding in the step-by-step calculation can make crystals slightly asymmetric.

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.

아두이노(Arduino)는 누구나 쉽게 대화형 전자 제품과 사물인터넷(IoT)을 만들 수 있도록 제작된 오픈소스 하드웨어 및 소프트웨어 생태계입니다. 자료는 아두이노(arduino) 입문자용 가상 시물레이터 입니다.

구성

• 보드: UNO R3(ATmega328P, 16 MHz)와 UNO R4 Minima(RA4M1, 48 MHz) 중 고를 수 있습니다. 헤더 핀, PWM ~ 표시, L·TX·ON LED, 리셋 버튼을 그렸고, 사용 중인 핀은 금색으로 표시됩니다. 공식 로고는 넣지 않았습니다.
• 브레드보드 부품: LED(220 Ω), RGB LED, 푸시 버튼(풀다운 / GND·풀업 배선), 가변저항, 조도 센서, TMP36 온도 센서, SG90 서보, 피에조 부저, 16×2 LCD를 놓을 수 있습니다. 부품을 더하거나 빼고 핀을 바꿀 수 있고, 버튼은 누르고 있기, 가변저항은 드래그, 빛·온도는 슬라이더로 조작합니다.
• 전선 색: 핀 상태에 따라 바뀝니다. 빨강은 HIGH, 주황은 PWM, 보라는 tone, 파랑은 입력입니다.
• 코드 편집기: 구문 강조가 되고, 지금 실행 중인 줄을 초록색으로 표시합니다. Ctrl+Enter로 업로드하고, 일시정지·리셋, 시간 배율 0.25–4×를 지원합니다.
• 시리얼: 모니터에서 보드로 글자를 보낼 수 있습니다. 플로터는 이름:값 형식의 출력을 여러 선으로 그립니다.
• 핀 패널: D0–A5 상태 표와 사용 중인 핀의 파형을 보여줍니다.

예제 12개: Blink, 버튼, 페이드(PWM), 가변저항 읽기, 신호등(millis 상태 기계 + 보행자 버튼), 서보 스윕, 멜로디(「작은 별」, 실제 소리), 야간등, LCD 온도계, RGB 무지개, 시리얼 명령, 떠 있는 입력(INPUT → INPUT_PULLUP으로 고쳐 보기).

실수를 알려 주는 경고

• PWM이 안 되는 핀에 analogWrite를 쓴 경우
• pinMode 없이 HIGH를 써서 LED가 희미하게 켜지는 경우
• Serial.begin을 빠뜨린 경우
• D0·D1이 시리얼과 충돌하는 경우
• tone을 두 핀에서 동시에 쓴 경우
• LCD에 한글을 출력한 경우

한계: 스케치를 아두이노 C의 자주 쓰는 부분만 JavaScript로 바꿔 실행합니다. 그래서 정수 나눗셈, 포인터, 구조체, static 지역 변수는 실제와 다르게 동작하거나 지원되지 않습니다. 세미콜론을 빠뜨려도 JavaScript 규칙 때문에 오류 없이 넘어가는 경우가 있습니다.

검증: 헤드리스 브라우저에서 12개 예제를 모두 변환·실행해 오류가 없는 것을 확인했습니다.

• 가변저항 512 → 2.50 V, TMP36 24 °C → LCD 23.8 °C(ADC 양자화 때문)가 정확히 나옵니다.
• 버튼 누름/뗌에 따라 LED가 켜지고 꺼지고, 시리얼 명령 ‘1’을 보내면 LED가 켜집니다.
• 떠 있는 입력은 0과 1을 오가다가 INPUT_PULLUP으로 고치면 1로 안정됩니다.
• while(true); 같은 무한 루프에서도 페이지가 멈추지 않습니다.

Sources:

• Arduino