@Rusty- One of the T100’s may be okay (it turns with the normal feel), the other is seized up and was smoking. What does the lead to lead resistance read for a good motor. If the resistance is okay, how much of a risk am I taking in using a new esc to test the motor?
Richard,
First PVC doesn’t like to bond well with a lot of things. I don’t care what the packages say for all of the epoxies the main problem was the PVC itself. In the case of the pipe etc. unless you said it and tack it up with MEK or something to increase the surface porosity, what looks like a good bond is a heartache waiting to happen. I would not trust a bond with that material to save my life in any pressure environment. I have tried using PVC cement between two pieces of PVC and have leaks at low pressure.
If you want to try that material again, I would recommend machining an O-ring race into one of the components and ensuring the other piece has a decent RHR to form a seal. Never trust an ultrasonic weld, cemented or frankly an epoxy bond with that stuff. It will crack.
On the rubber gasket material, next failure point waiting to happen. The gasket material can handle some serious pressure but the material has a habit of being cellular as in it has micro bubbles all through it and you can get a pressure cascade failure. In this case, for the pressures that you all are playing with … you more than likely would get away with this material, but Rusty has specification O-ring races in the BR WTE for a reason, they should last long after the material gives out.
Richard,
There’s not too much you can do to destroy the thrusters except shorting a phase and letting it overheat. We’ve actually shorted phases to the point that they were smoking and the motors were still fine afterwards.
The phase resistance should measure about 0.3-1 ohm on a normal multimeter (which isn’t good at accurately measuring small resistances). The ESCs have a “hardware check” at boot and will recognize if the phases are shorted or disconnected. There isn’t much risk in trying the thrusters with new ESCs.
I would take apart the one that is seized. If it got really really hot, then the plastic holding the stator can melt and the stator will bend sideways and touch the rotor. That’s not good, obviously.
Best,
Rusty
@Rusty-All lead-to-lead resistance readings on both motors are the same (<1 ohm). The one motor that was smoking is binding in one area of rotation. The other motor turns fine. I will proceed with your advice. Hopefully we will end up with two good motors. Needless to say, both esc’s are melted down and I lost all 3 batteries, the board camera, and the Stamp MC.
Amazingly, the Basic Stamp microcontroller still works! Hard to believe since this was submerged in salt water and it was 30 minutes before I could wash it down with fresh water. I just ordered 2 ESC’s so I can test the thrusters and get back going with my new (literally new!) build.
I was able to remove the T100 wires from the potted connecters by heating the connectors with a propane torch while pulling on the wire cable. As soon as the outer sheath insulation softened from the heat the 3 wires pulled right through and out of the connector without damage. The outer sheath was left attached to the connector. I will have to put a new watertight sheath around the wires but that is easier to do than making butt connections had I cut through the wires at the connector.
Nice to see that you have implemented a through, methodical recovery from your accident.
Regards,
TCIII AVD
Richard,
Why was it necessary to remove the thruster cables from the penetrators? Did you glue the penetrators into the end-cap?
-Rusty
Yes.
Well, I am slowly recovering from the home-grown WTE flooding disaster. Using a BR WTE, I have completed phase 1 (CCTV drop camera) construction and will go out for an at-sea test when the weather permits. That is one high quality enclosure!
Richard,
Glad to hear it! Looking forward to seeing pictures.
Rusty
At-sea test went fine to 70 feet. Here is a pic of the rebuild. Ordering T100’s soon. I’m also shifting processor control from Stamp BS2 to Arduino Metro Mini. Learning C has been fun.
Richard … how well is your weight balanced? Is the rig going to stay horizontal in the water? Just curious as to how is stabilizes in water.
Harold,
Both CG (2 pounds of positive buoyancy) and CB are in the same horizontal spot directly under the tether attachment. Works great, stays horizontal just fine. Once I go to a full-up 3-axis system with neutral buoyancy, keep things horizontal will become a challenge. The 8" long tube is really tight for the innards, so I am going to go with 10" when I go neutrally buoyant. That will somewhat help the horizontal stability in pitch.
Richard
I had A good day! I just finished garbage can testing my ROV rebuild for phase 2 using the BR WTE and T100 thruster. Ocean testing is Sunday.
I am using an adafruit Mini Metro processor and an LSM303 compass. Phase 2 is strictly drop down with heading control. Negative buoyancy is 2 pounds. I am only using one thruster, the other one you see is a burned up one from my flood out and is included for balance purposes. Motor direction and speed are controlled by reading a 0-5 volt signal from the control box. A switch on the control box activates “heading hold”, which works quite well with a Kp = 1, Ki = 0, Kd = 1 (P.I.D). Video camera and processor power are from the control box at 12 volts(3s). On board power for the thruster is a 5200 3s. The tether is cat5e. With only one thruster there is a forward velocity component when the WTE turns, but I can live with that until a second thruster comes along.
Phase 3 will add a vertical thruster and chuck the negative buoyancy weights for full 3 dimension capability. I will use a separate processor for vertical thrust and depth hold.
For those of you following my build you know I am hard over about keeping everything small and keeping drag to a minimum. An 8" WTE is really tight but doable. Plus I love that the whole unit can fit in a “designer” bag my wife gave me.
Richard
The garbage can is a poor test environment for heading hold. I don’t think a Kp and Kd of 1 is correct. I am going to use the unused y and z controls to adjust those K values in situ on Sunday, as someone suggested.
Richard,
Why use another microcontroller for vertical control? A single 328p processor should be able to handle all of the control you speak of without breaking a sweat.
Also, I suggest you start tuning your pid loop by leaving ki and kd at zero. Start by adjusting only kp until you have just a little bit of overshoot, or small oscillations around the target heading, then decrease it to where you have none or very little overshoot. Then add a little bit of ki bit by bit until you have overshoot, then pull back until the overshoot is gone. You will probably not need any kd, if you do, it will be small compared to kp.
The key is changing only one thing at a time to see how it affects the system.
-Jacob
@Jacob-How would you set up the program flow? For heading I use a switch to select manual or automatic (a simple while(autoOn) or while(autoOff)). Once in one of those modes I now would have to respond to a switch for manual or automatic depth control. Seems fairly daunting to me. Any suggestions would be appreciated.
Thanks for the advice on setting up K factors. I didn’t get out for ocean testing today due to the flue.
@Jacob- How would you propose keeping track of the PID data while switching between auto-heading and auto-depth? The PID accumulated data has to be reset to 0 each time you switch from manual control to auto control.
void loop() {
bool hold_heading = checkHeadingHoldSwitch();
bool hold_depth = checkDepthHoldSwitch();
input_forward = pilot_forward_value;
input_yaw = pilot_yaw_value;
input_throttle (z axis) = pilot_throttle_value;
if(hold_heading == true) {
calculate yaw_controller_output;
// Ignore pilot yaw input when holding yaw, and let the pid controller make the decisions
output_yaw = yaw_controller_output;
} else {
clear pid accumulated data;
yaw_controller_output = 0;
output_yaw = input_yaw; // Just pass through the yaw input when we aren't holding yaw
}
if(hold_depth == true) {
as above
} else {
as above
}
output_forward = input_forward; // Always just pass the forward inputs through to the output
send output values to motors;
}