We have an omnidirectional surface vehicle with a thruster configuration identical to a BlueROV2, except that the vertical thrusters are not installed. Autopilot is a Pixhawk 6X running ArduSub 4.5.6. Since this is a surface vehicle, we have integrated joystick control by connecting Spektrum to the Pixhawk DSM port and mapping RC channels to the appropriate degrees of freedom. Arm/Disarm and Mode switch (Manual/Guided) functions are handled by the LUA script running on the autopilot. LUA script monitors dedicated RC channels and performs the switching. This all works flawlessly: we can control the vehicle and arm/disarm it.
The issue arises when attempting to use GUIDED mode. Since we are running the ArduSub firmware, GUIDED mode requires a valid EKF3 estimation with an external barometer for Z estimation. Our primary position measurement is GPS. After reading the related topics on the forum, we found it is not straightforward to bypass the barometer requirement and decided to just plug the BAR30 sensor into the Pixhawk (although we do not require Z estimation for a surface vehicle).
We have set up the relevant parameters: BARO_EXT_BUS = -1, BARO_PROBE_EXT = 512 (MS5837), EK3_SRC1_POSZ = Baro. With this setup, the BAR30 is correctly detected on I2C3, and EKF3 initializes successfully, allowing the vehicle to enter GUIDED mode (when manually switched in QGround control). However, when the BAR30 is detected and actively used (i.e., when BARO_EXT_BUS is set to the correct bus), the Lua script stops working. We consistently receive the error: “lua:1: unexpected symbol.” As a result, the arm/disarm and mode-switching logic implemented in Lua no longer functions. If we change BARO_EXT_BUS to any other value (except 3), with the BAR30 still physically connected, the BAR30 is no longer detected, but the Lua script starts working normally again. This suggests a conflict (somehow) between the LUA script and BAR30.
Our questions are:
What could be causing this interaction between the BAR30 (I2C3) and the Lua?
Is there an elegant way to avoid using an external barometer altogether for a surface vehicle while still enabling GUIDED mode in ArduSub?
If the BAR30 is required, is there a recommended configuration or workaround to prevent this conflict and allow Lua scripts to run normally?
Note that radio control support has been added in ArduSub’s development releases, which you may wish to try out instead of using a Lua script. As with any development firmware it’s possible some features aren’t working as expected, but ArduPilot 4.7 is nearing its beta testing period anyway, so if you’re willing to test and report any issues you run into that would be appreciated
We did some digging to find where this is checked for, and decided it’s an overly strict check given there are conceivable situations where depth is not required or can come from an alternative source.
We’ve raised a pull request to make the check less hardware-dependent, which it would be helpful if you can check with this Pixhawk 6X firmware:
If you set EK3_SRC1_POSZ to None (0) (possibly with a high value set for EK3_ALT_M_NSE), hopefully your existing setup will work without needing a barometer connected
This seems very weird, especially since the error seems akin to a syntax error, which really shouldn’t be conditional on anything else the autopilot is up to…
In case it’s related, is your Lua script attempting to use I2C for anything?
Thank you for the quick reply. We have tested radio control on our setup, Pixhawk 6X with a Spektrum DX6e paired to a DSMX Quad Race Serial Receiver, and can confirm that it is functioning as intended. We can ARM/DISARM the vehicle and switch modes without using a Lua script.
The barometer “bypass” solution is also working correctly. We can now switch to GUIDED mode without a barometer, with the EK3_SRC1_POSZ parameter set to either None or GPS. We did not have time to thoroughly test the system, but we plan to continue running this firmware and will let you know if we encounter any issues.
We agree that this functionality collision does not make much sense, especially since the Lua script does not use I2C at all. We also do not believe this is related to a syntax issue, as the same script runs without problems when the barometer is not connected. For completeness, I have included our script below in case it helps clarify what might be happening.
Thank you once again for your quick response and help!
Great - really appreciate you checking and confirming!
Definitely a weird situation. Thanks for providing your script - we’ll try to investigate some more, and will let you know if we manage to find and fix the issue
