Nintendo NES controlled drone

[EliotBR (Eliot)]

@aguy63

… things always just get so busy!

Haha, I certainly know that feeling…
The forum and community are pretty long-lived though, so don’t stress on our account

@aguy63

As it stands now I am using a simple stacked square shape PVC body with two motors acting as thrust and the third turned to act as lift. I have 3d printed some mounting parts that wrap around the PVC and hold very well! Once I get this better put together I will try to post some photos.

Fair enough - I’m keen to see how it comes together

@aguy63

We have actually hooked this up with our older t100 thrusters and have had a great outcome. We were even able to add in some decoding leds that will be mounted to the project area of the Arduino shield we are using to help us figure out if something beyond the controller is acting up.

Great to hear!

The code may be a bit simpler to maintain by replacing some of the repeated blocks with some loops over arrays, but it’s great that you’ve got a functioning base to work from

@aguy63

I need to figure out … a way to keep the tether lines/line from twisting up on itself … I am thinking of adding a slip ring to help keep that from happening. The slip ring would be added in the line far enough that water should never be a problem. You wouldn’t happen to have seen a better way to handle that have you?

Hmm, excessive tether rotation can be a problem, but it’s not a problem we generally need to deal with from an “intentional misuse” standpoint. ArduSub’s orientation tracking gets used to also count full turns (in each direction), and the number of turns is reported to the operator. If someone is concerned there have been too many turns then they would generally turn the other way to untwist things.

A slip ring could work reasonably well, but it depends on your setup. The slip ring would need to be at the end of the usable tether length, which means you either need an underwater slip ring (which seem to currently not have great options available for low cost applications) at the vehicle end, or you need need your tether always fully unreeled/laid out and away from things it could wrap around to avoid tangles at the surface.

I guess the main alternative I can think of would be having the vehicle try to compensate for over rotation by ignoring control inputs and rotating in the opposite direction until it’s evened out, but that could be disruptive and quite unintuitive to deal with from the operator’s standpoint (and dangerous if it’s not possible to make it stop when it’s near something).

If you don’t have orientation sensing in the vehicle (e.g. a compass and/or gyroscope) then there’s additional difficulty from trying to estimate the rotation “offset”. A naive approach would be to just keep track of how much time is spent in each operating mode of the vehicle and just keep the net rotation time (one direction minus the other) close(ish) to zero, but I imagine that’s quite error prone since it doesn’t account at all for how the water is moving around the vehicle.