Mission summary logger - #544
Conversation
The imu-socat alias created a /dev/ttyV0 pseudo-terminal that tunneled the navtube Pi's IMU serial stream over TCP so the vectornav node could run on the Jetson. joe_shmore.py existed only to babysit that fake port, flushing its buffers when nothing held it open. Per #455, vectornav will run directly on the Pi and read the IMU's real local serial device, publishing over ROS 2 topics (DDS handles the cross-machine transport). That makes both the socat tunnel and its keepalive obsolete, so this removes them. Still pending: the serial port in the vectornav submodule config (/dev/ttyV0 -> real device path) is not changed yet, since it needs the actual device path from the Pi and a decision on where that override should live.
|
Hey Carlos, here's the plan from here so you can drop notes on any of it before I go further. Wire the logger into the node and do a first SquareTestMission run to confirm the output matches reality (keeping StdCoutLogger on temporarily to cross-check, then silencing it). Groot2 is already wired in the node so that stays available alongside the text summary, matching what you said about running both. Let me know if you'd reorder any of this or want the table to look different, and I'll adjust before building it out. |
|
Hi Anthony your plan sounds good. I think you're going about implementing this the right way A few notes:
|
|
Okay great, thank you so much man! |
|
Hey Carlos! Here is a snippet of what the logs look like now! I still have the old log code running so you can see the side by side comparison but I will be commenting it out on my local branch until you get back to me on this update! |
|
Can you add the summary files to subjugtaor/mission_planner/logs(new folder) And print the original logs during mission runs |
|
Hey Carlos, just finished what you asked for but I had a question to see what you wanted to do. First, would you want me to add this summary files to the .gitignore so that they don't get committed? If so, which section would it be? (I am assuming I make my own little section called logs or something like that). Secondly, the way the folder and pathing is creating is hard coded and local, if you think it is better to make it so its not just local? |
There was a problem hiding this comment.
Formatting might be easier with std::format, but what you have now also works.
- Change this line to the entire folder
Line 195 in 79da1b1
- Yes, maybe in
~/mil2/src/subjugator/mission_planner/logs
| void callback(BT::Duration timestamp, const BT::TreeNode& node, BT::NodeStatus prev_status, | ||
| BT::NodeStatus status) override | ||
| { | ||
| if (status == BT::NodeStatus::RUNNING) |
There was a problem hiding this comment.
To avoid running every tick, could we use prev_status == IDLE? Haven't verified if this works
| std::cout << table.str(); | ||
| std::time_t now = std::time(nullptr); | ||
| char fname[128]; | ||
| std::filesystem::create_directories("src/subjugator/mission_planner/logs"); |
There was a problem hiding this comment.
We don't necessarily run mission planner in a fixed working directory. Maybe base it off ~/mil2?
|
Tested the prev_status == IDLE change, it works well. The retry nodes now report their full duration from first start instead of resetting on each retry, so RetryUntilSuccessful lines up exactly with its parent RelativeMove and Timeout per leg, which is the behavior we wanted. All nodes still show up, nothing got dropped. Screenshot of a clean SquareTestMission run attached!! I also updated the .gitignore and the pathing. |
|
3 participants
Opening this early for direction and code feedback per our chat, not merge-ready yet.
Addresses #471. The mission planner currently uses BT.CPP's StdCoutLogger, which prints every status transition, and since the tree ticks ~30x/s the terminal fills with repeated lines. This starts on the Format C summary we landed on.
What's here so far is MissionSummaryLogger, a header-only logger that subclasses StatusChangeLogger. It records each node's result and run duration, keyed by node UID so the repeated RelativeMove legs don't overwrite each other, and prints a per-node summary from its destructor so it fires on any exit path including Ctrl-C. It's a logger rather than a mission operation, so no factory registration or CMake changes are needed.
Current state: the class is written and I'm wiring it into mission_planner_node.cpp next to the existing loggers for a first SquareTestMission run.
Direction from here in the comment below, would appreciate your notes on it.