Every question, in one place.

This student edition provides an interactive 3D model, prototype imagery, the navigation guide, simulator and working templates. The company references reviewed for these explanations also included project documents and controller code; request their approved raw source files through the company project handover. GLB meshes are visual references, not native parametric CAD or a complete manufacturing drawing set. Request STEP plus native CAD, revisioned PDF drawings, electrical schematics and connector pinouts from Adaptive AgroTech, with release dates and access restrictions confirmed by the company. Begin the BOM and architecture now, marking missing dimensions for measurement.

Use a controlled project handover containing an as-built BOM, mechanical CAD and drawings, wiring and power diagrams, connector tables, firmware and host software, configuration files, interface documentation, test procedures and logs. This student web package explains the navigation assignment and command chain and provides teaching assets and working templates; raw company firmware, original reference archives and private repositories are not included. Their existence or availability must not be inferred from the explanations. Maintain a manifest recording each item, revision, owner, availability and open questions, and deliver new navigation designs and evidence against it.

For each Monday meeting, prepare a short status update covering last week’s commitments, measured results or a reproducible demonstration, blockers, decisions needed and the next week’s owners. Bring the current BOM, architecture revision and risk/open-question register when they have changed. Record actions with an owner and due date and attach concise test logs or screenshots rather than relying only on presentation slides. The meeting length and submission deadline remain for the supervisor and company to agree.

No signed NDA, IP allocation, publication agreement or software licence for the student work is supplied. SDU and Adaptive AgroTech must agree in writing how pre-existing company material, student-created CAD/PCB/code, business findings, third-party software and publication rights are handled. Keep company background IP and new contributions identifiable in the repository and record third-party licences. Do not infer ownership or a duty to sign an NDA from the presence of this package.

Nominate one student liaison and agree a single written channel with the company contact so questions, files and decisions remain traceable. Send technical questions with the component revision, symptoms, logs and the specific decision needed, and collect routine items for Monday meetings. The supplied materials do not establish a response-time commitment or a private support channel; request both at kickoff. Safety-critical or test-blocking issues should pause the affected activity until the responsible supervisor or company engineer resolves them.

The central outcome is an integrated LiDAR navigation prototype on the existing FieldScout drive platform, demonstrated with repeatable test evidence by the students’ stated 23 December milestone. Prioritise a bounded indoor mission: localise on a map, visit waypoints, react to obstacles and pass commands through the Jetson–ESP32–motor-driver chain. The report, architecture, BOM and code should make that demonstration reproducible and explain its limitations. Final acceptance criteria and the milestone date need company and supervisor agreement; commercial readiness is not established by a successful classroom demonstration.

Proposed ranking of the eight original EXT tasks is: (1) build and demonstrate a functional prototype; (2) develop navigation and obstacle avoidance; (3) integrate navigation sensors and communications; (4) evaluate power and battery integration; (5) implement a monitoring/control dashboard; (6) investigate operating requirements; (7) make the mechanical changes needed for secure mounts and service access; and (8) produce a proportionate market/commercialisation study. Items 1–7 are required to the extent needed for the scoped navigation demonstration; broad chassis redesign and commercial product development are extensions. Task 8 remains an assessed workstream if the EXT course requires it, but must not consume the critical navigation integration time. Approve the allocation with the supervisor before finalising the problem formulation.

A functional prototype should use a real LiDAR and onboard computer to estimate position in a bounded test area and execute a short waypoint mission through the existing ESP32 and wheel drivers. It must also support operator stop, obstacle response, loss-of-command handling, clear mode/status reporting and recorded test results. Before floor tests, demonstrate correct wheel order, signs, units and stale-command rejection with the robot securely supported. Browser motion and generated messages are valuable preparation, but are not evidence that real navigation or the physical safety chain works.

Target a controlled, dry indoor laboratory or greenhouse-like aisle first, with a level floor, known boundaries and no public or animal access. This supports repeatable mapping, localisation, obstacle and stopping tests while avoiding weather and terrain as additional unknowns. A greenhouse trial can follow once the same functions pass indoors; livestock and open-field operation should be separately scoped extensions. Covering all three environments convincingly is unlikely within one student integration project.

The revised core scope is LiDAR navigation, its hardware/power architecture, the Jetson-to-ESP32 interface, simulation, monitoring and validation on the existing drive platform. Treat AI crop diagnosis, solar charging, autonomous docking, LoRaWAN expansion, fleet coordination, mowing and complete motor-driver redesign as extensions unless explicitly added by the company and supervisor. Environmental sensing may be represented by one example payload without making a full agricultural sensing platform a prerequisite. Publishing browser commands for physical ESP32 consumption is a later phase specifically reserved by the company brief.

The package contains both actual prototype photographs and conceptual/CAD imagery, and they must be identified separately. The project document states that the physical base platform has already been 3D printed; presentation slide 8 describes subsystem integration as still in progress. The exploded image on project PDF page 1 is a design illustration, not proof of a fully integrated autonomous robot. Compare the delivered unit against photographs, GLB geometry and a measured as-built inventory before designing mounts.

The project document identifies an existing prototype, but provides no confirmed delivery date, transport arrangement or SDU handover appointment. Request a written handover plan covering the robot, batteries/charger, emergency-stop arrangement, cables, spare parts, firmware revision and permitted test conditions. Arrange an operating demonstration with the responsible company engineer and record the wheel identification and shutdown procedures. Meanwhile, students can complete the BOM, architecture and simulation tasks without assuming that the robot has already arrived.

The supplied material establishes integration gaps rather than a measured list of mechanical failures: final power distribution, navigation integration and complete autonomous validation are still open. The Sep09 sketch only prints a heartbeat, and the Sep10 sketch runs a timed demo; neither implements the CMD receiver expected by the Lua controller. The Lua geometry and nominal mass also differ from brochure references, so measure the actual robot before using them in navigation or mounting calculations. Inspect mount stiffness, cable strain relief, enclosure ventilation and service access and record findings instead of presenting suspected weaknesses as confirmed defects.

The Sep10 firmware documents a confirmed wheel/channel polarity mapping and comments that 90 and 150 RPM have been tested, but the attachments do not provide a complete physical test dataset or acceptance report. The available Lua script supplies a simulation/control example, not proof that the matching ESP32 receiver or all claimed protections are installed. Establish a baseline with wheel-by-wheel checks, straight and turning trials, timing/acknowledgement logs, stopping tests, current measurements and photographs of the test setup. Preserve raw logs and distinguish observations from values copied from comments or brochures.

For this revised assignment, retain the existing four-wheel drive, motors, motor drivers and ESP32 as the low-level actuation system; add the LiDAR navigation computer and supporting hardware above it. Students may design sensor mounts, protected power branches, wiring, communication adapters and navigation software and propose chassis changes that are justified by integration needs. LiDAR and supporting sensor choices are open subject to BOM review and compatibility checks. Changes to drive hardware, voltage, wheel geometry or the company’s control interface require an agreed design change and a new validation baseline.

Preserve the physical wheel mapping instead of assuming that driver LEFT/RIGHT means vehicle left/right: driver 2 LEFT is rear right with reversed sign. Keep rad/s at the Lua-style host interface distinct from signed integer RPM at the Modbus registers, and apply polarity conversion exactly once. Timed pivots do not prove heading accuracy, simulator parameters do not prove physical limits, and an acknowledgement does not measure wheel motion. Finally, inspect executable firmware rather than trusting filenames or comments: the Sep09 file is a heartbeat test and the Sep10 command-refresh constant is 100 ms despite messages/comments mentioning other rates.

The presentation identifies R&D and environmental monitoring as the initial focus, making researchers, technicians and agricultural R&D teams the most defensible first users. The day-to-day operator should be a trained person who sets up the test area, selects a mission, checks system readiness and supervises the prototype. Farmers, greenhouse operators and agronomists are potential future users whose workflows should be explored through interviews. Do not assume the student prototype is ready for unattended use by an untrained customer.

Use a short repeatable indoor mission as the first reference case: an operator checks readiness, starts a saved map/waypoint route, the robot visits a small set of stations, records time and pose, then returns to a designated stop point. Propose a 10–15 minute trial with 3–5 waypoints in a measured test area, subject to supervisor approval. Repeat the same mission across trials before increasing duration or area. Mission frequency, commercial area coverage and duty cycle need end-user input and are not specified in the supplied materials.

For the navigation prototype, record timestamped LiDAR scans, pose estimates, transforms, wheel commands, available measured odometry/IMU data, controller acknowledgements, faults and mission events. Log each stream at its actual acquisition or command rate and record units, frame identifiers and clock relationships; do not label commanded wheel speed as measured odometry. An optional environmental sample should include its value, unit, calibration identifier, timestamp and spatial reference. Sensor-specific accuracy and spatial/temporal sampling targets should be derived from the chosen instrument and mission, because the source documents do not define them.

No booked SDU-area farm, greenhouse or livestock test site and no named end-user interview commitment are provided. Ask the supervisor and company to nominate site owners and obtain access, operating restrictions, supervision and an agreed test window. Begin with a university-approved indoor area so progress does not depend on a farm visit. Prepare a short interview guide around mission value, aisle dimensions, obstruction types, supervision and acceptable downtime.

The initial acceptance environment should be dry, firm and approximately level, with measured aisle widths and obstacle locations. Record floor material, slope, traction and wheel slip for each trial; derive clearance from the measured robot footprint plus a test margin. Mud, grass, gravel, manure, crop contact and uneven terrain introduce additional traction and perception requirements and should be separate experiments. No confirmed row-spacing or terrain envelope is supplied for the actual robot.

Exclude live animals from the core student navigation trials and use controlled obstacle surrogates first. A later livestock trial needs a site-specific plan for animal movement, unexpected contact, accessible cables, noise, cleaning, ammonia/corrosion exposure and operator intervention. A single planar LiDAR can miss hazards outside its scan plane, so its presence alone does not establish safe operation around animals. Agree the additional sensors, protective construction, operating separation and supervision with the site owner and responsible supervisor before such tests.

The first prototype acceptance should be in dry, controlled conditions; night, rain and direct-sunlight performance are separate capabilities to evaluate. Verify the selected LiDAR’s operating conditions and test lighting, reflective surfaces and contamination effects rather than assuming all LiDAR works equally outdoors. IP54 and the brochure temperature range are reference claims without supporting test evidence in the supplied package. Document enclosure and connector design targets, but do not claim an IP rating or allow wet-weather operation until the completed assembly has been assessed and validated.

Intercropping places different crops or crop/cover vegetation in a managed spatial arrangement, creating a need to navigate accurately between planted strips. FieldScout can support that work as a small mobile sensing and research platform; presentation slide 9 also describes a future cooperative mowing trial. For this assignment, interpret that context as a reason to design reliable navigation interfaces and adjustable corridor/clearance parameters. Mowing tools, crop-treatment efficacy and multi-robot coordination are separate tasks and are not necessary to demonstrate LiDAR navigation.

The 650 × 480 × 420 mm, approximately 22 kg, 1.5 m/s, up to 8 h, IP54 and −10 °C to +50 °C figures are brochure-reported references, not a supplied set of measured acceptance results. The original website explicitly notes missing IP test evidence and a different CAD assembly envelope, while the Lua script uses a 26 kg nominal model and its own wheel/track geometry. Measure and record the delivered robot’s dimensions, mass, wheel radius and footprint before setting navigation parameters. For the student prototype, approve a conservative indoor operating envelope and demonstrate it; reproducing every brochure figure is outside the narrowed scope.

For the first supervised indoor demonstration, propose a three-waypoint course repeated ten times: goal position error at most 0.20 m and heading error at most 15 degrees, at least nine complete runs without intervention, and zero contacts in all ten runs. These are initial acceptance targets for company and supervisor agreement, not measured FieldScout capability. Measure pose error against independent reference marks rather than the estimator’s own reported position. Row tracking and clearance requirements must be derived from the measured footprint, crop/aisle spacing, localisation uncertainty and stopping distance before agricultural trials.

A rated payload capacity and permissible centre-of-gravity envelope are not supplied. The BOM must include the mass and position of the computer, LiDAR, mounts, wiring and optional sensors, followed by stability, mounting and power checks on the actual robot. A removable sensor plate with labelled connectors is a practical modularity target for this assignment. Agree a payload limit after the base platform is weighed and evaluated; do not infer vehicle payload from an individual wheel or motor load rating.

No verified maximum slope, step height or traversable obstacle size is documented for the complete robot. Start with a level floor and treat obstacles as objects to avoid, not climb over. If terrain testing is added, measure traction, tipping margin, underside clearance, current demand and stopping behaviour under a controlled procedure. Publish only the conditions actually tested and keep unsupported brochure or component limits out of the acceptance specification.

Define a test obstacle set with dimensions, material, reflectivity and height relative to the LiDAR scan plane, including a person-sized surrogate and smaller representative objects. Compute an initial stopping envelope from measured sensing/processing/communication latency, speed, braking behaviour and a margin; v × latency + v²/(2a) is only a planning approximation and must be checked experimentally. Select the maximum trial speed and detection threshold from those results rather than promising an unsupported stopping distance. Low, overhead, transparent or poorly reflecting hazards may need additional sensing, since a 2D LiDAR cannot guarantee all-object detection.

The supplied brochure reference says up to eight hours depending on terrain and payload, without a documented duty cycle or measured energy log. Therefore it cannot be interpreted as guaranteed continuous driving. Define a mission profile including drive, turning, stationary sensing, compute and standby time, then measure battery energy and subsystem consumption over that profile. Report runtime with payload, route, battery state and environmental conditions, and use it to estimate a reserve-aware mission duration.

No approved noise limit, manual-carry mass or car-transport envelope is supplied. Weigh and measure the complete configured prototype, record noise under a stated test method and identify secure lifting/transport points. Agree handling arrangements with the supervisor rather than assuming the brochure’s approximate 22 kg is the actual transport mass. For student use, plan powered-off transport with the battery and payload secured and protect the LiDAR from impacts.

The sources do not contain a company-approved ranking of unsatisfactory chassis/body parts. Inspect the actual unit with the company engineer and document mount stiffness, access to the battery and stop controls, connector strain relief, wheel clearance, fastener retention and enclosure cooling. Prioritise changes that directly enable reliable LiDAR navigation and serviceability. Avoid replacing the whole chassis before measuring whether a simpler bracket or removable plate resolves the integration need.

For the navigation project, define modularity as a removable computer/sensor assembly, replaceable labelled cables and accessible drive/power connections with repeatable mounting references. Record mechanical interfaces, connector pinouts, power requirements and software drivers for each module. Battery hot swapping and tool-free drive-module replacement introduce additional requirements and are not implied by the word modular. Choose only the modular interfaces that can be demonstrated and documented within the project.

The Lua reference identifies ZLLG40ASM100 V1.0 wheel motors with 0.107 m wheel diameter, 24 V and 100 W values; these are source-script parameters that must be checked against the delivered hardware labels. The Sep10 sketch controls two dual-channel drivers and preserves an explicit four-wheel polarity mapping. No complete suspension or gearbox specification is supplied, and the assembled model dimensions differ from the brochure. Retain the existing drive hardware for this assignment and record the actual part numbers and dimensions in the as-built BOM.

Prioritise replacement of the LiDAR, computer storage, sensor/USB cables, approved fuses and removable sensor mount by a trained technician with power isolated. Make connector labels, access directions, tools and post-replacement checks explicit in the service guide. Drive-module or battery replacement should follow a company-approved procedure and include polarity, fastening and functional checks. Students should demonstrate the service steps they design, without implying hot-swapping capability.

Place the LiDAR on a rigid, level mount with a clear scan plane and document its transform to the robot base frame, blind sectors and nearby body reflections. Choose its height from the target obstacle set; mounting higher is not automatically safer because low hazards can disappear below the scan plane. If fitted, keep a GNSS antenna clear of obstructions, select camera height/view from the task, and mount environmental sensors where airflow and heat from the robot do not bias measurements. Measure all extrinsics and retain access to connectors, cleaning and calibration references.

For the dry indoor prototype, select materials and fasteners that keep sensor alignment stable and tolerate normal handling. Any future barn or outdoor version needs component-specific assessment of UV exposure, ammonia, cleaning agents, moisture, corrosion and temperature. Record material grades, enclosure/connector ratings and the permitted cleaning method; a printed polymer or a nominally sealed sensor does not establish the whole assembly’s resistance. Chemical and wet-cleaning tests remain outside the initial navigation acceptance unless explicitly added.

The verified drive-control chain in the Sep10 sketch is ESP32 HardwareSerial(1) to an RS485 interface at 115200 baud, 8N1, RX GPIO18/TX GPIO17, then driver IDs 1 and 2 controlling four wheels. The target architecture adds a Jetson computer and LiDAR upstream of the ESP32 and supplies them through appropriately rated, protected power conversion. Presentation slide 4 is a functional block diagram, not a complete as-built schematic. Students must draw both signal and power paths, identify the actual transceiver/board and document battery, fuses, connectors, grounding, regulator ratings and the physical stop circuit.

The latest company brief supersedes the earlier project-document line requesting newly designed motor drivers/controller hardware: use the existing ESP32, motor drivers and wheel-control implementation. The student electronics task is to integrate the navigation computer and sensors, design their power distribution and interfaces, and verify the complete command path. A custom navigation carrier or power/interface PCB can be proposed if justified, but new motor drivers are not a default deliverable. Agree any change to the low-level drive electronics before implementation.

The supplied files do not establish the actual battery chemistry, nominal/max/min voltage, capacity, BMS thresholds or charger model. Although the Lua script lists 24 V motor data, that does not verify the installed battery or power-board input range. Inspect labels and wiring with the company and record the battery, charger, BMS and protection arrangement before selecting regulators. Keep the existing battery for the initial integration if suitable; any redesign must be justified by a measured power budget and approved compatibility checks.

Solar charging is not part of the current LiDAR navigation request and should remain outside the core scope. Concentrate on reliable power delivery to the computer, LiDAR, ESP32 and existing drives, together with measured energy use and shutdown behaviour. A future solar option can be recorded as a concept with its mass and energy trade-offs, without adding hardware to the student critical path.

Use supervised manual charging with the company-approved charger as the initial operating concept, once the battery and charge requirements have been identified. Define how motion is disabled during charging and how the operator checks battery readiness before a mission. A removable battery may be considered for serviceability, but hot swapping and autonomous docking are separate extensions. The attachments do not confirm an existing dock or a validated battery-swap procedure.

No measured subsystem power budget is included. Build a BOM-linked budget with each rail’s voltage, idle/typical/peak current, converter efficiency, inrush allowance and fuse/wire requirements, then measure it under straight driving, pivoting and computer load. Keep motor startup/stall-related demand distinct from the computer and LiDAR supply so transients and brownouts can be diagnosed. Estimate runtime from measured usable battery energy and mission-average power, then validate the estimate with a timed trial.

The physical stop function must not depend on browser, Wi-Fi, USB or a successful Modbus transaction; the supervisor/company must confirm the actual motor-energy isolation arrangement. Add appropriately selected fusing and wiring, accessible stop controls, monitored battery/thermal conditions, explicit mode and motion-enable state and a stale-command stop policy to the integration design. Test loss of host commands, loss of driver communication, reboot and low-battery behaviour with the robot supported before floor tests, and require deliberate restart after faults. The supplied demo’s software ESTOP sends zero and disable commands over the same RS485 link and therefore cannot alone prove a stop if that link fails.

No exclusive supplier list or company purchasing prohibition is supplied. Select parts from documented suppliers with usable datasheets, stable model identifiers, compatible software drivers, known electrical interfaces and suitable mounting/power requirements. Compare at least two viable LiDAR/computer integration options and record stock, quotations, tax/shipping assumptions and alternatives in the BOM. Confirm the exact Jetson model and the available company inventory before ordering; original Nano and Orin Nano are different platforms.

The target architecture names LiDAR, RTK-GNSS, IMU, RGB and environmental sensors, but does not establish a complete installed inventory or exact sensor models. LiDAR and the navigation computer/interface are core to the revised assignment; identify available IMU and wheel feedback and select compatible units as needed. Treat GNSS, camera and CO2/NH3/T/RH/light/noise sensing as optional supporting or future modules unless the agreed mission requires them. The first BOM must separate supplied, verified-on-robot, to-purchase and optional items and include interfaces, drivers, power and mounting details.

No RTK base station, correction-service account or NTRIP access is evidenced in the supplied material. GNSS corrections are not required for the first indoor LiDAR mapping/localisation demonstration. If outdoor georeferencing is added, confirm receiver compatibility, correction source, coverage, communications, licence/access conditions and an independent accuracy-check method. Keep that procurement and validation as an explicit extension rather than a hidden dependency.

Use a LiDAR map and indoor localisation pipeline on the Jetson, with measured wheel odometry and an IMU where available, to estimate robot pose without GNSS. Establish the map→odom→base_link→laser frame chain and timestamps, map the test area under supervision, then localise against the saved map and navigate to waypoints. LiDAR obstacle detection by itself does not supply a stable global pose, and commanded RPM is not a substitute for measured odometry. Validate localisation in repetitive aisles and around reflective/transparent surfaces and stop or request intervention when localisation becomes unreliable.

Use a local wired link, preferably the agreed USB serial interface, between Jetson and ESP32; let the ESP32 remain the sole Modbus RTU master on the motor-driver bus. Wi-Fi can support local dashboard access, development and data transfer, while LoRaWAN suits small low-rate sensor/status reports rather than video or the navigation control loop. Cellular service is an optional remote monitoring/backhaul extension. Define coverage from the test site and measure it; autonomous stopping and local control must not rely on uninterrupted cloud or wide-area connectivity.

The supplied FieldScout architecture primarily describes sensors carried on the robot and measurements recorded with position and time. Stationary wireless sensors may complement this system, but no required stationary-node integration is defined for the LiDAR navigation assignment. If both are included, distinguish their sensor IDs, physical locations, timestamps and calibration records so mobile and fixed measurements are not confused. A single optional onboard sensing example is sufficient to demonstrate the data interface without expanding the navigation scope.

Yes: include LiDAR range/scan checks, mounting-transform verification, IMU orientation/bias checks and wheel-odometry calibration under the intended floor conditions. Validate timestamps, missing scans, implausible measurements and localisation quality and record what causes a pause or stop. Environmental sensors need their own calibration/reference procedure, warm-up and response-time documentation if they are used. Store calibration date, method and configuration with the test logs so results remain reproducible.

The company references reviewed for this guide include the original website/3D model, a standalone motor demonstration, a serial heartbeat test and the Lua CoppeliaSim controller. Neither reviewed ESP32 sketch implements the matching HELLO/CMD receiver, and no complete physical Jetson navigation implementation was supplied for review. This student edition adds the browser drive lab, synthetic LiDAR, A* planning and online obstacle detours, while keeping raw firmware outside the distribution. Request the installed firmware revision, approved receiver source and repository access from the company as an explicit integration task. The browser lab does not establish that the physical robot accepts its generated messages.

ROS 2 with a LiDAR driver, mapping/localisation, transform handling and a navigation stack is the proposed high-level approach; it is not shown as an existing deployed stack in the attachments. Use Python and/or C++ for the Jetson integration and Arduino/C++ for the ESP32 as appropriate to the chosen packages and team skills. Confirm the exact compute board first: the project PDF and slides specify Orin Nano, whereas the current brief says Jetson Nano, and these names must not be treated as interchangeable. Select and document a compatible JetPack/OS/ROS release combination from official support information before freezing the BOM; demonstrate performance on the actual board.

The original website is a working presentation and interactive 3D model, now accessible in the 3D explorer on the start page. The student Drive Lab also simulates manual movement, waypoint missions and LiDAR-triggered A* detours around added obstacles, with the resulting commands visible. It uses an ideal pose and simulated geometry and has no physical telemetry or motor-control connection. The eventual physical dashboard should show mode/readiness, pose/map, data freshness, faults, mission state and stop controls, with measured and simulated values clearly distinguished.

Prioritise mode/readiness, map and waypoint status, LiDAR, wheel commands, available measured feedback, data freshness, faults and downloadable logs. The student browser lab lets you add an obstacle, observe the planned detour or blocked-route stop and inspect the resulting command stream. These are simulation features; physical telemetry and autonomy require the student hardware integration and validation. Video, environmental heatmaps, historical analytics and user accounts remain optional unless needed by the agreed workflow.

Run navigation and essential logging on the onboard computer, with local storage and export to the team’s agreed repository or workstation. The existing website is static and the supplied materials do not define a working robot backend or an authenticated control API. A hosted JSON mechanism is a later phase requested separately by the company; downloaded simulation examples are not a deployed command service. Before adding remote control, design command ownership, authentication, sequence/freshness checks, acknowledgements and a local stale-command stop so an old web file cannot sustain motion.

Use a documented structured format for commands/status, CSV for human-readable time-series summaries and a robot-native recording format for LiDAR, transforms and sensor streams when using ROS. Include schema version, units, coordinate frame, timestamps, source/session identity, sequence and validity information where relevant. The Lua reference transmits newline-terminated ASCII CMD,FL,FR,RL,RR in rad/s; the driver bus uses binary Modbus RTU signed RPM values, so neither is inherently JSON. Use GeoJSON only for genuinely georeferenced coordinates and document any conversion from the local map frame.

Use an ordered waypoint mission in one documented map frame, with an explicit start, stop and deliberate resume after a blocked route. In Drive Lab, select Start example mission, then Add obstacle ahead and observe a new A* detour toward the same goal; if no route exists, the model stops with movement disabled. For the physical system, establish reliable localisation, a measured footprint and validated obstacle clearance before running the same kind of mission. Save the mission with its map and configuration identifiers so the test can be repeated. Drawn paths, crop-row selection and automatic coverage grids can follow reliable point-to-point navigation.

Prepare clean interfaces for optional image capture and timestamp/pose association, but do not make AI model development or extensive labelling a core navigation deliverable. If representative images can be collected without delaying integration, record camera settings, calibration, location and any permissions or restrictions associated with the data. Store raw data separately from derived labels and document how future datasets could be added. The presentation explicitly describes AI-based crop monitoring as a development path rather than an existing capability.

The materials describe a modular agricultural monitoring platform but do not confirm a chosen commercial model. Compare robot/system sales, leasing and monitoring services against the initial researcher/R&D-user workflow, including integration, support and maintenance effort. A practical student output is a transparent comparison of who pays, what is delivered, recurring costs and the evidence needed to choose. Present conclusions as business hypotheses pending company/customer validation.

No approved sales price, manufacturing-cost target or student purchasing ceiling is supplied. Build the BOM from actual quotations and distinguish one-off prototype expenditure from recurring unit cost, assembly/testing, warranty/support and overhead assumptions. Ask the company for a budget ceiling and any target margin before recommending purchases or pricing. A parts total alone is not a defensible selling price or production cost.

Create a current comparison of small research mobile bases, agricultural scouting platforms and manual/static-sensor alternatives for the selected use case. Use the same metrics: supported environment, payload/modularity, navigation evidence, integration effort, support, total cost and data access. FieldScout’s intended differentiation is adaptability and modular agricultural sensing, but the sources do not prove a cost or autonomy advantage over competitors. Verify each competitor claim from current primary material and distinguish advertised capability from independent or student-measured evidence.

No named paying customer, committed pilot user or letter of interest is included in the supplied materials. Ask the company what contacts or evidence may be shared with the student team and under what confidentiality conditions. Interviews arranged by the students can test needs and willingness to pilot, but must not be represented as confirmed sales. Record the evidence level behind each market claim.

The presentation supports an initial R&D/environmental-monitoring user segment, but it does not commit to a first sales region. For the student study, choose a reachable interview/pilot segment such as local research or greenhouse users and justify that choice through access, problem fit and support requirements. Compare expansion to livestock or open-field monitoring only after the first use case is clear. The company must confirm any commercial launch geography or channel commitments.

Produce a focused business case containing the chosen user problem, interview evidence, alternatives/competitors, a bottom-up cost model, pricing hypotheses, service/support assumptions and a staged route to pilots. Estimate market opportunity transparently using a defined customer segment rather than an unsupported global market headline. Include risks, validation gaps and the additional work needed before commercial deployment. Funding options may be discussed at a high level, but the technical integration and evidence-backed demonstration remain the central revised project outcome.

No certification file, completed conformity assessment or approved regulatory applicability list is supplied. The student handover should include a register for review of machinery, radio, electromagnetic compatibility, electrical/battery safety and relevant mobile/agricultural robot requirements, selected by the responsible company/supervisor for the intended application and placing-on-market date. Record hazards, design measures, component declarations and test evidence, and identify where specialist assessment is still needed. This educational prototype package does not certify CE conformity, IP54 or safe unsupervised deployment; legal applicability must be checked against current official requirements.

The project evidence places FieldScout at a physical-prototype and system-integration stage, with autonomous operation and representative validation still to be completed. Company size, staffing, funding and commercial release dates are not established by the attachments and should be requested directly if needed for the business case. This student project can reduce a concrete integration risk by delivering a documented LiDAR-to-drive demonstration and measured limitations. It should not promise a commercially ready robot or a company launch schedule.

The project PDF lists ESP32 boards as available and IMU/environmental sensors plus battery/power items as mostly available, but it gives no itemised quantities, revisions or dispatch dates. Ask the company for an inventory table with model, quantity, condition, accessories, firmware/calibration status, owner and delivery plan. Inspect each received item before treating it as available in the final BOM. Separate current verified hardware from expected loans and purchases so missing parts have clear alternatives.

The source document anticipates access to CAD, 3D printing, workshop and electronics facilities, but does not guarantee company manufacturing capacity or turnaround. Prepare drawings and manufacturing files only for the mounts, enclosures or interface boards justified by the scoped architecture, then request quotations and lead times from the agreed facility. Assign procurement/manufacturing ownership and approval limits before ordering. Include a workable off-the-shelf or simple fabricated fallback for items on the critical path.

A company contact is identified through Adaptive AgroTech, but named discipline leads and guaranteed support availability are not supplied. Agree a primary technical contact, supervisor escalation route and a written question/decision log at kickoff. Send minimal reproducible examples with firmware revision, wiring details and logs to make remote support effective. Allocate student owners for mechanics, power and software so cross-subsystem questions are consolidated rather than duplicated.

Proposed handover for the stated 23 December milestone is a demonstrated LiDAR navigation prototype plus its BOM, signal/power architecture, as-built wiring and mounting files, versioned host/ESP32 source, configuration, operator guide and measured test report. Include the revised dashboard/simulation package, command-interface specification, reproducible logs and a clear list of unvalidated capabilities. Add a concise business case to the level required by the EXT assessment. PCB fabrication files are required only if a new board is actually designed; the latest brief does not require replacement motor drivers.

Base the problem formulation on the current company brief: add LiDAR navigation to the existing ESP32-controlled four-wheel platform. Use this guide, the 3D geometry, simulator and documented controller interface for initial planning, and obtain the actual source code and hardware documents through the company handover. Keep battery details, physical dimensions, receiver firmware and hardware delivery as explicit dependencies rather than assumed facts. Maintain an assumptions/decision register and agree a review point when missing material arrives. The company and supervisor should approve scope changes, with simulation and interface milestones available if physical access is delayed.

Yes, a company review of the technical scope and interfaces is recommended before the work phase so students do not design against obsolete hardware assumptions. The supervisor retains academic approval responsibility, and the company should confirm the retained drive system, intended use, inventory and proposed acceptance criteria. Record the agreed baseline and unresolved items in writing. No existing contractual approval process is evidenced in the attachments, so establish this workflow at kickoff.

Use gated milestones in this order: BOM and inventory review; signal/power block-diagram and interface review; hardware/software compatibility freeze; supported-wheel command and fault tests; first supervised drive; mapping/localisation; waypoint and obstacle trials; repeated acceptance runs; final handover. Each gate should have a small demonstrable output and a named owner, with dates set against delivery lead times and the academic calendar. Freeze the core feature set early enough to leave time for repeatability and fault testing. These are proposed project gates, not company-confirmed meeting dates.

Judge success by repeatable completion of the agreed indoor mission, correct wheel-command translation, reliable stop/fault handling, and evidence that the selected hardware and power architecture work together. Compare measured arrival/tracking error, clearance, mission completion, command age, controller faults and energy use against approved test conditions. Include failed runs and limitations, and demonstrate that another team member can reproduce the setup from the documentation. Attractive simulation or a single successful route is insufficient evidence of a reliable physical navigation prototype.

Plan indoor or protected greenhouse-style tests as the critical path so weather and ground conditions do not determine whether the project can be completed. Outdoor autumn/winter trials can be added only when the actual robot, sensors, enclosure and site conditions support them and the responsible supervisor approves the procedure. Record temperature, lighting, surface and precipitation conditions for any such trials. Do not rely on the unvalidated brochure environmental figures to justify wet or freezing operation.

Provide a versioned, self-contained handover with README/setup instructions, an as-built BOM, editable diagrams/CAD, PDF drawings, wiring and connector tables, source/configuration files, licence notices and a reproducible release identifier. Document message grammar, units, wheel mapping, register use, timeouts, state transitions and fault responses, separating implemented behaviour from future proposals. Include test plans, raw logs, results, known issues, calibration records, operator/shutdown procedures and a dependency/inventory manifest. Another student should be able to install the software, reproduce a simulation and identify the remaining hardware commissioning steps without oral instructions.