Hello,
I assemble ROV for “Explobotique” association in France.
my setup:
Control card: Dropix v2.1 (equivalent to Pihawk)
Radio RC : Taranis 9XE
BlueROV configuration with 6-DOF positioning thrusters. (Frame: bluerov)
Advancement:
OK assembly
Initial setup OK
I managed to program a flight mode button (Stabilize and AltHold) and a “motor emergency stop” button on the radioRC.
But I can not configure a button “Arm / Disarm”. Need help here.
Currently, radioRC “ARM / DISARM” works as follows: (view image)
but the reaction of the engines is not good. engines panicked.
I tested “USB” live via “QGroundControl” and “joystick” behavior is good.
Sorry for my English Approximate
You cannot set up a method to arm like this with ArduSub. The only option available right now is to use the joystick buttons. You can set the “arm” and “disarm” functions and connect them to joystick buttons using the BTNx_FUNCTION parameters.
Thank you for the quick reply,
So if I understand correctly, the only current solution is to go through an Ethernet connection via raspberry (or other) and use the PC with the joystick?
the first test (in workshop) I have done with the PC and joystick USB Direct (without raspberry) was good.
If someone in a wiring schema the solution with raspberry I’m interested.
There are two options for communication to the ROV with ArduSub:
You can use the Blue Robotics Fathom-S Tether Interface, in which case you do not need a Raspberry Pi. This option uses an analog camera and is simple and reliable.
You can use an Ethernet connection and use a Raspberry Pi on the ROV, connected to the Pixhawk autopilot. We’ll have a few tether board options very soon to make this much easier as well. There is a little more setup involved in this one to get the computer running.
Attached are two draft wiring diagrams that show this.
Motors 3,4,5 are the vertical motors but it looks like the RC3 raw value is correct. Because of that, I would guess that the RC3_MIN parameter is set incorrectly and the range of the RC3 is getting skewed. RC3_MIN should be 1100. Is that correct?
Hi Rusty,
RC3_MIN was at 984, so I changed to 1100.
but it does not rule the problem.
I will attach a copy of some RC Desktop if you see other things.
Thank you
++
When you arm the motors, the flight controller immediately begins stabilizing. This means that the flight controller is outputting to the motors in order to try to get the vehicle exactly level. The if the flight controller is not sitting level, even by a fraction of a degree, the motors will spin as the flight controller tries to correct. As the motors spin to correct, and the angle of the vehicle does not change while the flight controller tries to correct, the flight controller will try harder and harder to correct by increasing the output to the motors, so the motors will spin faster and faster.
If you need to confirm directions of the motors, you can arm the motors, give an input on the joystick, and disarm the motors, then repeat as necessary.
There should be a new flight mode soon called manual which does not perform any stabilization so bench testing will be easier.
Hello Jacob,
I tested in a pool to prevent outside water stabilization problem.
the vehicle plunges straight to the bottom ^^
Given that I have the original BlueROV, there may be the “Factory” data I could control?
I’m stabilized mode.
I have no depth / pressure sensor (I forgot to tell you).
I have not tested yet because I do not know QGC well,
I do not know save a short log in QGC.
Good evening,
After several tests, I reinitilisé the control card.
I loaded the firmware and all parametered.
the ROV works perfectly.
it remains to solve the water and make a support for servo / tilt.
Thanks for the help.
