henthorn/sim pblog

[rhenthorn]

I believe all changes are contained in the sim_pblog folder in buoy_msgs.

[quarkytale]

Any specific reason the logger's named sim_pblog? I was wondering if it could be consistent with pbcmd and just be plain pblog?

[hamilton8415]

I am running this feature and it looks great, I do have a few comments, and I will try to get them appropriately spread between this PR, #47 in mbari_wec_utils, and #140 in mbari_wec_gz, but we may have to review all of these together...

For this PR,

• inside the directory such as 2023-05-02.000, maybe we can have the link be called "latest" to match the buoy behaviors. I understand a level up it's called latest_csv to differentiate it from the name latest that is used/created by colcon. I have a note about this default in Add pblog args #47 too.
• There is no controller Setup CI #5 in the buoy, so I'm not sure where the line beginning with 5 in the log files is coming from. Possibly from a defunct rudder controller. In any event, the numbers are 0 = Battery controller, 1 = Spring Controller, 2 = Power Converter, 3 = buoy based AHRS (NAV440), and 4 = HeaveConeController.
• It's a neat trick to gzip the latest file when the program closes, but we may want to only zip files at the end of each hour. This then matches the buoy behavior, and also, an hour is a very long sim time so multi-hour sims will be rare, by not zipping, it's a bit quicker to look at any given output.

I'm running a 10's of minute sim now and will run the logfile output through the matlab processing next to see how that looks.

[hamilton8415]

Looking more closely, the data isn't quite being placed in the .csv file quite correctly. Here's what I see in my example.

Line with first character = "0", should have battery data, and does in the correct places. :)
Line with first character = "1", should have spring data, and does seem to based on the values, but the data is in the wrong columns.
Line with first character = "2", Should have power converter data, and does in the correct places. :)
Line with first character = "3", Should have data from the NAV440 AHRS, but no lines starting with "3" exist
Line with first character = "4", should have data for the Heave cone, and does seem to based on the values, but the data is in the wrong columns.
Line with first character = "5", there is no controller 5 in this system, I can't quite tell what the data in these rows is but for sure it shouldn't be starting with a "5".

So, some issues, seemingly largely to do the the wrong number of commas. Want me to sing the song??

[rhenthorn]

I mixed-up the controller ids that go in the first column. That also causes the wrong number of empty columns (commas) to show up. This ought to be a one-line fix (CrossbowId = 3, not 5). I regret the error.

[hamilton8415]

Nice, let me know when it's ready to pull and run and I'll check it out. -- ah

…

_______________________________________________ Andrew Hamilton, Ph.D. Engineering Division Chair Monterey Bay Aquarium Research Institute 7700 Sandholdt Road, Moss Landing, CA 95039 Phone: 831-775-1861 Fax: 831-775-1646 http://www.mbari.org/ From: "Rich Henthorn" ***@***.***> To: "osrf/mbari_wec_utils" ***@***.***> Cc: "Andrew Hamilton" ***@***.***>, "Review requested" ***@***.***> Sent: Wednesday, May 3, 2023 12:57:16 PM Subject: Re: [osrf/mbari_wec_utils] henthorn/sim pblog (PR #44) I mixed-up the controller ids that go in the first column. That also causes the wrong number of empty columns (commas) to show up. This ought to be a one-line fix (CrossbowId = 3, not 5). I regret the error. — Reply to this email directly, [ #44 (comment) | view it on GitHub ] , or [ https://github.com/notifications/unsubscribe-auth/AO4ZFCMSGLGLKVFYEQWMZ2DXEK2BZANCNFSM6AAAAAAWBTZ4WM | unsubscribe ] . You are receiving this because your review was requested. Message ID: ***@***.***>

[rhenthorn]

Pushed. The zipped file behavior is an artifact of the gzip class from the gzip package.

[hamilton8415]

Although controller number five is gone and there is data in controller number three, things are still not landing in the correct columns for some of the controllers. I find a good way to check this is to open the .csv in excel, that separates all the values (based on the commas) underneath the named column. I suppose this way of checking isn't correct and introducing a mis-understanding, but I think excel is reliable for this and some of the controllers are putting things in the correct place,

[mabelzhang]

How are you getting the sim time?

If you are writing a Gazebo plugin, it would be free, as it comes in the parameter to the update function.
I see that you aren't writing a Gazebo plugin here.

In the Gazebo world, it is published as a topic

$ gz topic -e -t /world/world_demo/stats
sim_time {
  sec: 2
  nsec: 864000000
}
real_time {
  sec: 12
  nsec: 993655180
}
iterations: 2864
real_time_factor: 0.2707

Does ros_gz_bridge not let you get the Gazebo topic over to ROS 2? For example 14:42 in the talk here that Michael Carroll and Dharini gave https://vimeo.com/showcase/9954564/video/767127300

[andermi]

We are using the ros_gz_bridge to get sim time to the ros node in the plugin to publish the controller messages. The problem is rclcpp::Rate doesn't have any implementation yet that uses sim time and we are using the Rate to control publish rates... so if you check my PR over in _gz, I made one :)

osrf/mbari_wec_gz#146

[andermi]

@hamilton8415 @rhenthorn I believe the logs are working correctly now. The way the timestamps are set up in the csv logs is that it looks as if the logs are written in real time from the time the log started. So the logs will still show 10Hz timestamps even though in wall-time it's churning out data at 20Hz for RTF 2 for example.

I believe this is all working as intended now.

[andermi]

@hamilton8415 Latest patch uses line buffering for csv files :) nicer looking tail -f

[hamilton8415]

For sure. Thanks. Has the same buffering behavior as the buoy now. Much better.

[andermi]

The IMU sensor quaternions look fine all along the chain from the sensor to the csv. The IMU in the sim is located at the link origin where the tether meets the heave cone and is in ENU orientation.

[hamilton8415]

The IMU sensor quaternions look fine all along the chain from the sensor to the csv. The IMU in the sim is located at the link origin where the tether meets the heave cone and is in ENU orientation.

Thanks for checking this. I am able to resolve the pitch/roll/yaw of the heave-cone from this data, but things are rotated by 90 degrees from what the buoy outputs. On the buoy those items come directly off the VectorNav VN-100, so we may need to look into the orientation of that sensor relative to the heave-cone orientation. Or, just make a rotation until the sim data matches the buoy data with regard to which axis points up. The horizontal axes aren't really distinguishable. I think I may be able to say which way things need to be rotated to match...

[andermi]

orientation of that sensor relative to the heave-cone orientation

We can certainly rotate the sensor frame wrt the link

[andermi]

@hamilton8415 latest patch fixes the data loss when log rolling

tail of previous log

4, 1684274770.983, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,60, 48.000, 48.000, -42.169, -0.012, -0.005, -0.064, 0.998, 0.000, 0.000, -0.000, 0, -0.002, -0.032, 0.125, 0, -0.072, -0.228, 9.595, 60, 0, 0, 0,

head of new log

1, 1684274771.073, ,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,10493, 0.47, 46.71, 158.31, 8192, 0, 0.000000, 0.000, ,,,,,,,,,,,,,,,,,,,,,,,

[hamilton8415]

With respect to the IMU mounted in the heave cone. x-y-z axis of the device itself is mounted on the heave cone with it's y and z-azis pointing horizontally. I am not yet sure of the x-axis is pointing towards the top or the bottom of the heave cone, the quaternion multiplication I use to make z point upwards for subsequent computation of heave/pitch/yaw Euler angles is below, so there's a hint in that...

qmult(TC_Qtn,[sqrt(.5) 0 -sqrt(.5) 0]); %Rotate sensor 90 degrees about y-axis to make z point up.

[andermi]

Strange, because I checked the mesh origin yesterday, and the Z axis was pointing up. The IMU should be coincident with this with Z up as well. I'll keep digging

[hamilton8415]

I think it makes some sense, the physical IMU is mounted with z horizontal (when the heave-cone is in the rest position) and therefore the simulated IMU needs to be mounted the same. Or, the output rotated...

[andermi]

Oh oops, I just re-read your previous comment, and yes I understand now.

[hamilton8415]

Testing newtons/lbs meters/inches now...

[hamilton8415]

Looks to me as if everything is correct with this and the analog related to logging in _gz, I am not sure if the tests are all running correctly, so maybe some attention needed there. I will keep testing and hope this can be merged very soon.

[hamilton8415]

I have done further testing for this and believe it is ready to be merged into main, along with mbari_wec_gz #140