That's an assumption. As you posted "These pairs are colored and arranged in the same fashion as a Cat5 networking cable including cross-talk resistance" - but it does not say "it complies with CAT5 specs". The only thing they say is that the color scheme of the cables is CAT5 compatible - if that's god enough for you. I can say from experience that there's always a good reason why the datashees are not pubicly availabe. And usually the reason is not that they exeed the claimed specs.
My assumption was based on one of their forum posts. But I agree with you that it is nowhere near a guarantee
How much data do you have to send up the tether? i.e. how much data do these sonars emit and do you plan to process it on the drone to manage depth?
I intend on sending video from a secondary device and depth measurements (Which I forgot to mention in the post). The data will need to be processed on the drone. The sonars transmits a distance and a confidence level through serial
If you foresee your application sending 100mbit+ data through an ethernet-like cable/tether, maybe you should select a controller that can talk ethernet and generate 100mbit data? Some sort of Raspberry Pi perhaps?
I'm not planning on transferring nowhere near that amount. But I am going to use a pie for video capture. I was thinking I could use an Arduino mega for the controls and sensor data collector and have it communicate with the pie.
1 Like
Buy a full spool of the cable and begin testing right now, rather than after all the other stuff has been built and suddenly you find that your transferring plan will not work. Prove you plan one step at a time!
2 Likes
The main factor affecting a PID controller's performance is the physics of the system being controlled. One often needs to slow down the sampling and adjustment times of a PID controller to match the system. How fast does/would your system respond to roll, pitch, and other control commands? And how fast do you foresee updating the PID setpoints?
That's exactly what I am worried about - especially since it will be sampling from several sensors. I think it will be reacting quiet quickly (I'm still working on the fluid simulations), but the setpoint will only have to be updated at startup. The ROV will be moving with around 5 knots.
Knowing nearly nothing about your system, I can't imagine a 5kt underwater drone needing control loops faster than 100ms, which would give you time to read several severals of sensors.
5kt is 2.5m/s. At 5kt and full ailerons, would it do a full 360° flip/sec?
If you don't need to adjust the setpoints except for once per run, then the communications required by the PID PID are near zero mbit/sec.
Will do. Thankfully we have the spool at hand already. Thank you!
And when you do, do it under water, at about the depth you intend to go (+10% margin) - and be prepared for surprises.
I don't think it will quite as responsive luckily depending on the final wing design. I am trying to make it as self centered and stabilized as possible without the need for too much correction from the ailerons.
Yeah I can't imagine a 100ms response time would be too problematic. (I was thinking it might be way longer than that) Although it depends on how long I make the tail for the elevator as it becomes increasingly more responsive the the further it is from its center of mass.
The controller will however still have to transmit the depth measurements too the surface so some data will have to be continuously transmitted.
Hopefully that will be possible. We already have some normal thruster driven ROVs that I could make the speed tests with. (Although they are not designed to be towed as far as I know)
Depending on the responsiveness, or slowness of the responsiveness, you need a slower control loop.
The longer the arm would might make it more sensitive to the size of the control surface, but the turning would slow since you have a larger body to pivot through the water.
Sure, but the depth/height-above-ground measurements could be used locally by the control loop no matter what the communication rate you use to transmit them to the surface.
Control-wise, if you are 1m above the bottom with a 25° sonar beam moving at 2.5m/sec, the 0.43m sample will have moved 0.25m in 100ms, making the measurements at least ~40% autocorrelated, getting worse the higher you go. Sampling faster wouldn't add more information, and even if you sent depth data at 100Hz, it need not interfere with the PIDs.
I see, thats very insightful. I didnt actually know, that there it worked like that. Thank you!
Thats true. Although it is towed so it proberbly wont be that big of an isssue in that regard.
Thats true, it would be handled locally, but if I were to use an Arduino Mega, isnt it single cored and technically not able to run parrallel loops? Or were you thinking in jjust in general?
Thats a good point. I hadnt even thought about it that way. The drone would actually be limited to above 1m so thats quite reaffirming.
You can use these techniques to run your aileron PID control loop at, for example, 10Hz and sample and transmit other things at 100Hz, receive commands, etc... all on a single process on a single core:
1 Like
That's actually quite a smart way of going about it. Sorry if I sounded rude in that reply - it wasn't my intention. I really appreciate your help! I think I have good plan on how to continue with the project now. I truly appreciate your time and help with this!