I was riding home after work, as I do every night, when my latest version Hoyt Puck remote started beeping, indicating the remote battery needed a recharge. To my surprise, the remote turned itself off after only a few minutes, and my board went into full speed, throwing me off my back on the road. I hit the pavement pretty hard, and the board went full speed into a tree. After a couple of seconds, it stopped throttling at full speed and stayed flipped there upside down. It was fucking scary, to be honest. Fortunately, nobody else got hurt except me.
I’m wondering if anyone else has had this issue with the Hoyt Puck remote. Why would a remote cause the board to go into full speed for some seconds when it turns itself off?
Is there any programming I could do on the ESC to avoid these situations?
Puck 2 red light beep low battery alarm mode is WAY too short. @BenjaminF told JJ to fix this then he got fired. Unfortunately the safest thing is to stop riding the moment it stops beeping. Assume you have 60s.
So this false input feeling happens because vesc will continue the last input it saw before loss of connection (remote battery low voltage cutoff after some short time beeping). This is 1s by default. Or 0.5s. either way that’s too long imo.
If you weren’t touching the remote (coasting) when this happened then that’s a whole other thing we can look into. Vesc defaults to zero pwm after the set timeout.
I don’t think it’s a signal issue so much as a loss of signal protocol. The puck v2 should have been set up to start warning the user and vibrating sooner like the v1 does and people expected the v2 to behave as well as loss of signal connection by the receiver should bring the ppm or uart output to neutral in a controlled but rapid way.
I know if i kill the power to the zmote regardless of my throttle position it goes to neutral. You could only have this type of failure if your receiver dies… or you are riding a busted remote. Tried the latter and 0/10 do not recommend
100% not a signal issue based on the original post.
The puck does this too. It’s a basic feature of esk8 remotes. The behavior for when there is no input is defined in the vesc settings. I forget where, I gotta look. Unfortunately you can’t see that setting unless you’re actively connected to a vesc on mobile.
Do you recall where this is? I must have messed with it but I can’t for the life of me remember and it’s not on my list of vesc “ must check “ items and should be
my controller is way safer because i have my own receiver, so if anything wrong happens between the packets received from the controller, the signal goes immediately to 127 (neutral) which happens every 10ms
This is how most esk8 remotes work. They all also have their own receivers. I don’t know of any that use an off the shelf receiver. Most popular esk8 remote that doesn’t do this (by default) has not been used by many for years. What’s it called @b264 ?
Your remote is very cool and I look forward to supporting its development.
I’m not sure. I’ve never used one that didn’t go to idle on signal loss.
In a non-esk8 context, if you are sending UART control commands and cease transmission, it will stay at the last known value until the VESC timeout and you can make that as long or short as you want. But I don’t recall seeing an esk8 remote that had this issue.
most esk8 servo control (pwm/ppm) remotes the receiver has it’s own failsafe when signal is lost, it drops to a neutral pulse width output.
I actually want to test this hoyt now I’d be surprised if it didn’t have a failsafe in the receiver. as you said elsewhere it’s basically a gt2b.
usually the only time you rely on the vesc input timeout is when the input from the receiver is cut. (power or cable)
(the uart remotes OTOH are a different story most of them the receiver does nothing on signal loss and you rely on the vesc timeout. )
either way people should set the vesc timeout down to something less than 1s default.
It is in App>general>timeout right? Have you tried it?
I tested this with a vx1 under ppm and uart but it doesn’t have any effect in stopping time. Stopping time is the same even if the timeout is 10 seconds. I think the real time out is hardcoded in the receiver .
yeah. often the receiver never drops output… and has it’s own logic to go to failsafe output. in my experience that’s pretty quick. but i haven’t closely observed that many remotes.
what kind of time did you see taht felt like almost a second… which is ick. especially if caught while accelerating.
and if the receiver never drops output to the vesc, the vesc timeout doesn’t come into play.
if you wanted to test further you could put vsec tool in ppm mapping mode… to display the incoming signal. disconnect the receiver to see the drop connection behavior. plug it back in and do your test to see the receiver behavior.
Yes one second. I timed it from the videos. I did many tries and have many videos. Also worth noting that if you are in duty cycle mode and you have a signal loss the motors will hard stop and throw you off. On current mode they stop gracefully. SO better use current mode… I have a video with current mode on esk8 telegram but for some reason i can’t upload it here…
Yes this is what i observed, it goes to failsafe from the receiver so the vesc settings don’t have any effect . I tried ppm and uart, same result
Sure i will try that too. I am mainly interested to see what happens in real world scenarios first.
I would love if @eBoosted could give us more information. Like how much time was the board accelerating ?
