incoming wave height service

[andermi]

Adds ROS 2 service to check incoming wave height and normal vector (slope of wave) at an array of points.

requires osrf/mbari_wec_utils#53 and hamilton8415/FreeSurfaceHydrodynamics#5

NOTE: had to change the LinearIncidentWave object in ECM to non-pointer... need to get to the bottom of that if we want to keep it as a pointer.

for testing:
send_iwh_req.py.zip

[andermi]

@hamilton8415 I'm adding a stamp to evaluate the height at a specific time, and was wondering if I should make it relative to current time or absolute? I feel like relative to current time would be more useful... e.g. evaluate 10 seconds from now

[andermi]

@hamilton8415 I made it relative for now (easily changed)

[hamilton8415]

Yes, I think that's a reasonable choice.

[hamilton8415]

Only hiccup would be if there's a question of when "now" is, presumably it will return relative to the sim time when the service request is handled, that may be slightly different than the time in user-code, which would be when the last ROS messages were sent out. Small differences though, using absolute time may alleviate that. May, I need to think more...

[andermi]

In the response, I'm having it return the requested relative_time value as well as the simulation time it was computed

[andermi]

So, a user could see when exactly that height is valid using stamp + relative_tine

[andermi]

@hamilton8415
unzip this and use for testing:
send_iwh_req.py.zip

./send_iwh_req.py -x 1 2 3 -y 4 5 6 -t 5.0 --use_buoy_origin

heights:
- relative_time: 5.0
  use_buoy_origin: true
  pose:
    header:
      stamp:
        sec: 1942
        nanosec: 610000000
      frame_id: ''
    pose:
      position:
        x: 1.0
        y: 4.0
        z: 0.4209758150407607
      orientation:
        x: -0.005023644234914708
        y: -0.006724968921953192
        z: -3.378504167932509e-05
        w: 0.9999647677044281
- relative_time: 5.0
  use_buoy_origin: true
  pose:
    header:
      stamp:
        sec: 1942
        nanosec: 610000000
      frame_id: ''
    pose:
      position:
        x: 2.0
        y: 5.0
        z: 0.39561125637893335
      orientation:
        x: -0.005473899615728417
        y: -0.0073276819083833425
        z: -4.01126731328616e-05
        w: 0.9999581690709967
- relative_time: 5.0
  use_buoy_origin: true
  pose:
    header:
      stamp:
        sec: 1942
        nanosec: 610000000
      frame_id: ''
    pose:
      position:
        x: 3.0
        y: 6.0
        z: 0.3735285312008714
      orientation:
        x: -0.003536647965169145
        y: -0.00473442910203527
        z: -1.6744301432939676e-05
        w: 0.9999825383584839
valid: true

$ ./send_iwh_req.py -h
usage: send_iwh_req.py [-h] [-x X [X ...]] [-y Y [Y ...]] [--use_buoy_origin] [-t T]

options:
  -h, --help         show this help message and exit
  -x X [X ...]       one or more x points to evaluate wave height
  -y Y [Y ...]       one or more y points to evaluate wave height
  --use_buoy_origin  points are relative to buoy origin (world otherwise)
  -t T               enter relative time (+/-) in decimal seconds from sim time to compute height

[hamilton8415]

Thanks for the interrogation script. Working nicely. Two items...

• I am still thinking about the relative/absolute time question. Use of this for model-predictive control will involve collecting a number of wave-heights at a series of times into the future (5-20 seconds worth), if the simulation advances while these requests are being made, there will be a small glitch in the even-spacing of the time-reports, if I understand correctly. For programmatic use, it might be best to do this as absolute time so that one really is sure to get what they are asking for.
• Similarly for the position report, it seems to be reporting in whatever coordinate system the request is made in (buoy or world), I'm thinking it might be better to always report the sample position in world coordinates, that's new information rather than parroting back the request, and this then doubles as a way to find out where the buoy is. Might require a little thought to decide where the world origin is in the at-sea case...

Finally, I'm imagining that in an in-the-field case where there are wave-buoy measurement buoys, we'd set those sensors up to provide this same service, so the simulation/field difference is just who is providing the response.

[andermi]

series of times into the future (5-20 seconds worth), if the simulation advances while these requests are being made

I had envisioned a single request for all rather than a series of requests. I could use an array for the relative_time to be 1-to-1 per point so it would be a snapshot and no advancement would happen... I just figured this would be less bookkeeping for the user. Absolute time would require them to still do the math on their end anyways?

For your second item (and setting up coords at-sea), there's a couple ways to do it...

1. all bodies in lat/lon and Vincenty's formula for relative dist/az which could be converted to cartesian
2. all bodies in local cartesian about fixed world lat/lon, so this would just be (1) with the cartesian conversion relative to the fixed world lat/lon rather than between bodies

[hamilton8415]

Ah yes, if an array of times at a single location is possible, that works fine then. I'm on the fence, so let's leave it relative for now.

I think option (2) for the locations, stick to cartessian, with a specified anchor location as the origin, that's certainly easiest in the simulator, and if outside wave-buoys report in lat/lon, then conversion relative to a fixed anchor point might be needed.

[andermi]

I'm on the fence

When in doubt, do both! :-p

updated the python script:
send_iwh_req.py.zip

[andermi]

still working on (2)

[hamilton8415]

Of course I knew you would do both. :)

[andermi]

done with (2)

[hamilton8415]

This is all working pretty nicely for me. I am a bit unsure how to access the absolute versus relative time request I thought you were hinting at. The lastest .py file didn't have an obvious option. Similarly, does that tool multiple location/time requests, and if so what's the syntax.

[andermi]

oh, I can update the tool to do absolute_time... I just hardcoded relative

[andermi]

latest python tool
send_iwh_req.py.zip

you can add multiple points by just making space-separated values after -x, -y, -abs_t/-rel_t

$ ./send_iwh_req.py -h
usage: send_iwh_req.py [-h] [-x X [X ...]] [-y Y [Y ...]] [--use_buoy_origin]
                       [--rel_t REL_T [REL_T ...]] [--abs_t ABS_T [ABS_T ...]]

options:
  -h, --help            show this help message and exit
  -x X [X ...]          one or more x points to evaluate wave height
  -y Y [Y ...]          one or more y points to evaluate wave height
  --use_buoy_origin     points are relative to buoy origin (world otherwise)
  --rel_t REL_T [REL_T ...]
                        enter one or more relative time (+/-) values in decimal seconds from sim
                        time to compute height
  --abs_t ABS_T [ABS_T ...]
                        enter one or more absolute time values in decimal seconds to compute height

$ ./send_iwh_req.py -x 1 2 3 -y 4 5 6 --rel_t 0.0 0.0 0.0 --use_buoy_origin

[hamilton8415]

Got it. All features are evident to me now. Looks great, the flexibility here should cover all of the cases I can imagine. Ship it. :)