@rogjalon They just need to be coded with the same channel. No pairing needed.
@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); }
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
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/
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?