Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
N navigation_oru-release
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 5
    • Issues 5
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 3
    • Merge requests 3
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Package Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Martin Magnusson
  • navigation_oru-release
  • Merge requests
  • !34

Merged
Created Sep 17, 2019 by Federico Pecora@fopaContributor

Computetask pull request

  • Overview 1
  • Commits 2
  • Changes 19

Previously: the ComputeTask service set the field "result" in the service response to 1 if the path planning and smoothing were successful. However, according to the srv definition, the constants should be defined as follows:

int32 RESULT_OK=0 int32 RESULT_PATH_PLANNER_SERVICE_FAILED=1 int32 RESULT_PATH_PLANNER_FAILED=2 int32 RESULT_PATH_PLANNER_REPOSITIONING_FAILED=3 int32 RESULT_POLYGONCONSTRAINT_SERVICE_FAILED=4 int32 RESULT_SMOOTHING_SERVICE_FAILED=5 int32 RESULT_SMOOTHING_FAILED=6

I looked into the orunav_vehicle_execution_node.cpp code and found that it only ever res.result to either 0 or 1, never the other values, and that 0 means failure and 1 means success. I also think that positive error codes for failure states could be dangerous if you use C-style condition checking (anything >0 is true), so I have modified the srv to include only:

int32 RESULT_OK = 1 int32 RESULT_FAIL = 0

I have not changed the code anywhere, so if someone uses the int value directly the change should not affect them.

Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Source branch: computetask-pull-request