Grade Core technical FAQ

Grade Core is a prelaunch grade-intelligence, sensor, project-surface, and fleet platform built exclusively for 1/14-scale RC construction models. It combines normal RC operation with measured implement guidance, LiDAR capture, RTK positioning, project design, diagnostics, and private hosted workspaces.

No. You continue using an ordinary compatible RC transmitter and receiver for primary driving. Grade Core is a separate measurement and assistance layer connected through an onboard gateway and mapped implement outputs.

Grade Core launches as an operator-first grade-assistance system, not unrestricted autonomy. You retain control of travel and steering while approved implement channels can receive bounded corrections only when every local and hosted interlock passes.

No. Every Grade Core product, page, connector, project, and safety assumption is limited to 1/14-scale RC models. It must never be connected to or used for full-size machinery.

Initial machine profiles cover dozers, motor graders, pavers, milling machines, compactors, excavator-mounted tools, loaders, survey rovers, and custom model-scale equipment. Available functions depend on each machine’s geometry, sensors, mapped controls, and validated capability profile.

The Grade Core engine compares measured tool geometry with the selected project surface. It evaluates cut or fill, vertical error, cross slope, heading, tolerance, confidence, machine limits, and interlocks before returning a bounded, short-lived target.

No. A prelaunch account reserves your identity and hardware preferences. Device enrollment, live telemetry, LiDAR processing, machine commands, subscriptions, and paid entitlements are not active during prelaunch.

Yes. At launch, every customer receives an isolated workspace for accounts, projects, devices, files, commands, and storage. One customer cannot view or control another customer’s RC equipment.

No. Supported connectors expose only the documented communication and integration functions required by approved hardware. The grade engine, hosted service, owner controls, and protected processing logic remain proprietary.

No single component can guarantee a particular result. Your measured accuracy will depend on RTK quality, correction age, antenna geometry, time synchronization, tool calibration, servo resolution, linkage backlash, chassis and blade flex, surface quality, and operating conditions.

No. The standard Grade Core hardware configuration uses a Raspberry Pi 5 plus an ESP32-S3. The Pi handles sensors, storage, networking, and the Grade Core connection; the ESP32 handles deterministic local I/O, servo output, watchdogs, and fail-safe behavior. A separate Arduino is normally unnecessary.

No. An ESP32 can generate servo PWM and read receiver or sensor inputs, so it can replace a classic Arduino in the standard Grade Core connector. Some builders may use an Arduino they already own, but it is an alternative local I/O controller rather than a third required computer.

Yes. An ESP32 can read PWM or PPM receiver channels, decode supported serial receiver protocols with the correct electrical interface, generate servo PWM, read switches and feedback sensors, and communicate over UART, CAN, I2C, or SPI. It uses 3.3-volt logic and must not power servos or motors directly; use level conversion when required and a properly sized external BEC or actuator supply.

Technically yes, especially through an external PWM controller, but Linux is not a hard real-time operating system. Grade Core uses an ESP32 or comparable microcontroller for deterministic servo output, command expiry, and local timeouts in production configurations.

An ESP32 can send basic measurements and control a limited number of outputs, but it is not the full Grade Core gateway for 3D LiDAR, large recordings, camera streams, rich diagnostics, multiple drivers, or extended offline buffering. In the standard configuration, it serves as the local control node beside the Pi.

A classic Uno or Mega can handle deterministic low-level I/O but is too constrained for Grade Core device identity, secure connections, LiDAR drivers, files, recordings, and multi-sensor workloads. The supported standard configuration uses a Raspberry Pi 5 with an ESP32-S3.

Yes, as an integration profile if the chosen Arduino exposes the required serial or CAN protocol, watchdog, output limits, and safe startup behavior. The ESP32-S3 remains preferable because it combines capable I/O, strong tooling, watchdogs, and modern security features.

Only for a limited experimental machine. Without the Pi, the model loses the standard Grade Core gateway for sensor drivers, buffering, certificates, updates, recordings, and diagnostics, so this is not a supported full-system configuration.

All three are useful only in a specialized build—for example, a Pi gateway, an ESP32 safety and servo controller, and an existing Arduino dedicated to a legacy sensor or lighting system. Grade Core does not require three boards simply to move a blade servo.

It runs supported LiDAR, RTK, IMU, camera, and gateway services; timestamps and buffers telemetry; stores recordings; maintains authenticated network sessions; presents local diagnostics; and exchanges validated data with the Grade Core backend.

It reads mapped local inputs, produces deterministic servo or actuator commands, checks command sequence and expiry, clamps range and slew rate, monitors Pi heartbeat, enforces manual priority, reads the physical E-stop, and reports the output actually applied.

Not by itself. Grade Core combines the ESP32 with manual-priority hardware, an independent physical E-stop or actuator-enable circuit, safe power design, watchdogs, and a defined neutral or manual fallback.

Grade Core uses a wired local link. UART supports early configurations, CAN provides robust framed messages and error detection, and USB serial is convenient for bench work. Messages include the protocol version, machine identity, sequence, timestamp, expiry, validation data, operating mode, and acknowledgement.

No. The Raspberry Pi maintains the authenticated hosted connection, device certificate, buffering, and update workflow. The ESP32 accepts only the bounded local protocol and returns to its configured safe state if the Pi or network disappears.

No. Servos and actuators require a correctly sized regulated supply or BEC designed for their stall current. The computer and control electronics also require stable power, correct grounding, filtering, and protection from servo-induced voltage drops.

No. RAM affects how much software, buffering, visualization, and local processing the gateway can run. Grade accuracy comes from measurement quality, timing, calibration, geometry, mechanical repeatability, and the control model.

Yes for a headless entry gateway using a 2D LiDAR, RTK or GNSS, IMU, ESP32 link, telemetry, and modest recording. It leaves less room for large point clouds, multiple cameras, containers, ROS 2 components, and local visualization.

Yes. The 8 GB Raspberry Pi 5 is the standard Grade Core recommendation because it provides headroom for 3D LiDAR drivers, RTK, IMU, camera input, recordings, diagnostics, local previews, containers, and connector services without requiring the highest-memory board in every model.

The 16 GB model is useful for development gateways, local SLAM experiments, large offline point-cloud work, several cameras, heavy containers, compilation, or long offline buffers. Most customers will not need 16 GB when Grade Core performs the heavy processing online.

A Pi 4 can support reduced profiles, especially 2D LiDAR and basic telemetry. The Pi 5 is the Grade Core launch baseline for performance and continued support, while final compatibility depends on workload, ports, power, and thermal conditions.

Yes for most Pi 5 installations, especially inside a scale model with restricted airflow or near motors and batteries. Thermal throttling can increase latency and interrupt recording even while the gateway still appears online.

Use at least 64 GB high-endurance storage for a basic gateway. A 128 GB high-endurance card is more practical, while 256 GB or larger NVMe storage is recommended for frequent 3D LiDAR or camera recording.

No for basic telemetry and short 2D recordings. It becomes valuable for sustained 3D point-cloud capture, cameras, large datasets, faster exports, and better write endurance.

Yes. The Grade Core connector boots, connects, records logs, and recovers without requiring a keyboard or monitor. A local display is optional for diagnostics and is not part of the model’s safety path.

Yes. A Pi-connected display can show connection state, RTK fix, sensor health, mode, latency, tool error, and fault information. Owner and account functions still require authenticated access.

No. The ESP32 handles deterministic output and local timeouts, while the Pi and hosted Grade Core service provide higher-level measurements and bounded targets.

Support is scheduled after physical hardware validation. The released Logitech profile will provide device discovery, live input inspection, calibration, remapping, disconnect detection, and machine-specific assignments through the Grade Core desktop connector. The prelaunch website cannot read or control this hardware.

Yes. They are included in the same future operator-station profile. When released, Grade Core will recognize the wheel, pedals, and side panel as Windows reports them, including configurations where they appear as separate USB devices. Control assignments remain unavailable until calibration is complete and a compatible RC machine profile is selected.

The controls will connect by USB to the Grade Core Windows desktop connector. The connector reads local inputs, applies your saved calibration and mapping, and sends normalized, short-lived operator input to the authenticated Raspberry Pi gateway. Grade Core manages the account, mapping revisions, permissions, monitoring, and audit records without placing internet latency in the continuous local control path.

Potential mappings include blade lift, blade tilt, moldboard rotation, side shift, screed functions, attachment selection, work lights, mode requests, camera selection, horn, speed or sensitivity limits, and other machine-specific functions. No physical label is treated as a fixed Grade Core command; every assignment is explicit, visible, reversible, and scoped to the selected machine profile.

Not in the first release. A later supervised operator-station mode may add mapped steering and travel input, but it will retain an independent local stop and recovery path. Output begins disarmed, requires intentional operator enable, rejects stale input, and returns to the configured manual, neutral, or inhibited state on disconnect.

No. The Logitech controls will connect through the signed Grade Core desktop application, which can recognize Windows input devices, handle hot-plug and calibration, and maintain a low-latency local path to the Raspberry Pi gateway. The prelaunch website remains informational and account-focused.

The calibration wizard will identify each connected component, display every raw axis, button, and directional control in real time, and capture center, minimum, maximum, direction, dead zone, response curve, button behavior, and an optional hold-to-enable input. Grade Core stores a versioned mapping for your account and selected machine profile and requires confirmation before it can be armed.

The current operator input expires locally. The Pi and ESP32 stop accepting the affected controls and enter the configured manual, neutral, or inhibited state without waiting for the website. Reconnection never resumes motion automatically; the devices, mapping, input health, receiver state, and safety interlocks must pass again before re-arming.

At launch, a short-lived target will travel from the hosted Grade Core engine to the Pi gateway, then as a validated local target to the ESP32, and finally as a clamped servo output through a manual-priority integration circuit. The ESP32 reports the output it actually applied so requested and applied values remain distinct.

No. Your receiver remains the primary operator-control source. Grade Core connects only to explicitly mapped assistance channels and preserves a reliable manual-control or tested neutral path.

It depends on the machine and integration profile. A dozer might map blade lift and tilt; a grader may require lift, side shift, rotation, and articulation-related inputs. Travel, steering, mode selection, and manual override remain explicit channels or independent controls.

Yes when their torque, speed, duty cycle, voltage, repeatability, and mechanical installation match the machine. Grade performance may be limited by servo deadband, linkage play, flex, and inconsistent return position.

Calibration maps commanded pulse or position to the actual working-tool geometry. Grade Core needs neutral, direction, safe minimum and maximum, rate limits, linkage response, and the measured relationship between actuator movement and tool-edge movement.

It is a hardware- or firmware-supervised device that selects whether a mapped servo receives the receiver signal or the assistance signal. Its default and failure state favors manual receiver control or a tested neutral condition.

Software override is useful, but it is not the only protection. A physical mode input or signal path can remove Grade Core assistance independently of the web page, hosted service, and Pi process.

The ESP32 expires the current assistance command, stops following hosted targets, and moves to the configured safe state—normally manual receiver priority or a tested neutral output. This timeout occurs locally and does not depend on a website request.

The local controller rejects expired commands, old sequence numbers, duplicates, invalid checks, disarmed modes, and values outside configured range or rate limits. A rejected command creates a diagnostic event without moving the actuator.

Potentially, through an appropriate motor controller or actuator interface with position feedback and current limits. Grade Core never drives a power actuator directly from a Pi or ESP32 pin.

It is strongly recommended for serious grade assistance. Commanded PWM is not proof that the tool moved. Position feedback, linkage sensing, or tool-pose measurement lets Grade Core compare requested, applied, and measured behavior.

Yes. Existing lighting, sound, and accessory controllers can remain independent. Grade Core only needs a documented interface to the sensors and mapped implement functions involved in the selected machine profile.

The RPLIDAR C1 is included in the planned 2D sensor profile, but it is not yet listed as production-validated. It can provide planar ranges, cross-sections, local profiles, obstacle information, and recorded scans. A native full 3D yard point cloud requires a 3D sensor or additional measured motion, pose, and reconstruction.

The desktop connector will enumerate serial devices and suggest likely profiles. You confirm the COM or device path, baud rate, model family, scan mode, orientation, and calibration before use. Detection never silently selects an actuator or enables assistance.

A 2D unit measures ranges in one scan plane. A 3D unit produces points across vertical and horizontal fields of view. Grade Core enables only the processing features supported by the connected sensor and its calibration.

It can contribute to a reconstructed 3D dataset if its motion and pose are measured accurately, but this is not the same as receiving native 3D frames. The result depends on synchronization, trajectory quality, calibration, and scene motion.

The Unitree L2 combines a three-dimensional point cloud with an onboard six-axis IMU. In a supported Grade Core build, its measured frames can contribute to yard capture, motion-aware mapping, ground classification, surface generation, obstacle context, quality reporting, and fusion with RTK position and heading. Advanced functions appear only after the connected hardware, timestamps, calibration, and data quality are validated.

No. The L2 body is approximately 75 × 75 × 65 mm, and a complete installation also needs room for the Raspberry Pi or other supported gateway, RTK receiver, antennas, local controller, power regulation, cooling, cables, and safe service access. Some compact models may not have enough usable space or may require significant modification, so Grade Core cannot promise compatibility with every model.

Grade Core will do its best to support practical installations, including removable mounts and optional scale-styled external covers that can resemble an HVAC unit, GNSS enclosure, electrical cabinet, or other believable machine detail. These covers can hide and protect selected electronics without pretending that every model has unlimited room. Fit, airflow, antenna view, LiDAR field of view, wiring, weight, weather exposure, and safe access still have to be checked for the individual build.

No. Grade Core is capability-based. A supported 2D LiDAR can provide measured polar scans and basic capture functions, while a supported 3D LiDAR with IMU can unlock richer mapping and surface-processing workflows. RTK-only or reference-sensor workflows may also be possible for selected tasks. The dashboard enables only the functions that the connected and validated hardware can actually provide.

No. This shared-hosting prelaunch site provides product information, account reservation, news, policies, beta interest, and launch previews. Real Unitree L2 telemetry, Holybro UM982 RTK and heading, LiDAR processing, device commands, and private customer workspaces belong to the separate VPS launch platform and signed Grade Core connector applications.

Not for every workflow. RTK plus calibrated machine geometry can support position-based guidance, while sonic or laser-style references can support local elevation tasks. LiDAR adds existing-ground capture, surface comparison, obstacle context, and as-built information.

RTK is recommended when the machine and tool must be placed repeatedly in a project coordinate frame. Local relative systems may work without it, but ordinary GNSS usually cannot provide the consistency expected for model-scale grade assistance.

A properly installed dual-antenna receiver can estimate heading even when the model is stationary or moving slowly. Antenna spacing, baseline calibration, multipath, correction quality, and mounting rigidity all affect the result.

The IMU contributes pitch, roll, angular rate, and motion context. This helps transform antenna and LiDAR measurements to the chassis and working tool, especially when the model operates on a slope.

No. An IMU measures motion and orientation but accumulates drift when used alone for position. It complements RTK, LiDAR, wheel or track motion, and tool sensors rather than replacing an absolute or mapped reference.

Yes. Sonic sensors can support local height, material, edge, or reference measurements when their beam, target, temperature sensitivity, update rate, and mounting suit the task. Grade Core reports their capabilities separately from LiDAR.

Cameras can support operator views, evidence, visual diagnostics, and future fusion experiments. They increase bandwidth, storage, privacy, lighting, and processing requirements, and they do not silently become a required safety sensor.

Calibration records the rotation and translation between every sensor, antenna, pivot, chassis reference, and working edge. A precise sensor can still produce a wrong blade elevation when its physical offset or orientation is wrong.

It is critical when the model is moving. LiDAR points, RTK positions, IMU orientation, servo feedback, and commands must refer to compatible times; otherwise the system can calculate the correct geometry at the wrong location.

Grade Core holds or disarms modes that require fixed RTK. The dashboard reports the real fix state, correction age, and confidence instead of continuing to display fixed-quality guidance.

The hosted grade engine requires a secure network path. The local system must remain safe during an outage, stop using expired assistance, preserve manual RC operation, and optionally buffer measurements for later upload.

Yes. Wi-Fi is expected for many yards and indoor events. Ethernet may be preferable for development or fixed stations, while a dedicated access point can provide more predictable local coverage.

Potentially, if latency, coverage, data allowance, firewall behavior, and stability are acceptable. The local safety design must never assume that a cellular or hotspot connection will remain available.

Every command carries an expiry and is rejected locally when it arrives too late. Grade Core can reduce capability, hold guidance, or disarm assistance while you continue with normal RC control.

The cloud can provide stronger surface processing, account isolation, storage, updates, fleet context, and proprietary computation without forcing every model to carry heavy hardware. The Pi still performs the local work needed for measurement, buffering, validation, and safe handoff.

No. Upload behavior is selected by workflow and service access. Live guidance may use normalized measurements, while LiDAR capture or processing jobs can upload recorded frames or point clouds. The interface identifies what is being transmitted and stored.

At launch, a protected one-time setup will enroll each gateway into one customer workspace and issue a scoped device identity. Ordinary telemetry cannot assign a gateway to an arbitrary account.

Authorized roles can allow several viewers or operators, but command ownership remains explicit. Conflicting sessions, stale browser tabs, or a second account cannot silently take control of a model.

A physical local control that can remove actuator enable or assistance independently of the website, cloud, Pi process, and ordinary API path. A web E-stop is useful as an additional request but cannot be the only emergency protection.

Assistance starts disarmed. The local controller completes self-checks, confirms receiver state, validates configuration and calibration, establishes heartbeat, and requires explicit arming before applying Grade Core output.

The model returns to its configured safe state and requires fresh authorization and arming. It does not replay the last hosted command or resume an old automatic mode merely because configuration was restored.

Every assistance target is valid only for a short, defined interval. When its expiry passes, the ESP32 rejects it and uses the configured manual or neutral fallback instead of holding a stale correction indefinitely.

The local controller limits position, direction, speed, rate of change, and optionally current or force to the calibrated range for that machine and mode. Hosted software cannot bypass those local bounds.

At launch, travel and steering remain under direct operator control. Any later coordinated-movement capability will require independent local interlocks, geofencing, testing, unmistakable arming, and a separately defined feature set.

It may be read by the ESP32 for diagnostics, but the physical stop also affects actuator enable or the assistance signal path electrically. A firmware crash cannot be allowed to prevent the stop from taking effect.

Grade Core rejects the affected measurement, holds or disarms its dependent mode, and identifies the real fault on the dashboard. Demo data never replaces missing telemetry in a live operational view.

No control system can guarantee that. Builders remain responsible for assembly, power, mechanical limits, testing area, bystanders, materials, radio operation, manufacturer instructions, and immediate local intervention.

Begin with the model raised off the ground or the tool unloaded. Verify direction and manual priority, test every timeout and E-stop, use reduced limits, compare requested versus applied output, and only then perform slow, supervised material tests.

At launch, you will be able to record through a supported connector or import a supported dataset, assign coordinate information, inspect quality, process a surface, and keep the result inside your private project.

At launch, export options will include supported raw or normalized recordings, processing reports, derived point clouds or surfaces, and project-compatible products according to sensor capability and service access.

No single connector can support every model automatically. Grade Core uses driver profiles and a capability matrix. Generic import can cover documented file formats, while live hardware support requires a tested transport, data decoder, timestamps, and calibration model.

It states what the connected device can actually provide—for example 2D ranges, 3D points, intensity, IMU, hardware timestamps, return count, or scan mode. Features remain unavailable when the required capability is missing.

A project surface represents the target or measured geometry used for comparison. It may describe a flat pad, percentage slope, crown, swale, alignment, imported design, existing ground, or as-built result.

Cut is material above the target surface that needs to be removed; fill is a location below target that needs material. Grade Core displays model-scale values in clear millimeter or centimeter units against the selected project reference.

You retain ownership of your original RC projects and datasets. The applicable terms authorize Grade Core to store and process them only to provide, secure, support, and improve the requested service.

The prelaunch shared-hosting site includes encrypted application backups and manual recovery controls. The hosted launch platform will add independent offsite backups, retention rules, restore testing, and tenant-aware storage protection.

No. The prelaunch site does not process payments, accept deposits, create orders, store payment keys, or activate subscriptions. Service plans and checkout remain informational previews.

Yes. The prelaunch site includes a protected account-migration path designed to preserve your identity, password hash, verification state, preferences, policy acceptance, and beta records when the hosted Grade Core platform launches.

No. Beta participation is optional and Grade Core can perform development internally. Interested builders may participate through invitation-based, role-scoped testing without affecting ordinary prelaunch access.

Yes, unless a specific written test assignment says otherwise. Participants fund their own RC model, gateway, sensors, positioning equipment, materials, tools, connectivity, and normal operating costs.

A tester who is accepted by the owner and completes the defined milestones can receive twelve consecutive months of complimentary Grade Core Advanced access after commercial launch. Applying or enrolling alone does not earn the reward.

Only active, verified accounts with a current news opt-in can enter an email campaign queue. Each campaign includes a signed unsubscribe link; opting out does not remove access to essential security messages or the private account news feed.

After signing in, open Account News from the navigation or account workspace. The owner can publish updates for all accounts, verified accounts, or beta testers without requiring marketing-email consent.

The Policy Center is linked from the public navigation, footer, account area, beta workspace, and owner administration. It includes prelaunch terms, privacy, RC-only safety, and beta participation information.

The page was submitted with an expired, missing, or different session token. Reload the exact page, sign in again if necessary, re-enter the form data, and do not resubmit an old page from the browser Back cache.

A selected profile is not proof of a live device. Confirm power, USB or Ethernet link, operating-system device enumeration, COM or device path, permissions, baud rate, driver profile, scan mode, and whether another program has already opened the sensor.

Common causes include the wrong COM port, wrong baud rate, insufficient USB power, another application holding the port, a mismatched model command, motor or cable problems, or a driver expecting a scan mode the device does not support.

Operational views must remain empty until validated telemetry arrives from an enrolled source. Check gateway identity, account assignment, connector health, sensor frames, timestamps, network path, and capability status rather than enabling demo data in live mode.

Check correction input, antenna view, antenna power, base or NTRIP configuration, coordinate settings, multipath, correction age, baseline configuration, and receiver status. Grade Core displays the receiver’s actual solution state.

Investigate time synchronization, IMU vibration, antenna and tool offsets, servo feedback, linkage backlash, flexible mounts, RTK state, LiDAR motion distortion, coordinate-frame mistakes, and excessive controller gain before changing the design surface.

The local or cloud system detected a failed interlock such as stale telemetry, missing heartbeat, invalid calibration, RTK degradation, sensor fault, command expiry, physical E-stop, manual override, account entitlement, or device-certificate problem.

Include the machine profile, gateway and firmware versions, sensor models, connection type, project and mode, time of failure, real status indicators, relevant logs, expected behavior, observed behavior, and whether manual control and E-stop worked correctly.