I am looking to integrate an external pressure sensor with Pixhawk and ArduSub and would like to understand how to achieve this integration.
The sensor in my system communicates via RS485, and I would like to use the depth hold mode in QGroundControl (QGC). Is it possible to integrate this functionality with my sensor? Would using an RS485 to I2C converter be a suitable solution for this?
If this approach is not feasible or too complex, I am considering an alternative: sending the depth hold command directly to Pixhawk from the external sensor while QGC is still running. Could you assist me in outlining a roadmap or providing guidance on how to proceed with this method? My previous works, i could not to achieve sending thruster command while QGC is working.
Hi @omer_1 -
To support your pressure sensor, you’ll need to get ArduSub to understand how to talk to it. This would typically require modifying the source code of ArduSub, compiling it, and flashing your custom version. An RS485 to I2c converter is not likely to help you much in this pursuit - a BluART would let you connect your sensor to the system and handle the data from there! Others on the forum have discussed this before.
QGroundControl is just a ground control station, displaying what the vehicle is doing. Your second approach, controlling your vehicle from a script, can conflict with QGC’s own control link if you try and do both at the same time!
Thank you very much for your reply. I have already observed that the pwm signal I send to the thrusters conflicts with the QGC’s control link, so how can I overcome this? Would it be pointless to use udp:0.0.0.0.0:14550? What is another way to send commands to the thrusters?
How are you trying to do this, and why are you trying to do it while QGC is already controlling the vehicle?
You can’t control the vehicle with conflicting commands, so if you want to use your own control you’ll need to either disable QGC’s joystick input, or close QGC entirely. If you want QGC to receive telemetry from the autopilot while you send commands in a separate program, you’ll likely want to set up an extra MAVLink endpoint for your program to connect to.
I want to improve autonomous modes. I already implemented profiling sonar. I’d like to guide my robot to a safety position autonomously, i ccan find the boundries via profiling sonar.
That confused me. When i connect to raspberry (BlueOS) and pixhawk, its already MAVLink conflicts. In BlueOS interface, Could i create another MAVLink protocol or could you explain more how could i send these autonomous command while QGC is open.
This seems potentially easier to manage by feeding the autopilot the relevant details from your profiling sonar, as part of an Object Avoidance strategy, or custom flight mode (possibly implemented with a Lua script for initial testing, and left there if you’d prefer not to modify the core firmware).
That said, if you’re operating an autonomous vehicle then your onboard computer should be able to command a switch to guided mode, then switch back to auto mode once it has completed its deviation from the path.
In the MAVLink Endpoints page you can create additional endpoints for MAVLink, which means you can have multiple simultaneous connections. If QGC is performing manual control though, it’s not expected for the onboard computer to take over that, so that kind of overriding is likely only practical if the vehicle is in AUTO or GUIDED mode (and is not receiving frequent commands from QGC).