We have a setup similar to the Blueboat. We are using 2 T200 thrusters for skid steering and a T500 in the center (intended for extra thrust).
We are trying to add the 3rd motor that will give us extra thrust. This motor (T500) is placed in the center of the other two. We want to control this motor separately and only use it when we need the extra trust.
We can’t seem to get it to work. We tried attaching it to a button on the Xbox controller in order to enable it when the button is pressed.
Has anyone done anything like this before? Any help will be appreciated.
Thanks in advance.
Hi @gademetriou -
Welcome to the forums!
Unfortunately, ArduRover does not have a frame type for a 3 motor skid-steer vehicle. To get things working you could develop a Lua script that controls the third motor output channel based on the average of the other two motors? Or, you could map it as a servo output and control it manually, incrementing thrust levels up and down via buttons mapped on your controller. Can you share what you tried to get it mapped to a button?
However, if operating in Auto mode, both approaches run the risk of confusing the autopilot / tuning, and leading to poor waypoint navigation performance.
The ArduRover forums may be a better place to seek guidance on this!
Hi Tony!
Thanks for the quick reply.
We tried the ardurover forums but could not get any straight answers.
We tried several things. Mostly trying to map it to a servo output and a button (R1 or R2 on the Xbox controller) as you suggested here. We are doing something wrong apparently. The T500 just peeps constantly in some cases. In the others (when it seems to initialize correctly) we get no control… nothing happens when the button is pressed.
The Lua script approach will not work for us (though if we can’t get it to work otherwise it might be an acceptable solution). We want to turn it on only when needed. With the Lua script it will be on all the time thus draining the battery… But of course in this case we will go shower on the thrust (since we will have 3 motors) thus less amps. Have to see it in action I guess.
The auto mode has to be tested… But not worried too much about that for now.
This is for a funded project we have at my Robotics lab of the University. An environmental project (oil spill detections). I can share more info if you want.
We developed several USVs by using Blue robotics parts in the past. This is the first time we are using the navigator though. We used it on a smaller prototype we developed first for this project and things were fine (that is using only two T200 though, so it was straight forward).
Thanks again.
Hi @gademetriou -
Sorry for the frustrations! ArduSub is well setup to pass button pushes to servo channels, but things are a bit trickier with ArduRover. That doesn’t mean it’s not possible!
A Lua script in no way means the thruster has to be on all the time! In this example, the T500 only turns on when the BlueBoat is upside down… it should have what you need to get things working, in terms of software setup information? This guide is also relevant, and there are many ways to approach this - even using QGC (ugh)
Maybe a Lua script could increase the extra throttle when the difference between actual and target heading is less than some value?
It’s worth noting that depending on the drag and configuration of your boat, just adding more thrust may not make it move appreciably faster… A T500 is well suited for pulling hard, like if you were towing a payload, but if just trying to cover ground the nozzle is actually going to add extra drag and slow you down, above about 1 to 1.5 m/s it is quit a penalty! This prop may help - Blue Robotics will have a better version of it available when the M500 launches. Depending on how fast your target speed is, you may need completely different prop design!
Thanks for the info Tony!
We will actually print and use the propeller you provided. We will design an adapter for attaching the new Thruster (T500 motor and new propeller) to out USV.
We will go with your idea (suggestion) to set the T500 PWM to the average of the other two PWMs.
We will worry about the automode later if it actually causes problems. We will cross that bridge when we get to it (if we get to it with this project)
I will let you know how it goes.
Thanks again!
Hi @tony-white can you elaborate on the differences between Ardusub and Ardurover ref. servos / relays. I read this in the navigator hardware guide to mean all was good with Rover on the later firmware.
“Support for relays requires ArduSub ≥ 4.1.1, and ≥ 4.4.0 for other ArduPilot firmwares.”
It makes no mention of limitations regards servos?
Sure thing @gademetriou -
What is your goal for the additional motor’s use? When testing the BlueBoat with dual M500s and pr that larger printed prop, it was demonstrated that additional speed is quite expensive, from a power perspective!
As for that Lua example, an LLM like Claude, Gemini or ChatGPT can parse example code these days, and likely get something working for you. Testing via SITL is sure to make getting it working quite easy - you can use “print” statements to get feedback in a connected QGC or Cockpit instance, and tell what your script is doing before running it in the real world. All the examples here may be useful, and this is a repository I’ve been keeping to track useful Lua mechanisms.
Hi @mattcmgb -
The differences around servo use in other ArduPilot firmware vs ArduSub are only around mapping to buttons (servo 1 ,2 3, max min joystick functions corresponding to servo 9,10,11) - it’s correct that between both firmwares newer than those specified versions, controlling via lua script and other methods is identical…
You should be able to check the SERVO_OUTPUT_RAW MAVLink messages in a MAVLink inspector (e.g. in BlueOS, or your control station software) to see what pulse-durations your flight controller board (Navigator in this case) is trying to set for the pin you’ve assigned your motor to. That way you can tell whether the button presses are not registering/behaving correctly, or whether it’s a hardware or signalling issue between the flight controller board and your ESC.
Assuming you’re using a bidirectional ESC for controlling your extra thruster, it will likely be expecting a consistent 1500 µs pulse duration before the ESC arms itself and starts accepting motor control commands. That said, there can be electrical issues or clock inconsistencies that cause that intended 1500 µs signal to output or be received by the ESC as a little higher or lower, so you may need to adjust the relevant SERVOn_TRIM parameter to compensate.
1 Like
From a related previous post:
ArduSub will likely end up moving in a similar direction (because in principle an autopilot shouldn’t need to know about or store the specifics of a given input method/device), but for now things are the way they are. ↩︎
@tony-white , we developed (with the help of claude) a test script that will test the center thruster (T500) - before we do anything else we wanted to see it actually runs from a lua script.
We connected the motor to Pin 4. And set the following:
SERVO4_FUNCTION = 0 (for Lua control … correct?)
SERVO4_MIN = 1100
SERVO4_MAX = 1900
SERVO4_TRIM = 1500
nothing happens. the script runs but the motor is not turning.
any ideas?
Tc-Test.lua (3.0 KB)
There are different possible approaches here, but you’re mixing two of them, which won’t work.
-
Per the API documentation, the
set_output_pwmfunction you’re using searches for a PWM output with the specifiedSERVOx_FUNCTIONvalue, which is more versatile than directly using the channel value (e.g. you can configure a different pin to use the specified output, and the script will continue working).For that to work your output function needs to be specified to a value the script can uniquely find, so it’s best to use one of the scripting outputs (e.g. assign the pin to function
Script1 (94), then refer to that pin in your lua script withfunction_numset to94). -
Alternatively, if you’d prefer to hardcode the channel number directly, you can use the
set_output_pwm_chanfunction.Note that the channel numbering is zero-indexed, so pin 4 would be specified as channel 3 (or as
TC_CHANNEL-1, if you want your code to make the indexing change more obvious)
Hi @gademetriou -
In addition to what Eliot mentions, have you enabled the lua script parameter and put the lua script in the correct location with the File Browser?
It can be quite bad (for the dry sheave bearings) to run a T500 or M200/T200 in air, dry, for sustained periods! You may want to shorten your script up, or test it in SITL by monitoring the output channel, to verify the signal would be sent…
1 Like
Hi @tony-white … i think i did put it in the right location. Can you tell me where it should be?
Thanks for the tip about running the motors in AIR. We know this.
But i do not know about SITL. Will check it out.
dear @EliotBR ,
thanks for the tips. you are right.
Will make the changes based on what you suggest
@tony-white @EliotBR
We got it work. We were mixing the two approaches as Eliot mentioned.
Thank you guys for all your help!!
Tomorrow we are doing the first sea trials with 3 thrusters.
3 Likes