GRIDLANTIS / RESEARCH

Open research log

We build the things to find out if and how they work

Gridlantis runs a small, self-funded Build lab alongside the services practice. Everything below is live work: neural simulation, ground robotics, and public-signal monitoring.

Why a services company runs a lab

The Build lab exists to answer questions the client work keeps raising. How little can a tool depend on and still be worth running? What can stay on the device instead of leaving the building? Where does a control loop stop being arithmetic and start being behavior?

The entries below are written the way they are kept: setup, open question, current state. When a result comes in, it gets posted here whether or not it supports the hypothesis.

3 shown

Fly neuron test

A fly brain, wired from the connectome, driving a physical body

The FlyWire FAFB dataset gives a full synapse-level wiring diagram of an adult fruit fly brain. FlyGym gives a physics body, a NeuroMechFly model with real joint limits, contact, and gravity, simulated in MuJoCo. This line couples the two: the connectome supplies the network topology, the body supplies the sensory input and consumes the motor output, and nothing in between is hand-tuned to make walking happen.

Open question If the only thing you specify is who connects to whom, how much coordinated behavior falls out of the structure by itself?

Connectome
FlyWire FAFB, adult female brain
Body & physics
FlyGym 2.1.0 (NeuroMechFly) on MuJoCo
Bench
CachyOS Linux · NVIDIA RTX 3060, 12 GB VRAM
Next step
Shuffled-connectome control run with the same degree distribution and randomized edges
Where it stands
Coupling verified, baseline gait not yet characterized

Ask about this line

Rendering of an adult fruit fly brain from the FlyWire connectome, with optic lobes, mushroom bodies, and central complex neurons traced in blue, orange, and magenta.
FlyWire FAFB — adult brain, traced neuron populations

R.I.M.D.A.RRobotic · Intelligent · Mobile · Driving · Autonomous · Rover

Obstacle avoidance without a map

A four-wheel ground platform on a Raspberry Pi 4B, driven through an L298N motor bridge, with three RCWL-1601 ultrasonic rangefinders reading left, center, and right. No simultaneous localization and mapping, no odometry, no memory of the room, just three distances and a control loop. The interesting work turned out to be everything around the decision: slew-rate limiting so the chassis stops lurching, dynamic braking so it stops where it decided to, and a calibration pass because the sensors disagree with each other and with the tape measure.

Open question How far can a purely reactive robot get before the absence of a map is the thing that actually stops it?

Compute
Raspberry Pi 4B ("cyberdeck")
Drive
L298N dual H-bridge, software pulse-width modulation
Sensing
3 × RCWL-1601 ultrasonic, per-unit calibration offsets
Control
avoider.py: slew-rate limiting, dynamic braking, sensor fusion across three channels
Where it stands
Runs unattended, corner-trap recovery still unsolved

Ask about this line

Line drawing of the R.I.M.D.A.R rover, front view: four-wheel chassis, stacked compute and battery decks, and a forward-facing ultrasonic rangefinder.
R.I.M.D.A.R — front elevation

Optic Oversight

Reading a city from its public signals

A single-pane view of one metro area, assembled only from feeds that are already public: traffic incidents and flow tiles, traffic camera stills, aircraft positions, and radio scanner audio. No private data, no scraping behind a login. It began as an exercise in feed reliability, because most of these sources go down, rate-limit, or silently change shape. It turned into a study of how much situational picture you can assemble from sources nobody is protecting.

Open question If this much is assemblable from open feeds by one person in a weekend, what should a city assume about its own signal exhaust?

Runtime
Node.js, zero packages, single file
Sources
TomTom traffic tiles and incidents · camera stills · flight positions · scanner audio
Method
All third-party feeds proxied server-side to keep credentials off the client
Why parked
Upstream feed churn outpaced maintenance, waiting on a stable source set
Where it stands
Runs locally, not published

Ask about this line

Working together

Bring us a question you can't get a straight answer to.

The Build lab takes on outside problems when they're genuinely open: a system nobody can characterize, a build nobody wants to own, a claim a vendor keeps making that you'd like independently tested. Remote-friendly, with student and community projects welcome.

Start a conversation