G.A. vd. Hoorn
G.A. vd. Hoorn
@ted-miller: could you perhaps check what a useful maximum upper limit for job files could be? I don't have access to anything representative as I don't normally use INFORM.
So technically you're correct. We don't *have* to pre-allocate. However, the `micro_ros_utilities(..)` functions I now use (2bc333f7d2060eb5b3e9da2968e9e0b0f2ed61d8) do pre-allocate, and they will only do that based on the size configured...
Context: #279 (specifically: https://github.com/Yaskawa-Global/motoros2/pull/279#discussion_r1678323164). @ted-miller: turns out I'd already added the possibility to emit warnings about catch-all ranges in the documentation, we just hadn't enabled it during the CI run....
Friendly ping @ted-miller
> Are you sure we want this then? If there are other warnings, would they get smothered by this message? so, yes, I would want this, but perhaps the script...
> Are you making such a change? yeah, I'll add it.
High-level comment (about the proposed approach): the current implementation seems to use a different approach: error reporting uses the result of `Ros_Controller_GetNotReadySubcode()` (based on the result of `Ros_Controller_IsMotionReady()`) if `Ros_MotionControl_StartMotionMode(..)`...
And another (but only slightly related to this PR): seems the new error / pattern matcher in combination with the updated `mpBuilder` doesn't yet capture compiler errors correctly, resulting in...
`Warning: Group 0 - Time difference between endTrajData (...) and startTrajData (...) is 0 or less.`
@ted-miller: would it not make sense to refuse to execute a trajectory which has this problem? We iterate over all trajectory points when processing the incoming goal, and this seems...
`Warning: Group 0 - Time difference between endTrajData (...) and startTrajData (...) is 0 or less.`
Thanks @schornakj. > It probably isn't possible for the robot to actually perform the precise requested motion since the jerk is too high, so maybe the solution is to do...