I am working with a high school group on their MATE ROV entry and we have a T200 that is acting weird. There have been some wiring problems that cleared issues with the other motors on the craft; however, we have a motor that only turns in one direction.
All of the wiring from the ESC is color-to-color etc. and we looked at the incoming PWM signal with an O-Scope and we are seeing the pulse width go from full reverse to full forward and when not driven … it is sitting at the null frequency.
Brushless motors are very simple machines, and the direction one spins is determined purely by the ESC driving it. If it can spin at all, going either direction is identical as far as the motor is concerned, its up to the ESC. Similarly, the ESC commutation is just reversed for the other direction, all the components are doing the same work, just in a different sequence.
What ESC are the students using? Is it a bidirectional ESC, and is it being driven at the appropriate PWM frequencies to get its full range of motion? Electrically, if the thruster/ESC combination is working in one direction, the only thing limiting it from going in the other direction would be an inappropriate signal or software/firmware limitation.
It is one of your latest version ESC’s. We are using a VEX controller and differential signal boards to get the signal down the tether etc. and as I said we can observe the PWM signal and we get the correct pulse width shift from the controller for the action that we are trying to do.
What are the “stupid” things that can happen to make it just run in one direction when you have a correct PWM signal?
Also, do you have a sample waveform of what we should see on the ESC outputs? We saw some funky looking wave that kinda of looked like a squared off sinewave for lack of better description. Whatever you have for info that would help us at least see input and a correct output … then I guess it is back to easter egging parts
An ESC and thruster combination will run as long as it sees a valid signal instructing it to do so. There’s not much to mess up, short of not providing a valid signal between 1100-1900 μs.
The likely explanation for running in one direction and not the other is not receiving a valid reverse signal. When checking the signal , you should be doing so right at the ESC signal input, as long signal wire runs can cause odd issues. RC style PWM signals are designed to travel a few feet at most, any longer than that and your mileage may vary depending on voltage drop and other factors.
Hypothetically, the ESCs may have had the wrong firmware loaded at the factory and only have a unidirectional firmware loaded. This is incredibly unlikely however, and highly doubt is the case especially if all your ESCs are behaving the same way. We have never seen the wrong firmware loaded in many thousands of ESCs. In any case, if you would like to check the firmware, you can do so using BlHeli Suite and an Arduino. Further instructions and the settings file are located here.
You shouldn’t need to monitor the outputs to confirm the ESC is working right. It will either work because it is receiving a valid signal, or not at all because it is not receiving a valid signal, unless there is hardware issue with the ESC. Since it is running fine in one direction, this cannot be the case.
The PWM signal you are sending to the ESC to command it is just a communications method like any other, its arbitrarily associated with a driving duty cycle just by software operation.
In any case, the outputs will look like this at full throttle:
Thanks for the waveform post. That is what I was seeing on the scope when the ESC was outputing in the one direction. Weird part is multiple units were swapped in … even from the other motors and still the same thing.
I didn’t have much time with the team yesterday to do any solid troubleshooting and the test equipment was laking. I need to take a closer look and track the PWM signal all the way through from the control box, tether etc. to the ESC.
We found one bad terminal connection that was causing a pair of motors to run with a lot of vibration. It was a screw down terminal and we will end up soldering directly to the board now.
I am having a similar issue. In my case the motors can move in both directions when using the QgroundControl motor testing feature. However, when using the gamepad, the motors will only spin in one direction wether I push the joystick up or down. I am using a Logitech F310.
I checked the SERVO_OUTPUT_RAW message and the servo output will always be below 1500 even if I move the joystick into the opposite direction. The SERVO_MIN and SERVO_MAX parameters are 1100 and 1900 respectively for all 1-8 outputs and SERVO_TRIM is 1500.
Does anyone have a clue of what might be happening here? It seems that something is mixed up between sending the input from the joystick and delivering to the ESC.
Hi @Alex_UJI1 -
In QGround Control, please navigate to your Joystick Settings and confirm the “allow negative thrust” and “center stick 0 throttle” check boxes are selected.
The “allow negative thrust” option is not showing up in my QGroundControl app. I tried with v4.4.3 (latest) in one PC and then with v4.3.0 in another PC (both Ubuntu 20)
I am experiencing the same issue. Do you know if the problem is related to the ArduPilot software or its version? Or is there a parameter that needs to be changed to fix it?
Also I have tested the motors in the vehicle setup and they move in both directions.
Hi @Alex_UJI1 and @barajas -
The Blue Robotics recommended version of QGround Control is 4.2.8 - give that a try and see if the check box appears, and selecting it fixes the issue.
Can you both share what autopilot you’re using Pixhawk or Navigator? ArduSub 4.5.1 it seems?
I tried Qground Control 4.2.8 and the check box is still not showing up, but now things went weirder. When I press the “arm” button, the “servo_raw” value from servos output 5-8 goes from 1500 to 0 (1-4 stays in 1500). When I move the joysticks only motors 1-4 move (in only one direction) regardless the joystick movement. When I press the “disarm” button the “beep - beep” sound sounds same as when you power on the BlueROV (the second set of sounds).
I am sharing the autopilot parameters in case some parameter might be off.
We have another BlueROV that is running ArduSub 4.1.0, Navigator board and is working well, but also the checkbox is missing when connecting it to any of the tested versions of QgroundControl (4.2.8, 4.3.0 and 4.4.3). So I tried installing ArduSub 4.1.0 to the faulty BlueROV with the parameters of the good BlueROV and it did not work. Actually now what happens is that, when arming the vehicle, all “servo_raw” outputs go from 1500 to 0 and now nothing moves . When disarming the beep - beep sounds aswell.
Finally I restored everything as it was before (ArduSub 4.5.1) and we are back at were we started, motors move only in one direction when using the joystick but can move in both directions while using the QgroundControl (any version) motor testing feature.
EDIT: We tried the Cockpit BlueOS extension and the BlueROV is still not working.
Further testing:
When we connect our BlueBoat the checkbox appears in QgroundControl! and its marked. I believe because ArduRov allows negative thrust (im surprised ArduSub does not)
Hi @Alex_UJI1 -
Have you calibrated the game controller in QGround Control?
Can you share a screenshot of your joystick axis configuration in Cockpit?
Loading the default parameters for your frame time (standard or Heavy) from the Vehicle Setup menu> Config may resolve the issue, although nothing jumped out to me as incorrect in your shared parameters file.
The issue was finally solved by flashing a fresh image into the Raspberry SD card. It seems that at some point during use it got corrupted(?). Now the motors, the joystick and everything is working as it should.
However, the Qgroundcontrol is still not showing up the “allow negative thrust” checkbox. This might be an issue involving the QGC developers maybe?
Hi @Alex_UJI1 -
My mistake, the allow reverse thrust is specific to ArduRover, and not ArduSub firmware. Glad you fixed your issue - it likely didn’t require a complete re-flash, but just a loading of the default parameters. In any case, glad things are working!
. When disarming the beep - beep sounds aswell.