Skip to content

Conversation

rodja
Copy link
Member

@rodja rodja commented Jun 24, 2025

Motivation

Non-RTK planted rows might bend to much to simply follow them in a straight line. This PR introduces the capability to add waypoints within rows to approximate the shape more closely.

Implementation

This is work in progress. See Progress below.

Progress

  • I chose a meaningful title that completes the sentence: "If applied, this PR will..."
  • I chose meaningful labels (if GitHub allows me to so).
  • The implementation is complete.
    • Implement all navigations based on waypoints #354
    • Split Field class into FieldDescription and ComputedField
    • FieldProvider can add multiple waypoints per row
    • Simplify UX for adding waypoints
    • Navigate from one waypoint to the next
    • Remove rows_to_work_on
    • Cleanup naming of Waypoint / SupportPoint / RowSupportPoint
    • Remove old "Support Point" UI code
    • Resume should verify that we are actually on a row
    • Find a solution for large WORK_X values (see test_advance_when_target_behind_robot)
    • ...
  • Tests with a real hardware have been successful (or are not necessary).
  • Pytests have been added (or are not necessary).
  • Documentation has been added (or is not necessary).

@pascalzauberzeug pascalzauberzeug added this to the 0.10.0 milestone Jun 24, 2025
@pascalzauberzeug pascalzauberzeug added the enhancement New feature or request label Jun 24, 2025
def _should_finish(self) -> bool:
end_pose = Pose(x=self.target.x, y=self.target.y, yaw=self.origin.direction(self.target), time=0)
return end_pose.relative_point(self.robot_locator.pose.point).x > 0
return end_pose.relative_point(self.robot_locator.pose.point).x > -0.0001
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should investigate why this failed for you

robot must follow a row, then user can pause the field navigation and set a waypoint -- also started with new waypoint driving but it's still a total mess
@pascalzauberzeug pascalzauberzeug modified the milestones: 0.10.0, 0.11.0 Jun 25, 2025
@pascalzauberzeug pascalzauberzeug modified the milestones: 0.11.0, 0.12.0 Jul 22, 2025
rodja added a commit that referenced this pull request Aug 1, 2025
### Motivation

When we started to implement
#352 we once again
noticed the limitations of our old navigation style that always just
calculated the next step. We decided to convert our navigations into
path planners, that use the RoSys driver's system of
[PathSegments](https://github.com/zauberzeug/rosys/blob/main/rosys/driving/path_segment.py).

### Implementation

I reimplemented the `Navigation` class as a waypoint navigation that
generates the whole path beforehand. All other navigations extend from
this.
All specialized navigation types just have to implement their own
`generate_path` method.

The implementation is not fully polished yet, but we decided to get this
merged now and fix any occurring issues later. This way other projects
and issues (like #352)
can already profit from these changes.

### Progress

- [x] I chose a meaningful title that completes the sentence: "If
applied, this PR will..."
- [x] I chose meaningful labels (if GitHub allows me to so).
- [x] The implementation is complete.
- [x] Let the `AutomationWatcher` stop the automation, when the robot
was moved when paused
    - [x] Rework implement blocking
    - [x] Wait for zauberzeug/rosys#314
    - [x] FieldNavigation._is_allowed_to_start after path generation
    - [x] Fix strange turns when weeding in a curve
    - [x] Stop at last row
    - [x] Remove debugging code
- [x] Tests with a real hardware have been successful (or are not
necessary).
    - [x] StraightLineNavigation
    - [x] FieldNavigation
    - [x] ImplementDemoNavigation
- [x] Pytests have been added (or are not necessary).
    - [x] Restructure navigation tests
    - [x] Waypoint Navigation tests
    - [x] Fix Field Navigation tests
- [x] Documentation has been added (or is not necessary).

### Known issues
I will create Github issues once it's merged, so I can link code
directly

- If a target plant is on the next segment, but the robot isn't yet due
to the `work_x` offset, the plant will be skipped
- When driving a curved spline, plant locations will change due to
perspective changes. That's why already targeted plants, can already be
behind the robot when the robot arrives on target.
- Advancing a certain distance on a spline returns unprecise t values
(Navigation:L209)

---------

Co-authored-by: Rodja Trappe <rodja@zauberzeug.com>
@rodja rodja removed this from the 0.12.0 milestone Aug 22, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants