PaperlayerView exact revision on arXiv

Source-linked AI summary

ALFRED: Requirement-driven development of an open-source mobile manipulator for long-term plant monitoring

Ciarán Miceal Johnson, Christopher Quail, Garry Ellard, Alistair McConnell, Steve Tonneau, Fernando Auat Cheein

arXiv:2610.01477v1cs.ROcs.ARcs.CV

TL;DR

Repeated plant monitoring needs close-range observations, but long-term field platforms are rarely released with design files and successive builds are seldom compared for reach and visibility. This paper presents ALFRED, developed through four requirements-driven builds and model-based comparisons. Usable arm workspace improved across builds, and the platform completed a year of monthly forest surveys without a missed collection.

  • Problem

    Long-term field platforms are rarely released with design files, and successive agricultural robot builds are seldom compared for reach and visibility as development tools.

    Source: §1 · p. 4

  • Method

    The authors developed an open-source mobile manipulator through four builds against six requirements and used robot-description models to compare reachability and visibility.

    Source: §1 · p. 5, §2.3 · p. 7

  • Results

    Usable reachable workspace rose from 34.0% to 60.0% to 66.1%, and ALFRED completed 528 traversals over 29 days without missing a scheduled collection.

    Source: §11 · p. 26, §12 · p. 28

  • Takeaways & Limitations

    Robot-description-based analysis lets design changes in reach and visibility be quantified before manufacture.

    Source: §12 · p. 29

    Mechanical modularity depends on keeping robot descriptions and payload configuration synchronized; a mismatched description can make a running robot behave incorrectly and dangerously.

    Source: §8.1 · p. 19

Abstract

from arXiv · show

Tracking seasonal change in crops and forests requires observing the same plants repeatedly. Ground robots can do this at close range, and a manipulator gives their sensors more viewpoints. Yet the robots behind long-term field datasets are rarely released with their design files, and how a robot's own structure limits arm reach and occludes its sensors is seldom compared between builds. We present ALFRED, an open-source mobile manipulator built from commercially available components. It carries a six-degree-of-freedom arm, LiDAR, RGB-D cameras, RTK GNSS and an IMU on an Ackermann-steered base, all mounted on a reconfigurable aluminium strut frame, and runs containerised ROS software. It was developed through four builds against six requirements for repeated outdoor deployment: durability, modularity, repairability, sensing reach, endurance and reproducibility. Model-based analysis of the last three builds shows the usable share of the arm's reachable poses rising from 34.0% to 60.0% and then 66.1%, and ray casting shows that only the final build keeps the frame-mounted LiDAR's horizontal view clear both forwards and backwards. ALFRED completed a year of monthly forest surveys (528 traversals) without missing a scheduled collection. This was despite battery degradation, reconfiguration for another researcher's study, and the parallel development of ALFRED 2.0 for autonomous crop-row operation, with each switch between builds taking about six hours. The deployment also showed that mechanical modularity is only as dependable as the robot description that tracks it.

Highlights

ALFRED was developed through four builds against six requirements, with measurable gains in arm workspace and LiDAR visibility and a year of forest surveys without a missed collection. The project also releases its design files, robot descriptions and software.

Highlights

1. Introduction

Repeated crop monitoring benefits from close-range, non-destructive sensing, but long-term deployment and prototype development are seldom assessed together. This paper presents ALFRED, developed through four builds against six requirements, and compares build-level reachability and visibility alongside field deployment.

1. Introduction

  • Non-destructive measurement allows the same plants to be observed repeatedly, unlike manual destructive sampling that can damage plants and alter neighboring growth.Source: §1 · p. 4
  • Ground robots sense plants at close range, while manipulators position cameras at useful viewpoints and interchangeable end effectors support different tasks.Source: §1 · p. 4
  • Long-term field robots must accommodate changing sensing tasks and repair needs, yet successive prototype improvements are rarely compared during sustained deployment.Source: §1 · p. 4
  • ALFRED is a commercially assembled mobile manipulator developed through four builds against six requirements; forestry tested annual monitoring, while ALFRED 2.0 used artificial plants for crop-row operation.Source: §1 · p. 5
  • The work documents requirement-traced builds and compares arm workspace and frame-mounted LiDAR visibility across the last three builds.Source: §1 · p. 5

2. Background

The background links crop-model observation needs to the constraints of repeated field sensing, then frames reachability and visibility as coupled design measures for mobile manipulators. It introduces ALFRED and its forest and crop-row deployments as the platform context.

2.1. Data assimilation into crop models

  • Phenological windows can be only days wide and their dates uncertain, motivating dense ground-robot sampling with close-range viewpoints unavailable from platforms above crops.Source: §2.1 · p. 6

2.2. Mobile manipulators for long-term crop sensing

  • No reported in-field campaign monitored the same plants across a full growing season with a mobile manipulator, and prior work rarely reports design requirements or rebuild information.Source: §2.2 · pp. 6–7

2.3. Reachability and visibility as design tools

  • Coverage combines arm reachability and vehicle-sensor visibility; posture-dependent arm occlusion couples them, motivating model-based comparison of successive builds before manufacture.Source: §2.3 · p. 7

3. The ALFRED robots

  • ALFRED’s modularity supports sharing across researchers and changing sensor-placement needs as plants grow.Source: §3 · p. 7
  • ALFRED collected monthly ForestYear3D surveys, while ALFRED 2.0 supported ROWCAST’s scout-plan-execute-phenotype workflow for crop rows.ForestYear3D point clouds show added arm-mounted LiDAR viewpoints and seasonal forest change.Source: §3 · p. 9

4. System Design

ALFRED and ALFRED 2.0 share a commercial mobile base, six-joint arm and rugged laptop, with sensors and independently powered electronics mounted on configurable frames. Their containerised ROS software supports distinct forest-survey and crop-row configurations.

4. System Design

  • Both builds combine an Ackermann-steered Hunter 2.0 base, a six-joint Z1 arm and a rugged laptop, with two batteries powering separate electronics enclosures.Each enclosure has a 48 V 30 A h battery and steps down power for its loads.Source: §4 · pp. 10–11, Figure 5 · p. 11

4.1. Software

  • ROS Noetic runs in layered Docker images, while Gazebo, RViz and MeshCat support physics testing, monitoring and rapid kinematic checks.The base image holds core configuration, drivers and dependencies; application images add planning and behaviour components.Source: §4.1 · pp. 11–12

4.2. ALFRED: ForestYear3D configuration

  • ForestYear3D recorded both LiDARs and IMUs in ROS bags during semi-autonomous traversals, with an operator steering the base and the arm sweeping fixed joint configurations.The GNSS receiver was carried but not used because RTK had not been commissioned before a full annual cycle could begin.Source: §4.2 · p. 12

4.3. ALFRED 2.0: ROWCAST configuration

  • ALFRED 2.0 adds computing, networking and sensing for crop rows, using RGB-D cameras and autonomous base navigation while arm trajectories remain planned offline.Its second laptop was added for camera ports, online planning and GPU perception, but only the port constraint was realized; Wi-Fi also carries RTK corrections.Source: §4.3 · pp. 12–13, Figure 6 · p. 13, Figure 7 · p. 14

5. Design requirements

The platform was developed against six requirements for repeated outdoor deployment, from durability and repairability to sensing capability and reproducibility.

5. Design requirements

  • R1 requires unsheltered operation across a full annual cycle, tolerating weather, site conditions and obstacles such as leaves, stones and roots.The platform should also survive unforecast light rain or gusts during a session.Source: §5 · p. 14
  • R2 requires sensors, computers and other hardware to be relocatable or replaceable without major redesign as sensing needs change or researchers share the platform..Source: §5 · p. 14
  • R3 requires failures to be repairable in-house between scheduled deployments using commercial components or parts made with available workshop equipment.Source: §5 · p. 14
  • R4 requires the manipulator to place sensors at poses unavailable to rigid mounts while preserving sufficient base-mounted field of view for each task.Source: §5 · p. 14
  • R5 requires completing a scheduled data-collection session without battery capacity becoming the limiting factor.Source: §5 · p. 14
  • R6 requires rebuildable bespoke parts with released design files, priced commercial components and software portable across machines.Source: §5 · p. 14

6. Platform development

Four builds were assessed against the six design requirements, with each prototype treated as unfinished and open to further optimization and validation.

6. Platform development

  • All four builds are presented as prototypes rather than finished products because components could be further optimized and validated.Source: §6 · p. 15, Figure 8 · p. 15

6.1. Prototype overview

  • Prototype 0 tested component integration and manufacturing skills; Prototype 1 assembled the main subsystems but was never field-deployed after testing exposed a requirement failure.From then on, builds were modelled in CAD and tested in simulation before construction.Source: §6.1 · p. 15
  • ALFRED first met every requirement at least partially and entered field experiments using a modular aluminium-strut frame, while ALFRED 2.0 added hardware for autonomous crop-row monitoring.Source: §6.1 · p. 15, Figure 9 · p. 16

7. R1: Outdoor durability

The first complete assembly’s printed electronics cage failed the outdoor-durability requirement; the later aluminium-strut frame was sufficient for the reported work.

7. R1: Outdoor durability

  • Prototype 1’s low-infill PLA electronics cage broke during assembly, and remaining parts were judged likely to fail in the field.Source: §7 · p. 16
  • ALFRED replaced the cage with aluminium profile struts and angle brackets, and no structural frame element failed over two years.Source: §7 · p. 16
  • The authors caution that this history does not prove durability, though the frame was sufficient for the work performed and was reused for ALFRED 2.0’s second layer.Source: §7 · p. 16

8. R2: Modularity and reconfigurability

ALFRED’s shared interfaces and reconfigurable frame supported changes to hardware and payloads during the ForestYear3D campaign without missed scheduled collections. The campaign also showed that reliable modularity depends on keeping the software model aligned with the robot’s mechanical configuration.

8. R2: Modularity and reconfigurability

  • A common 3D-printed end-effector interface let new payloads use their own housings instead of requiring the whole assembly to be redesigned.The shared interface persisted to the final design; shared software interfaces also kept the codebase smaller and easier to maintain.Source: §8 · p. 16, Figure 10 · p. 17
  • The final aluminium strut frame extended mounting space, while hinged enclosure doors enabled field access and ALFRED 2.0 added a second hardware layer.These changes addressed Prototype 1’s constrained mounting and field access.Source: §8 · pp. 16–17, Figure 11 · p. 17

8.1. Reconfiguration during the ForestYear3D campaign

  • During a year of monthly surveys, ALFRED was reconfigured for another study and ALFRED 2.0 development without missing a scheduled collection.Each transition between the builds took about six hours; the payload-study reconfiguration took about half a day in each direction.Source: §8.1 · pp. 17, 19
  • Ventilation openings were added to fixed and end-effector RGB-D mounts after restricted airflow caused camera overheating during extended operation.The thermal improvement was not quantified, but the fault did not recur and was addressed before ROWCAST.Source: §8.1 · p. 17, Figure 13 · p. 18
  • Mechanical changes alone do not ensure modularity: each build and optional payload configuration requires its matching robot description and controller settings.Launching with the wrong description can produce incorrect and potentially dangerous behavior.Source: §8.1 · p. 19

9. R3: Repairability

Across the later builds, model-based analyses compare LiDAR visibility and arm reach, while field experience assesses repairability, endurance, and reproducibility. The results distinguish builds suited to different sensing tasks and document practical constraints on maintenance and operation.

9. R3: Repairability

  • Stock struts and laser-cut panels let damaged parts be replaced in minutes rather than a working day of printing, and both field builds were repaired without disrupting schedules.During ForestYear3D, a damaged end-effector mount was replaced the following day without affecting data collection.Source: §9 · p. 19

10. R4: Sensing reach and coverage

  • The visibility and reachability comparisons use robot models under shared assumptions, but omitted cable routing and small fasteners make their collision models slightly optimistic.LiDAR visibility was ray-cast against posed visual meshes; workspace tests used each build’s collision model.Source: §10 · p. 20, §10.1 · p. 21, §10.2 · p. 24

10.1. Fixed-sensor visibility

  • For ROWCAST, only ALFRED 2.0’s horizontal LiDAR beam reaches the 5 m cap both forward and rearward; ALFRED in drive posture has the widest transverse aperture for ForestYear3D.The corresponding ALFRED 2.0 clear apertures are 56.60° forward and 22.50° rearward; ALFRED’s are 160.31° left and 159.96° right.Source: §10.1 · p. 21, Table 2 · p. 23

10.2. Manipulator workspace

  • Usable poses rose from 34.0% on Prototype 1 to 60.0% on ALFRED and 66.1% on ALFRED 2.0, among poses where inverse kinematics converged.Collision rejections fell from 50.8% to 17.6% and 13.3%, respectively; Table 3 reports usable workspace as percentages of reachable poses.Source: Table 3 · p. 24, §10.2 · p. 25

10.3. R5: Endurance

  • After one battery degraded, a survey window that had taken a day required three; replacement equipment restored endurance part-way through the campaign.Each charge lasted about 30 minutes, or roughly five of the 33 traversals in a complete survey window.Source: §10.3 · p. 26

10.4. R6: Reproducibility by others

  • The release provides ALFRED and ALFRED 2.0’s CAD, robot descriptions, collision configurations, operating code, assembly manual, and component costs; Prototype 1 lacks operating code.The software is packaged in Docker containers.Source: §10.4 · p. 26

11. Discussion, Limitations and Research Opportunities

ALFRED met its requirements in a year of monthly forest surveys, while model-based comparisons quantified design gains across builds. The discussion identifies hardware limits, integration work, and challenges in the planned online crop-row system.

11. Discussion, Limitations and Research Opportunities

  • The robot completed 528 traversals across 29 days without a missed monthly collection; workspace usability rose from 34.0% to 60.0% and then 66.1%.Collision pairs fell from 128 to 84, and only the final build kept the frame-mounted LiDAR view clear in both travel directions.Source: §11 · p. 26

11.1. Hardware

  • The chassis is rated IP22 unless custom ingress protection is purchased, and its manual advises against operation in rain or snow; arm zeroing errors can propagate into sensor measurements.Collection was therefore not attempted in wet conditions.Source: §11.1 · p. 27

11.2. Integration is the hidden cost

  • Integration required modifying third-party code and reconstructing base joint states because the hardware reports only rear-wheel velocity and steering angle.The reconstructed states complete the transform tree, enabling sensor data to be viewed in its correct spatial relationship to the robot.Source: §11.2 · p. 27

11.3. Future Work

  • ALFRED 2.0’s intended next-best-view architecture sampled sensor poses, estimated newly visible space, and checked reachability and collisions to select an informative reachable pose.The approach was intended to adapt sensing trajectories to vegetation observed on each visit.Source: §11.3 · p. 27
  • Whole-body motion planning combined the planar vehicle pose with six arm joints, but planning time could grow substantially, and the MPC struggled at forward-reverse transitions and across scenarios.The search-tree quadratic programme selected base velocity, steering change, and joint velocities subject to steering, joint-position, and joint-velocity limits.Source: §11.3 · p. 28
  • Online collision checking depended on consistent timestamps, transforms, and self-filter geometry; future work would address planner issues and compare the approach with ROWCAST.Inaccuracies could insert parts of the robot into the OctoMap, while larger filtered volumes also removed nearby environmental measurements.Source: §11.3 · p. 28

12. Conclusion

ALFRED completed monthly forest surveys while undergoing reconfiguration and parallel development, with battery replacement restoring endurance mid-campaign. Build iteration improved reach and visibility measures, and the released design materials support reuse and comparison on other platforms.

12. Conclusion

  • A year of monthly forest surveys yielded 528 traversals over 29 days and 4.9 TB of data without a missed collection, despite concurrent reconfiguration and ALFRED 2.0 development.Each build change took about six hours; degraded-battery endurance was restored mid-campaign by replacement.Source: §12 · pp. 28–29
  • Across the last three builds, usable reachable workspace rose from 34.0% to 60.0% and then 66.1%, while collision pairs fell from 128 to 84.Only the final build kept the frame-mounted LiDAR’s horizontal view clear in both travel directions.Source: §12 · p. 29
  • Robot-description analyses quantify reach and visibility effects before manufacture, and released design files, descriptions, drivers, and containers let others repeat comparisons.The authors identify repairability, treating the robot description as part of the hardware configuration, and integration budgeting as priorities for similar platforms.Source: §12 · p. 29

CRediT authorship contribution statement

The statement assigns conceptualization and writing roles across the author team, with investigation and review contributions listed for several authors.

CRediT authorship contribution statement

Loading 2610.01477v1…