RC Speed Boat with PX4

junwoo0914 · July 24, 2022, 6:21am

Links to other episodes of the Boat series:

RC Speed Boat with PX4 - Episode 0 : Trying out the Boat and integrating Pixhawk

Properly integrating PX4 Autopilot

In my last post, I tested the basic functionality of the boat but didn’t actually use PX4 for its right purpose. So, in this post I will show how I integrated the Autopilot properly and made it actually control the boat.

This is how the boat arrived out of the box. That looks quite empty , let’s fill it up with advanced sensors and autopilot components

What do we need?

So what’s missing from the last boat test? Remember, the goal is to make an autonomous boat. Let’s start with low-level concepts and list higher-level ones as we go on:

Actuator output : Control authority of Thruster and Rudder from the PX4 Autopilot
Rate control : Automatic attitude correction via rudder/throttle input
Global position control : Automatic waypoint navigation/mission execution capability

And in this post we will tackle the first two (well, not much on the rate control but ) parts. Let’s get started!

Configuring Rudder/Thruster to be controlled by PX4

Using Dynamic Control Allocation

As PX4 is now moving onto the new Dynamic control allocation mixing system, I wanted to utilize this for the Boat project as well (also it’s way better than the legacy mixer system). In case you aren’t familiar, please check out this video

Fortunately, PX4 already had a matching geometry “Rover (Ackermann)” configuration. You can read more about the ackermann geometry here. Basically it’s a rover with a propulsion element & a steering control.

And since boats are technically equivalent to rovers driving on water surfaces, it is totally fine to use the rover configuration.

Creating a new RC boat airframe

In PX4, an ‘airframe’ is a file that contains all the custom configurations you need for a specific vehicle, and it gets loaded everytime you boot up the Autopilot.

And as I was planning to do a lot of development on the boat, I wanted a single airframe file that captures the history of changes I make. And also have a setting file that I can fall back to if I mess up the system so badly: if I need to do a whole parameter reset for example. Here’s the airframe I created:

github.com

junwoo091400/PX4-Autopilot/blob/boat_bigstorm/ROMFS/px4fmu_common/init.d/airframes/50005_bigstorm_catamaran

#!/bin/sh
#
# @name Amewi Big Storm racing boat
#
# A generic boat with a thruster and a rudder (not thrust-vectored)
#
# @type Rover
# @class Rover
#
# @output MAIN1 Thruster
# @output MAIN5 Steering servo
#
# @maintainer Junwoo

# Setup Rover default environment variables
. ${R}etc/init.d/rc.rover_defaults

# Enable control allocation
param set-default SYS_CTRL_ALLOC 1
# Set airframe as Ackermann Rover (Throttle & Steering)

This file has been truncated. show original

The airframe file basically does the following:

Loads the rover startup script that configures the vehicle as a basic rover : rc.rover_defaults
Enables the dynamic control allocation
Sets the control allocation geometry as the ‘Ackermann Rover’
Sets the disarmed value for the Steering servo channel to be in centered position
Enable the commander prearm mode so that Servos can move even if the vehicle is disarmed

After flashing the autopilot with the new firmware with this airframe file, you can enable the airframe by going to the Parameters tab and setting SYS_AUTOSTART to 50005, which is the ID I gave with the airframe filename 50005_bigstorm_catamaran.

You can read more about the system startup process of PX4 and airframe format in the user documentation.

Now we have the fundamentals set, let’s get onto actuator configuration

Actuator Mapping

To map the correct outputs I want to use: FMU1 (AUX1) as Thruster and FMU5 (AUX5) as Steering, I had to configure in the Actuators tab few settings.

Set the AUX 5-6 pinout group to PWM 50Hz protocol since Steering servo can only take 50Hz PWM output
Set the AUX1 Function to Motor 1 and AUX5 to Servo 1

That’s pretty much it. Once I did this and connected the signal cables to Pixhawk 4 mini, I could easily test the actuator output using the sliders, which is so helpful when developing an untested vehicle like the boat.

Other setups

RC receiver

As I couldn’t use the simple 2 channel receiver due to it being old configuration of outputting 2 separate PWM output channels for throttle and yaw control, I decided to use a conventional transmitter/receiver.

I chose Radiomaster TX16S, which is running OpenTX program that allows you to flexibly connect to any type of receiver (and it’s open source). And the receiver that outputs the SBUS, which came with the transmitter.

Binding is hard!

As usual, there was an unexpected setback in most unexpected stages of the project. I just couldn’t bind my receiver with the transmitter! For some reason, it seemed to work but it wasn’t, but that wasn’t all.

The Pixhawk 4 mini takes the ‘PPM’ input using its Servo cable format IO interface, which is really convenient to use as most receivers come with the Servo style output (Signal / Power / Ground). So I tried several receivers but they just didn’t work, and when I clicked “calibrate” in QGC > Radio Setup screen, it would say: “Turn on the transmitter”, which meant that the receiver data wasn’t getting recognized properly.

And after a while, I realized that the receivers I am using is outputting in SBUS format, and not PPM (older format). This meant that:

I couldn’t use the PPM RC input interface
I had to use the RC IN / SBUS input connector as the receiver output

Fair enough, I plugged in the receiver that already had the connecter soldered on that I used in my previous tests straight out of Pixhawk 4 and into Pixhawk 4 mini, and it didn’t work .

I was quite puzzled but after noticing that receiver wasn’t even on, I read the Pixhawk4 pinout document, and realized that the connected lines to the receiver were all totally wrong! The voltage/ground was swapped, and the SBUS signal line was connected to VDD_3V3_SPEKTRUM, which doesn’t really make sense.

So I swapped the pins in the connector and voila, the receiver was powered on and started outputting data after I binded the transmitter

Telemetry radio

If there’s one biggest lesson @sfuhrer taught me, that would be to “Always have a second connection”. You will read later on in this post but this saved me later during the test.

Anyways, to have a connection with the QGC (Ground station) during operation (which is really helpful), I added the Telemetry Radio, which was as easy as just plugging in the radio module to the TELEM1 port.

Cherry picking Rover Acro Control PR

Since @Jaeyoung-Lim has already started the PR that brings in acro mode support for Rovers, I wanted to test this out.

github.com/PX4/PX4-Autopilot

Add support for Acro mode on Rovers with Rates Control

PX4:main ← PX4:pr-rover-ratesp

opened 04:40PM - 30 Sep 21 UTC

Jaeyoung-Lim

+238 -41

**Describe problem solved by this pull request** Attitude errors were directly …fed into steering angles for stabilized modes rover and boats. However, this can result in unstable behaviors if the vehicle is operating on slippery surfaces or operating on water. Using a rate control loop improves the stability of the vehicle for stabilized mode. **Describe your solution** This commit adds a angular rates controller controlling the yaw rate of the rover. This is also used for the previous attitude controller in order to stabilize the vehicles. - The rate controller is mapped to the acro mode of the vehicle. The horizontal stick inputs are mapped to the desired angular rate (center stick results in zero yaw rate) and the vertical stick to throttle. - In stabilized mode, the attitude setpoint is moved using the horizontal stick - Attitude controller generates rate control commands to control the vehicle, instead of steering commands - The rates controller is not used for mission mode (yet) **Test data / coverage** Tested for stabilized mode and acro mode in SITL: https://logs.px4.io/plot_app?log=a493e453-4460-4c5d-b12f-db02084b8421 - The yaw oscillations are coming from the gazebo model **Additional context** - This is beneficial since it removes the ambiguity of control logic between ackerman steering vehicles and differential steering vehicles. They can both be controlled through the rate controller (related to: https://github.com/PX4/PX4-Autopilot/issues/13468. https://github.com/PX4/PX4-Autopilot/issues/11994) - This is a re-implementation of https://github.com/PX4/PX4-Autopilot/pull/15257

So I basically fetched this branch and cherry-picked it on top of the test branch I was using (which branched out of the main branch of PX4-Autopilot).

I then added some refactor commits to clean up the Rover Position Control module, which wasn’t really necessary (and is definetely not encouraged for creating PRs, as it doens’t bring in any functional changes and is more of a noise to the PR reviewers).

But I just can’t resist cleaning up the code when it’s so dirty (in my standards ). I will need to learn how to resist this temptation!

More details

I added batteries to both left and right side to balance out the boat (which hopefully would remove the inconsistent turn characteristics between left / right turns)

This is what the boat looked like after setting everything up.

This was a shot

Testing

Bench testing

First I checked if enabling the Acro mode has reasonable rudder movements when I move the boat around. It definitely had some jittery movements (which I need to check the log to exactly understand why), but it seemd all right (when I yaw it to right, rudder moves left which will try to yaw the boat back to left direction).

River bench testing : Failsafe

Before actually launching the boat to the water, I checked the “RC Lost Failsafe” behavior. Since you don’t want the boat to run away / do crazy stuff when you lose the RC signal .

I definitely encourage everyone to make sure you know exactly what’s going to happen when you loose the control by testing them. Please configure your failsafe correctly!!

When I first turned off the transmitter while the thruster throttle was at minimum, it actually went to higher throttle and started to do werid stuff. This puzzled me so I checked the failsafe action and it was set to “Return”. Which meant that boat tried to return to the launch spot, but of course this wasn’t desirable for me at this point since the dock has walls and obstacles all around, so the autonomous return feature would:

Probably crash the boat to the wall (due to GPS inaccuracy)
Probably do weird stuff (since Rover’s position control isn’t so smooth for now, as I haven’t tuned the vehicle and the rover guidance logic itself is probably not mature enough)

So I set it to “Lockdown”, (after reading the comments and code of PX4-Autopilot, I learned that it locks-down the actuators to their disarmed values, and is different from “flight termination”, but I still find their distinction confusing ) and expected the motors to stop completely.

Guess what happend when I disconnected the RC? It kept spinning more for 15 seconds, then stopped. Which left me even more puzzled. Why did it just do that? I don’t want the boat to be moving around for 15 seconds after RC signal is lost!

After some debugging session and reading through the code, I realized that there’s another paramter COM_RCL_ACT_T that defines the buffer time between RC signal loss and Failsafe action trigger . So setting that to 2 seconds did the trick of shutting down the motor within the reasonable time.

And of course, I submitted the Issue

github.com/PX4/PX4-Autopilot

Ground Vehicles should lockdown motors immediately after RC loss

opened 07:32PM - 22 Jul 22 UTC

junwoo091400

feature-request Boat 🚤

## Describe problem solved by the proposed feature Today while testing a PX4 bo…at, I noticed that **there's a considerable delay between RC transmitter turning off and actual lockdown (failsafe action where motors should output disarmed value) having ~15 seconds delay.** This was bad since ideally I would like the boat to trigger lockdown as soon as the RC is lost (since I don't want the boat to run away on it's own! 😱). After some investigation, it was found that the parameter `COM_RCL_ACT_T` was responsible for this: https://github.com/PX4/PX4-Autopilot/blob/6a0f394d463494908c5b4fcbde7b63ab3da66d33/src/modules/commander/commander_params.c#L145-L160 This basically created a 'buffer zone' where the RC link is considered 'lost' but the vehicle doesn't really go into the 'lockdown' mode that was configured via Failsafe [behavior](https://github.com/PX4/PX4-Autopilot/blob/6a0f394d463494908c5b4fcbde7b63ab3da66d33/src/modules/commander/commander_params.c#L820-L837). ![diagram_log_3_Screenshot from 2022-07-22 21-24-14](https://user-images.githubusercontent.com/23277211/180514458-7a2f54b6-3c6a-44b5-b1cb-4c154caebeb7.svg) So in this intermediate state, the vehicle temporarily alters the failsafe behavior as 'AUTO LOITER', which for the boat just outputs the minimum throttle output, but it would be better for ground vehicles to go into lockdown immediately, since contrary to flying vehicles: 1. Rover doesn't need to have loiter mode on to stay in one position 2. For rover/boats, with the loiter failsafe mode activated & having the throttle at minimum, it will inevitably move the vehicle around, which isn't so pleasant as on the ground/water surface, there are a lot of obstacles! https://github.com/PX4/PX4-Autopilot/blob/6a0f394d463494908c5b4fcbde7b63ab3da66d33/src/modules/commander/state_machine_helper.cpp#L709-L713 ## Describe your preferred solution Initially, I thought of having `param set-default COM_RCL_ACT_T 2.0` so that this buffer zone will only be active for 2 seconds for rovers by adding that to `rc.rover_defaults` startup script. ## Describe possible alternatives But there are multiple other things to think about: 1. I was testing this on bench (next to the river), and it freaked me out when I tested the RC loss behavior and the motor kept spinning for 15 seconds. **However, this was at 'minimal' thrust, which in the water pushes the vehicle at around ~0.5 m/s. So maybe it wasn't as bad as it seemed** (since Boat thrusters spin much faster outside water, it seemed like even the minimal thrust would be too much) 2. **If I actually tested this on water, maybe the vehicle would have correctly 'Loitered' and stayed in one point** by doing circle maneuver, which would be acceptable (I imagined that it was just going to move straight ahead with minimal thrust) ## Additional context ### Ground Vehicle RC loss failsafe action Additionally, when I first tried out the RC loss failsafe behavior the vehicle went almost full throttle since it was configured to do 'RTL' as the default failsafe behavior. I think for ground vehicles (which encounters way more obstacle than aerial vehicles), RTL should be used more conservatively. And I am questioning if the default failsafe value should be Return mode, or rather it should be one of Hold/Terminate/Lockdown modes 🤔 https://github.com/PX4/PX4-Autopilot/blob/6a0f394d463494908c5b4fcbde7b63ab3da66d33/src/modules/commander/commander_params.c#L820-L837 ### Resources - Log link: https://logs.px4.io/plot_app?log=b8361fcb-c79c-404b-b68e-4d3dc9e86520 - PR that implemented this delay parameter: https://github.com/PX4/PX4-Autopilot/pull/16406

Water Testing

Now let’s get to the fun part. After verifying the failsafe behavior, I put the boat in the river and let it cruise using manual control.

After doing a couple of laps around, I started to increase the speed and did more aggressive turns. Which was super fun and I just wanted to get familiar with the controls using the RC transmitter, and it was super fun!

There were a couple of things I observed:

Boat jumps up and down a lot (nose pitches up), and I supected this is because there’s not enough nose weight
Boat accelerates really quickly once it reaches a certain speed / condition and it then kind of glides over the surface really fast. The speed increase curve felt exponential.
Giving the full throttle doens’t necessarily lead to highest acceleration in the beginning phase when the velocity is low. This can be either limitation in the ESC, or more on the hydrodynamics (when your speed is low, the momentum applied by the thruster is limited by a factor of the speed)

Boat failing prearm checks

While testing, some errors started popping up on QGC like “Preflight check failed, GPS Speed Accuracy too low” from certain point. And the problem was that I couldn’t arm anymore using the RC controller.

This is where Silvan’s advice saved my day: “Always have the Telemetry Radio connection”. Had I not installed the radio, I probably wouldn’t have been able to regain control easily (and also wouldn’t have a clue what’s wrong with the vehicle).

So how do I fix this? Well it basically depends on the GPS sensor, and if the GPS output doesn’t improve, I will never be able to arm the vehicle.

So I actually went to MAVLink console and did commander arm -f, which basically bypasses the prearm checks and directly arms the vehicle. This is definitely not an encouraged method to arm your vehicle, but for my case it was necessary as I at least needed to regain the control.

But then some more errors popped up like “Compass#0 fault!” which eventually disarmed the vehicle if I recall correctly. I had no idea why this was happening and tried to solve it by setting the MAG0 and MAG1’s priority to ‘Disabled’ (which would hopefully disable the usage of the magnetometers entirely), but I think the errors were still coming up. It was quite hectic haha.

Accidentally flipping the boat

I then cruised around more, but of course no fun comes without accidents , while trying some more aggressive turns and high-speed maneuvers, I actually flipped the boat which was captured in the video below:

It was quite sad to watch the boat flipped upside down, unable to flip itself back up. I really wished that the boat-flip feature Mathieu discussed was a real thing when it happened.

What’s interesting to note was that the ‘emergency rudder’ that was supposed to safely guide the boat (according to the product manual) even when it’s flipped was useless as the thruster out of the water. Bad product marketing !

So the only solution was to swim to get the boat, and after getting it back, I realized that the thruster was not working and it had some water inside. But in the end, I was glad the boat was back.

Conclusion

Log Analysis

Here’s the log of the whole test. Please feel free to check it out and learn from the logs yourself!

>> Boat Test Log Link <<

Here’s what I noticed from the log:

First, I noticed a strong 2.5 ~ 3 Hz vibration, which seems to be related to the bouncy motion boat was having due to the pitch up / down behavior.

Second, I noticed that when I apply full rudder deflection (manual_control_setpoint/y, since PX4 uses Front-Right-Down axis convention and roll input from the RC controller is translated into the Y axis, which is in the Right direction), the boat reached 41 m/s^2 acceleration & 6.5 rad/s yaw rate, at the speed of around 6 m/s.

The math checks out (Radial acceleration = Angular rate * Tangential velocity), and it was fascinating to learn that the boat was experiencing 4G sideways acceleration! Also, the turn radius must have been around 1 meter (Velocity / Yaw rate), which is quite crazy to think about since the vehicle going at 6m/s is turning within 1 meter-ish distance and coming to a full stop.

Things that are still ambiguous to me

Here it’s visible when I disabled two magnetometers as it was causing the fault error (which also doesn’t allow you to arm the vehicle). But I am still not sure how this fault even occured.

I noticed that the IMU sensors get new offsets committed during operation, and I don’t know why.

Here it is visible when I force-armed the vehicle. I am still unsure how the low GPS speed accuracy occurred

Thoughts

It was great to actually let the PX4 control the vehicle, and this is a big step up from the previous test where PX4 was merely a data logger.

But of course, there’s much more to do. Here are the next steps I am thinking of:

Test the acro mode properly (change PID settings and check boat behavior) at a calm lakeside place
Test the position control mode
Test the mission mode, and do waypoint missions

Hope to meet you all in the next post! And this one got super long, so I will try to keep it short on the next one

r0n4n · November 19, 2023, 10:26pm

Hi @junwoo0914

Thanks a lot for sharing this content!

I built a small catamaran with two bidirectionnal motors. So I’m using the Differential Steering Configuration.
I just started to test it in manual mode. Everything works fine !

My goal now is to control this boat with a position controller and to run a mission.
I tried to run the position controller but the boat is not stable at all. It yaws between both direction looking for the target point.

I saw that the developpment is still ongoing for the rovers/boats.
What’s the current state of the position controller ?

Has it been tested ?

I can support the development and the tests if needed.

junwoo0914 · November 19, 2023, 11:04pm

There seems to be some development in the rover control recently. Could you try this?

github.com/PX4/PX4-Autopilot

Differential drive for Rover & Gazebo R1 Rover port

PX4:main ← PX4:Differentialdrive

opened 04:36PM - 17 Nov 23 UTC

PerFrivik

+1579 -47

### Solved Problem This PR addresses two key points: **Differential Module:** 1. The existing `RoverPositionControl` module, handling both `Differential` and `Ackermann` rover configurations, limits the potential of each configuration due to their distinct maneuvering capabilities. 2. The module's interface elements are more suited for drones, leading to inefficiencies in rover control. **Gazebo R1:** 1. With the deprecation and firction issues of Gazebo-classic, we are want to update the testing environment and lay the foundation for validating the current and upcoming rover architecture types. ### Solution **Differential Module:** 1. To seperate the individual rover types, we have started to restructure the control architecture into separate modules and vehicles types (differential, ackermann, mecanum, etc.), starting with the introduction of `differential_drive_control` module along side the `DifferentialDriveKinematics` library. The module is specifically tailored for differential rovers and, in its current release, supports **only** manual mode. Figure 1 presents our initial implementation plan, with areas requiring further development highlighted in red. ![image](https://github.com/PX4/PX4-Autopilot/assets/94360401/cdb8760f-d1d6-4ee9-9971-603d601f6d64) $$Figure. 1$$ | Symbol | Description | Unit | |--------|-------------------------------------------------------------------|-------| | $$V_x$$ | Linear Velocity in the X-direction (relative to the rover's body frame) | m/s | | $$\omega$$ | Angular Velocity around the Z-axis | rad/s | | $$\phi_{l,r}$$ | Angular Wheel Velocity for the left (l) and right (r) wheels | rad/s | 2. In the context of rovers, it is possible to directly map their angular wheel speeds to body velocities. Therefore we have implemented the `DifferentialDriveKinematics` library and with this approach, the controller's inputs are the linear and angular body velocities, and the outputs are the wheel angular speeds, which are directly published to actuator_motors. This way of control, allows us to bypass the control allocation module and directly control the wheels. The calculation of wheel speeds is based on the inverse kinematic equations for a differential drive rover, taking the requested body velocity rates as inputs. Here are the **inverse kinematics equations**: $$ \dot{\phi}_l = \frac{v_x}{r} - \frac{L}{2} \cdot \frac{\omega}{r} $$ $$ \dot{\phi}_r = \frac{v_x}{r} + \frac{L}{2} \cdot \frac{\omega}{r} $$ and for future references, the f**orwards kinematic equations**: $$ v_x = \frac{r}{2} (\dot{\phi}_r + \dot{\phi}_l) $$ $$ \omega = \frac{r}{L} (\dot{\phi}_r - \dot{\phi}_l) $$ | Symbol | Description | Unit | |--------|-------------------------------------------------------------------|-------| | $$L$$ | Wheelbase, distance from left to right wheel | m | | $$r$$ | Radius of wheel | m | The kinematics equations used here are based on the motion model described by Frank Dellaert and Seth Hutchinson in the "Introduction to Robotics and Perception" course, specifically in the section on the differential drive robot's motion model. Further details and examples can be found in their course material. Source: [Motion Model for the Differential Drive Robot](https://www.roboticsbook.org/S52_diffdrive_actions.html) **Gazebo R1:** 1. We ported the SDF from gazebo-classic to the newer Gazebo GZ version and introduced GZMixingInterfaceMotor, a new interface class for motor control. For the motor velocity control, we are using the [joint_controller plugin](https://github.com/gazebosim/gz-sim/tree/gz-sim7/src/systems/joint_controller) provided by Gazebo (GZ). ### Changelog Entry For release notes: ``` Feature: Introduced base architecture for new rover modules Feature: Introduced `differential_drive_control` module and `DifferentialDriveKinematics` library for enhanced control of differential rovers, currently supporting manual mode only. Feature: Ported glazebo-classic R1 rover to Gazebo (GZ) ``` ### Alternatives Open to any suggestions. ### Test coverage Unit/integration test: DifferentialDriveKinematicsTest SITL tested ### Context Excuse the laggy videos... Gazebo-classic: https://github.com/PX4/PX4-Autopilot/assets/94360401/b624dca8-66f8-4166-96c6-dfe9a532e9f6 Gazebo (GZ): https://github.com/PX4/PX4-Autopilot/assets/94360401/19062eca-b77f-48ef-b4ae-4114119173e2

MaEtUgR · November 21, 2023, 9:41am

Just to be clear: Rover ≠ Boat. The dynamics are different.
That said if you want to inspire yourself from the reworked differential rover implementation it might be a good reference to start a boat control implementation that anticipates the drift in the water and so on. You can also use it directly if it satisfies your needs but please do not put boat-specific things inside the rover implementation, that historically made solutions worse for all use cases.

r0n4n · December 16, 2023, 7:34pm

Indeed this controller will probably not be the most efficient to control a boat. But I’ll try anyway and see the result. If it doesn’t work, we could create another dedicated controller for the boats.

DaShen96 · January 25, 2024, 9:15am

Hi !!
We have the same requirements and are currently developing a differential drive ship controller. We plan to use PX4 for development. Are you still using PX4 to develop ship controllers? If so, what is the effect?

r0n4n · January 25, 2024, 9:54pm

Currently PX4 is not able to control a boat with a differential drive.
Therefore I started to implement a new controller for this architecture in PX4.
I will create a pull request soon to share my code.

Jaeyoung-Lim · January 26, 2024, 8:23am

@r0n4n I have added Add Boat Mission mode support through rate controllers by Jaeyoung-Lim · Pull Request #20082 · PX4/PX4-Autopilot · GitHub a while ago, but needs testing to be merged

r0n4n · March 21, 2024, 9:21pm

I created a new pull request to implement this feature : Implement a boat position controller for a bi-motor catamaran by r0n4n · Pull Request #22915 · PX4/PX4-Autopilot · GitHub