VectorNav: Reorganize message packets #27585
Conversation
lashVN
force-pushed
the
reorganize-message-packets
branch
from
8c7d8e8
to
39461cb
Compare
|
I've tested that I can arm on a VN-210 and VN-100, and that all new logging messages output correct data. Please let me know if there's something else necessary. Unfortunately flight testing at our facility is quite a bit more difficult. Edit: Looks like I still need to update the SIM code to use the new packets. I'll resolve that tomorrow. Feel free to begin reviewing the 2 primary files, as I think those are ready. |
lashVN
force-pushed
the
reorganize-message-packets
branch
3 times, most recently
from
ee9bfac
to
35a71f6
Compare
| @@ -625,11 +518,7 @@ void AP_ExternalAHRS_VectorNav::process_ahrs_packet(const uint8_t *b) | |||
| #if AP_COMPASS_EXTERNALAHRS_ENABLED | |||
| { | |||
| AP_ExternalAHRS::mag_data_message_t mag; | |||
| if (use_uncomp) { | |||
There was a problem hiding this comment.
This existing functionality has been removed?
There was a problem hiding this comment.
While the naming of uncompaccel/uncompgyro/uncompmag implies they're handled the same, a distinct difference is the mag (compensated) isn't estimated by the internal EKF; our on-board Hard Iron estimator is a pretty rarely used feature, so it seemed like unnecessary bloat and bytes to me (especially given we're using it in our high-rate message). If we think that's still valuable I can readd it.
There was a problem hiding this comment.
It is not only removed for mag? Its removed for accel/gyro too?
There was a problem hiding this comment.
It's available for accel/gyro, here. The diff is a bit misleading
Edit, not clear why permalink didnt' work. New file line 498, diff line 602
There was a problem hiding this comment.
Ah, OK. So is the mag compensated or not now? My preference would be uncompensated I think. Maybe it is possible to turn off the compensation on the VN side so the user can still pick if they really care?
My argument for uncompensated is that AP should be able to do a better job of calibration as it can use battery current if it needs to where as the VN does not have that information.
There was a problem hiding this comment.
It's technically using compensated, but unless the user has explicitly configured the VN to run the HSI estimator, the compensated and uncompensated outputs are both uncompensated.
I will update the simulators in my next push. The total data rate is the same by default (50Hz + 50Hz + 5Hz), but allows for higher IMU rates. I believe because the messages were combined, the INS (used on VN-300) could only achieve 400Hz + 5Hz. It can now output at 800Hz + 50Hz + 5Hz. It may be reasonable to introduce a config parameter to allow customizing the update rate of the EKF packet (which most imporantly includes attitude) but I decided to defer that to later work. |
lashVN
force-pushed
the
reorganize-message-packets
branch
from
d79355a
to
23c72e6
Compare
lashVN
changed the title
lashVN
force-pushed
the
reorganize-message-packets
branch
2 times, most recently
from
9122b33
to
8aeba58
Compare
In AHRS Mode, split the single message to an IMU packet and an AHRS packet; in EKF Mode, split the two messages into an IMU message, an EKF packet, and a GNSS packet. Simplify message header definition to consolidate and eliminate the need for static asserts Update healthy logic and use to represent new packet structure Replace EAH3 message with messages per-packet Add Ypr as configured output in the EKF message
Redefine messages to 3 INS packets, and send as appropriate Resolve SITL failures due to too-long logger message headers
Remove unnecessary header Switch parameters to default initialization Change pointer casting to prevent a const_cast, and remove doubled sync byte when echoing ASCII messages Fix Valgrind report by preventing use of nmea_printf on buffers which may not be null-terminated
Resolve SITL failures due to multiply defined logger message by pulling the call to a single method
lashVN
force-pushed
the
reorganize-message-packets
branch
from
8aeba58
to
d27859b
Compare
A few key outputs for logging are missing, and the current structure prevents 800Hz IMU data using TYPE::INS. I would split the messages into:
IMU packet, EKF packet, GNSS packet
There should also be additional logging messages for the new packets coming through
This both aids in debugging, and allows use of VectorNav uncertainty and status information for internal publishing and use