DIY Waterproof remote

@rogjalon They just need to be coded with the same channel. No pairing needed.

1 Like

@Goldy nice idea. Is the thumb piece only held on by a magnet? This could potentially be knocked off when falling.

Hi @g.gregory8, yea at the moment it is just held there by a magnet, It is a really strong magnet though so there isn’t any sign of it coming off but I agree with you that in a fall it could be knocked off. Was thinking maybe a small lanyard to keep the button attached to the case or even a plastic arm with a pivot point on the outside of the case

You can design *side walls" shaped (wedge) to keep that magnet sliding only where it must be, back and forth. I won’t trust that magnet… Even if of the strongest grade

I thought we already had found waterproof potis.

It works just fine! Still, I played with throttle increase delay (you should define variables to make it work) but “Delay” doesn’t seems the right strategy to follow… Tried millis() but that’s made for different purposes. I’m stuck…

Delay make it jerky…

I think the millis() function is the right approach to regulating the smoothing, What code are you using?

I tried to play with the Pacificmeister one. Probably millis need’s a different approach?

Could you post the code source or location of the file?

What are you trying to achieve? If you are trying to slow down the ramp up, Increasing the delay isn’t necessarily the correct approach. If you increase too much you will get less response and update time so will see jerky response like you mentioned. You need to add code to ramp up the throttle value to the target setpoint value from the trigger, similar to the code that is commented out in pacficmeisters example.

I use

if ( throttle_current_us > throttle_sp_us ) {
    // Decreasing throttle faster due to slow response of ESC on decel
    throttle_current_us -= (step_size*5) ;
    throttle_current_us = max(throttle_current_us, throttle_sp_us);
} else if ( throttle_current_us < throttle_sp_us ) {
    // Increasing throttle
    throttle_current_us += step_size ;
    throttle_current_us = min(throttle_current_us, throttle_sp_us);
}
2 Likes

The loop time through the code can be variable and undetermined, especially when adding other sensor steps, logging functions, etc. The approach I would take would be to define a ramp up (and down) per unit of time and balance the step size as related to the milliseconds passed since the last update.

Yes you are correct, depending how much and what is in the code. But on a simple sketch like the example presented a simple little delay would be fine. I run a scheduler on my micro so this loop gets run at the fixed rate I set. I run it at 20Hz (50ms).

Thank you Gregory! I will play with this, just to see how it works. My goal is to achieve a very soft accelleration ramp, like a continuous and smooth curve, and why not even a smooth deceleration as well.
Pacificmeister code is a good start, Alexander ones should be the good one for my purposes (waterproof remote) but I need to implement this soft start. I’m a newbie in Arduino…

I’ve seen @x-jets “foiling 2.0” project with the sensors, far beyond!! But for now, I think that we might be ok just smoothing the motor response. But it’s good to know that there’s no limit to development!

Love the design, Have you considered releasing the files to the community to print?

Thanks @ATRIAY11. Yes, I will share the files, want to make sure it all works properly before I do though so I will share them once I have everything finished. Cheers

3 Likes

hi guys found an interesting supplier tonight of waterproof connectors, i'm kind of looking for connectors with a rating higher than xt90's maybe 150amps for a safe margin, any ideas? also have a few wired servo controllers on the way, its just a little Potentiometer with the 3 servo wires to connect to the esc, going to have a wired controller for now and maybe some kind of kill switch, at hand, (going to change the potentiometer for a waterproof one)
but in my aquastar 240A esc manual, it says cutting the battery power lead will damage the esc, need to think of a safer cut off option there is an on/off switch on the esc not sure if its the way to go yet,
sorry heres the link (forgot to add it last night, sleepy head)
http://www.atakel.com/urun/large-series-waterproof-connector/EN/

1 Like

Hi @Alexander ,
In the picture of arduino connections for the transmitter, you recommend the use of a Pro Mini instead a Nano. However, the hall effect sensor yellow wire connects with the A8 pin which is not available on the pro mini. Should I use the A0 pin on the pro mini instead?
I am using The @pacificmeister programing codes, will the need to be any change to the code to adapt to the change in pin?
Arduino is all new to me, so any help and advice would be appreciated.

I used two mini instead, and two 5V to 3.3V shield for the NRF24, to avoid transmission problems.
@pacificmeister code works as it is, I couldn’t get it work using that delay function unless some minor mods, or the sketch won’t compile, but I found it not too smooth as ramp. (you need to compile as it is, //comments should stay as they are even tho they are commands).
Now, with the help of @g.gregory8 (the most of the code, I’m a jerk with Arduino!) I’m trying to get that work with a smooth and controllable throttle ramp.
So far, it doesn’t work but I think we nailed the transmission problem. Tonight I will test it again.
Sensor port: A0 (or A1, A2, any analogic port, but you need to change the number in the code).
Once fixed this code, the goal will be to implement part of @Alexander code for the LED feedback and possibly to get some sort of throttle calibration for the Hall sensor.
There’s a very cool code in Github, as Pacificmeister mentioned, written by a eskate guy, it’s way too complicate for our needs, and it’s made for VESC, but probably we can borrow something from that too…
Once ready, I will model a back wheel waterproof model, of “gun style” remotes we already have plenty of good designs.
If g.gregory8 will agree, I will post the code also. At your own risk:scream: obviously, but won’t be great to work at a remote code all together?

3 Likes