Hi
I am exploring the system with a PIX32 v6, with standard baseboard.
The configuration I am aiming for is a boat with 2 fwd/aft port/starboard esc controlled brushless motors, a forward mounted bow thruster, also esc, but brushed motor, and rear mounted rudders, behind both props, but linked to turn together.
The problem I am experiencing is that the standard Omni3 doesn’t allow for a rudder, and I am not sure if the discussion for the 3a, was completed? I get the message that in pre-arm there is a problem, and to “check steering and throttle configuration.”
Now if I change the Servo1_function to ground steer, and not rudder, then this message goes away. Is it that the rudder is not possible with the Omni3 config? I did try changing the port and starboard motors from (Servo2_Function =motor3, & Servo3_Function =motor2,) to motorL & R, but that didn’t help.
Am I missing something obvious?
Regards CC
I would try 2 options both with Omni 3 frame. In each of these the rudder servo is connected to Servo4.
Hi Dave
Many thanks for the reply. It’s really good to work through the concerns and questions. I had been worrying that the ground steering would effectively have a positive action, and no “slip” whereas a propeller or rudder has a varying degree. So using the motor2, (bow thrust) signal does make good sense.
Would the calculated signals to the ESC/rudder servo, take account of the slip, ie when the water across the rudders is moving faster, the rudders will be more effective?
CC
I think the problem, or at least a challenge to overcome, is scaling the rudder output vs Motor 2 output. I’m not sure the Ground Steering method would even work but easy enough to try both scenarios. Why would you need more Yaw authority than the Omni Motor 2 would give?
I should state I have not built an Omni vehicle just spitballing based on what I know of Rover which I do have general experience with. @count74 might have a good answer.
Yes you are right. There would be plenty of rudder yaw authority, at higher speeds, though I was wondering if the system would realise that the rudder was doing little at low water speeds, and be trying to over-compensate? I guess that the 1st runs, would be used to tune the responses? Ironically the bow-thruster is less effective at higher boat speeds, as the water rushes past the thruster inlet ports.
The boat I am intending to use for this system is a model of an anchor handling/rig support vessel, the Model Slipway kit, the Aziz. It works well, with control from RC equipment, using a rudder mixer, to control the axial motors in differential steering. The bow thruster is controlled from a separate knob. I built in an arduino nano, for 7 stage lighting changes, but I hadn’t, yet, planned to build this into the Ardupilot. I find it fascinating what can be achieved, with such control systems.
CC
I have never tested the omni 3 configuration other than some testing in the bath on a Southampton tug fitted with a bow thruster. the 3A config moved in the right directions but I never got around to tuning it so im not sure how it would react. It sounds like a good idea to use the motor 2 output for the rudder rather than ground steering as the ground steering output will get reversed as the throttle average goes above and below the centre position.
The thrusters are just going to yaw the boat at the moment in automatic modes as there is no lateral control in ardupilot other than in manual modes like acro and manual. im just running my thrusters with RC passthrough at the moment as I don’t want to use them all the time.
I have a lua script thats untested, the idea is to be able to switch what motors are active so it can change between omni using the 3 thrusters, or ackermann and skid steering using the 2 main motors with the 3 thrusters disabled…
local SCRIPT_NAME = 'group motor control.lua'
local RUN_INTERVAL_MS = 200
local RC_OPTION = 300
local THROTTLE =70
local THROTTLE_LEFT =73
local THROTTLE_RIGHT =74
local OFF =135
local MOTOR_1 =33
local MOTOR_2 =34
local MOTOR_3 =35
local MAV_SEVERITY_INFO = 6
-- wrapper for gcs:send_text()
local function gcs_msg(severity, txt)
gcs:send_text(severity, string.format('%s: %s', SCRIPT_NAME, txt))
end
-- ! setup/initialization logic
local rc_chan = rc:find_channel_for_option(RC_OPTION)
local last_sw_pos = nil
function update()
local sw_pos = rc_chan:get_aux_switch_pos() -- returns 0, 1, or 2
if sw_pos == last_sw_pos then return update, RUN_INTERVAL_MS end
if sw_pos == 0 then
param:set('SERVO1_FUNCTION', OFF)
param:set('SERVO2_FUNCTION', OFF)
param:set('SERVO3_FUNCTION', OFF)
param:set('SERVO13_FUNCTION', THROTTLE)
param:set('SERVO14_FUNCTION', THROTTLE)
)
gcs_msg(MAV_SEVERITY_INFO, 'Ackermann ')
if sw_pos == 1 then
param:set('SERVO1_FUNCTION', OFF)
param:set('SERVO2_FUNCTION', OFF)
param:set('SERVO3_FUNCTION', OFF)
param:set('SERVO13_FUNCTION', THROTTLE_LEFT)
param:set('SERVO14_FUNCTION', THROTTLE_RIGHT)
gcs_msg(MAV_SEVERITY_INFO, 'skid-steering')
else
param:set('SERVO1_FUNCTION', MOTOR_1)
param:set('SERVO2_FUNCTION', MOTOR_2)
param:set('SERVO3_FUNCTION', MOTOR_3)
param:set('SERVO13_FUNCTION', OFF)
param:set('SERVO14_FUNCTION', OFF)
gcs_msg(MAV_SEVERITY_INFO, 'Thrusters')
end
last_sw_pos = sw_pos
return update, RUN_INTERVAL_MS
end
gcs_msg(MAV_SEVERITY_INFO, 'Initialized.')
return update()
Many thanks for your reply. There is a lot of good stuff there. I won’t confess to understanding the LUA code, but will take some time to work through it. I did load the Yaapu LUA script to the transmitter, so that the telemetry is displayed there, but I have not begun to workout how it does it, or even if I should. Arduino is OK, but getting to grips with LUA and C++ are future aims!?
I have tried very briefly to get sideways movement of the Aziz, by running 1 motor ahead, the other astern, and holding the yawing, by running the bow thrust, but there is room for more experimentation.
Many thanks CC