Evolve Bamboo GT, Wheels Locked, Crash....

Hey Guys,

New to the forum. Posting this to see if anyone else has experienced this problem, and also, as a warning to those that haven't. This is a dangerous situation that needs to be addressed by Evolve. I know my battle scars aren't as bad as many others, but this is a real thing.

Here is the letter I wrote to Evolve today.

Hey Evolve,

I received my board back in December. I've ridden it many miles since. I bought the street conversion kit and programmed the remote appropriately. I've ridden it everyday from the carport back to my house (about 300 yards).

Last night I was riding in Eco mode and going about 12 MPH, when the wheels literally locked up. DEAD STOP. This happened in a relaxed riding condition and happened so quickly that I was ON THE GROUND before I realized what had happened to me. Thank god it wasn't a faster speed.

The current aftermath is a severe strain to my shoulder, elbow and wrist, bruising to my hip, in addition to the tore up hand and road rash on my elbow. By my best guest I was thrown about 10 feet. I'm 44 and weigh 197 pounds. I hurt.

The next morning it dawned on me that I will never be able to trust riding this again. I've done a great review on this board on Youtube, and have always preached wearing safety gear. But there is no WAY I will trust riding this again. I didn't hit a rock, I didn't activate the brakes, I was cruising with the trigger fully depressed. Additionally, the board was charged to 74% and the remote had been charged that morning.

Now I'm wondering why Evolve chose Bluetooth 2.4ghz over a more robust standard like those in 2.4GHZ hobby RC units (like Spektrum)? I've been flying RC Helicopters for years and have yet to have a problem with my receiver or transmitters. It can't be a question of cost effectiveness as retail on a good brand with 6 channels is $39. Furthermore, what kind of programming results in an instruction to lock the wheels when a radio "brown out" occurs?

Unless there's something that Evolve can do to regain my confidence, this thing has just become a giant paperweight. Seriously, I am of the opinion that this is a manufacturers defect, and a big oversight in safety. I would gladly return this and accept a refund if you guys offered it to me.

Please let me know what has been done on Evolve's side to remedy this dangerous situation, and DO let me know why you guys chose bluetooth over a more robust 2.4 or even 5.8 GHZ.

My Review:
Ouch:

 

I have almost the same problem, and i have sent emails to Evolve asking them about 2.4 bluetooth and why they buffer commands on the remote. I got an answer from Evolve Australia saying "Thanks for the email and feedback. All will be taken on boards and passed on." , its a joke if you ask me.

My board is in Germany for repair, but i am thinking to get my money back and buy Boosted. At least on their forums there are no issues like this.

Edit : Actualy you just convinced me to get my money back.

 

Hard to believe this is still happening - first reported back last November... and fyi they are not using Bluetooth but are rolling their own with NRF24L01+ transceivers in the board and remote (current Bluetooth and BTLE protocols have frequency hopping and encryption built in) - doesn't appear as though Evolve has implemented similar in their remote radio design - their latest "safe mode" is a band aid for a more fundamental problem...

 

Here is the response from Evolve:

Hi Shaun,

We are sorry to hear about your recent issue that happened with your board, and so sorry to hear about your fall. Glad you are ok though.

Regarding any returns, unfortunately that is not something that we are able to accommodate as it is past the initial 7 day return period in our policy. In addition, at this time the board is also OUTSIDE the warranty period itself.

You may at any time review the warranty/return policy once again via the following link:
Store Policies and Terms of Service

What we can offer at this time is to have your board fully diagnosed and repaired for you in house. Normally according to our policy outside the warranty period there is a $75 labor fee, however we are willing to assist and waive the labor fee to help out in this for you. If an item is found to be faulty/defective, we can go ahead and replace that for you at no charge. However, as normal, if the faulty component found is due to misuse, abuse, or water damage, etc...then we will proceed in sending an invoice over to you for the cost of the component(s) needed for repair along with the shipping cost back to you.

Basically, we would like to go ahead and assist you by treating this as still within the warranty period. If any items are found defective and not misused or abused, we will waive the shipping back to you as well. You will only need to ship your board to us.

In situations like this, most commonly we notice that some our of riders do not correctly sync their remotes to their boards if needed and/or move the triggers before the board is completely synced to the remote. This can cause bad modulation and a delayed response. In turn, with a delayed braking response, this is when we would hear the motors lock up as braking comes unexpected (with a delay), especially since the boards are in no way programmed to apply braking and lock up in any circumstances. However in the event of an overheat, or shutdown...the board will free-roll with nothing more than the tension of the belts (this can feel as if a lockup occurred due to a sudden jolt if coming from GT mode to OFF however, but is merely a sudden switch to free-roll). The only other situation that can cause a lockup at all is simply a broken motor(s).

As you may know, we are The Evolve USA distributor and not the designer. However regarding the use of bluetooth technology that they have chosen, has proven very effective and we also enjoy riding our boards as well as racing them as we have recently in the Evolve World Cup. However no electronics are failsafe, and while technology is ever increasing, we find that the bluetooth connection we currently use has been good, and we will certainly continue to make improvements too as with any product.

Once again, we are sorry to hear your experience and let us know if you would like to send in your board to us so that we can make the necessary repairs. If so, we will email you an RA# to write on your package so that we can identify it when it arrives to our facility.

Kind regards,


Evolve Skateboards USA - Service/Tech Support

www.evolveskateboardsusa.com

 

There is no such thing as "wrong syncing", thats called "bugs" in software world. Remote shouldn't "buffer" or remember commands and then apply them after the sync is done, it should be a one way communication and just send the commands to the board, atleast for accelerating and braking. Two way communication should only happen for mode changing, so the board confirms its in GT mode. Telemetry is also one way communication.

I hope Evolve solves this problem and publicly addresses it, updates its controllers with more then "safe mode" band aid.

 

Also, what i think is that Evolve has some lazy programmers , i dont mean to offend anyone. I am saying that as a 20 years experience programmer. If i would to get a task and make a remote, i would at least ;

1. Make it updatable from miniUSB, because i want to get my new safer firmware updated to as many customers as soon as possible.
2. Would put miniUSB port on the board itself in case i need to upgrade firmware on the board too.
3. Make the remote T/R like Futaba, Spectrum, Turnigy or any other proven manufacturer out there that works on 2.4GHz and works great with 8-14 channels. For a skateboard you need 1 channel for acceleration/braking, another for modes, and a few more just for telemetry. I wouldnt even consider Bluetooth becuase if very prone to interference, maybe BT V4, but i am sure Evolve doesent use V4.
4. Implement acceleration/braking easing curves so people can choose how responsive their remote is.

my 2 cents

 

100% buffering of commands should not happen at all (for obvious reasons which have tossed a lot of us off our boards)

RC protocols ! - they have been around so long virtually all major bugs and problems (like we are still seeing with the Evolve remote) have been worked out - that would be something Evolve could move to and all the major players have two way communication now (to send stats and info back to the remote etc - telemetry)

EvolveUSA - nice they are willing to help - and I've had great service myself when getting my remote swapped - but they don't even know that their boards are not actually using Bluetooth (or want to admit it) - also I don't agree when they say the only other sudden stop is caused by a locked motor - many of us have seen this happen when the Queued up commands get acted on and the board software applies the brakes so hard you cannot stay on the board - (this should not happen at all - could be accommodated in firmware)

Firmware updates in the field - Yes! - whenever improvements and fixes are made we can all get them without having to send anything back

Customize acceleration and brake curves - some Boards already have this (the diy community and I think Jed Boards just rolling out now)

Disappointing that we have still not seen a complete redesign of the radio part of the remote at this stage when they keep rolling out new boards (with incremental improvements) - its like they are still in denial of the serious remote issues and may be afraid to make a major change with the remote as they would be admitting they have been wrong and not transparent on this all this time... (other board brands do not advertise safe mode for a reason - not needed - with a good radio design this happens so quickly, ie blue tooth channel hopping that the rider does not even notice).

 

My response to the RA:
OK guys...

I reject the notion that this was user error as I've been riding the board uneventfully since December.

I always wait until I achieve a positive communication with the remote before stepping on to the board.

I don't know of any situation where a loss of communication should result in a wheels locked response from the ESC...this is entirely TOO dangerous for anyone to be told to accept.

I've never ridden the skateboard through water, and at the time of the accident, I was riding on a dry street.

I appreciate the opportunity to send this back and have it looked into. However, if you find anything faulty that is deemed to be "caused by misuse or abuse", please do not replace and do not charge me, I am only looking to have a problem that is possibly inherent analyzed. I will say that I have been going through a lot of E-skate forums and have found that this is a problem that has been brought up time and again since November of last year, so it's something Evolve should definitely address.

Once returned, my current idea is to sell the skateboard, outside of some game-changing revision to the ESC and/or remote that would make this much safer. I can't risk a more damaging fall than I already have taken.

Please send me the RA. The board is boxed and ready to go!

 

Hey there Ozren...

Lived with the pain for a couple of months and finally had an MRI today. Broken Humerus Head and a Torn Superspinatus Tendon.
Did you sell your board?

 

Hi Ozren,

The board and remote use nRF24 is like BTLE, same frequency and stuff but it's different.
Commands do not get buffered on the remote, the remote uses only 1 retry as far as I know. I've decoded the entire protocol and can control my board and remote with an Arduino.
When you switch mode/gear it sends that command to the board until one of the ESC's respond with the different mode. So when your board can't talk to the controller the controller will keep trying until it sees the new status of the ESC. When you press a mode button twice the second mode change gets buffered and it will go directly after the 1st because the connection is back... (don't spam the left button ever! And always look at the display if the switch worked, else wait!!)

Your controller chooses a channel (out of 14) at boot and will not change! If you get in a area where the channel is busy you may notice the lag on the controller.

Looking at the protocol and how it addresses each other I recommend not riding near many other Evolve boards EVER! -- It would be smart for Evolve to show channel on the next remote so people who ride together can avoid using the same channel.

Also I'm not 100% sure but I think you can make anybody loose control by broadcasting a BIND command on all of the 14 channels used by Evolve. (aka don't try holding your left button while you or somebody close on the same channel is going 40KM/h)

Ps. They do need encryption because my Arduino UNO can find my connection in about a second and make the board do anything while my remote is kind off helpless. (Didn't try Reverse GT on the board yet but the remote is fine with that and makes for some funny pictures)


-- After hacking the protocol in 1 night I'm too scared to ride it... I'm going to replace the controller with a custom build, the nRF24 module on the board with small MCU emulating the nRF24 and make the connection secure, also I can use the MCU to control lights, I'd also love brake lights--

 

Stefan...one smart dude!

Explain to me a situation where the wheels would "lock up"? I put the board on the ground, powered it up, turned on the remote, waited for it to pair, got a positive id for 'ECO", stood on the board, kicked off slowly added throttle input, cruised for about 100 yards, and wham...wheels locked! I wasn't switching modes, I had a steady input of throttle...wheels locked...no other boards around me. Neighborhood street. I can't imagine a buffered protocol that would allow for full brakes to be applied if the controller lost communication with the board. You have to be able to anticipate braking and accelerating on these boards or YOU WILL FLY OFF! I sympathize with the designers with respect to losing communication in a braking scenario, especially if it was in a dire situation (such as at a traffic intersection)...but there are certainly more robust protocols in existence in other markets (again, such as RC aircraft).

 

I can explain it in C++..

if(Evolve.findNextBoard(true)){ // Does not keep track of all ID's, only last.
if(Evolve.setReversed(true)){ // Say hi..
if(Evolve.setThrottle(0)){ // Make it so..
printf("Board %s is a gonner..\n",Evolve.getConnectedID());
}
}
}

-- Works on my board and put's it in reversed no matter how fast you are going..
-- Could also send setThrottle(-500); -- Full brake makes a BANG when you have the remote throttle active!

With the V1 motor controller you could just blind broadcast the setThrottle(-500); on all channels, mine is V2 but it's damn easy to hijack the connection.. takes my Adruino UNO ~1 second to find the connection and crack the key using only 2 radio's, I have more but I'm too lazy to connect them and ~1 second is fast enough...

 

Currently only a couple of board command work in my library, I can fully emulate a board already and send commands like shown but I'm still testing stuff.
When I loose connection it will coast not brake, it sounds more like something used the same channel and pipe the packet started with 0x14 0x1b and you have a V1 motor controller.

I'll finish the controller part of the library and test some more.
Also my throttle is getting a bit twitchy, my minimum is now ~25 and to get it to 0 I need it press towards brake a bit.. If your remote is offset negative it could brake when you release the throttle. (still need to test the thresholds of the ESC's)

-----
Evolve Board Status;
Modus: GT - Last direction: Forward

ESC's;
ESC 0 : AMP 0.000, RPM 0, TEMP? 3151, TRIP-TOTAL 762, Brake 0, Power 0, Reverse 0
ESC 1 : AMP 0.000, RPM 0, TEMP? 3151, TRIP-TOTAL 859, Brake 0, Power 0, Reverse 1

Battery;
Cell 0: 4.079 Cell 1: 4.098 Cell 2: 4.037 Cell 3: 4.118 Cell 4: 4.083
Cell 5: 4.098 Cell 6: 4.084 Cell 7: 4.082 Cell 8: 4.088 Cell 9: 4.123
Volt: 40.89 - AMP: -0.04 [00] - Charges: 304


Sending throttle packet...
ESC 0 : AMP 0.000, RPM 0, TEMP 3149, TRIP 833, Brake 0, Power 0, Reverse 0
ESC 1 : AMP 0.000, RPM 0, TEMP 3149, TRIP 1071, Brake 0, Power 0, Reverse 1
Send:OK
ESC 1 : AMP 0.900, RPM 3238, TEMP 3148, TRIP 1305, Brake 0, Power 1, Reverse 1
ESC 0 : AMP 0.000, RPM 1817, TEMP 3148, TRIP 1200, Brake 0, Power 0, Reverse 0

Throttle packet;
14 1b SS SS 14 00 00 00 00 00 00 00 00 00 00 00 xx xx xx xx 00 00 00 00 00 00 00 00 00 00 00 00
SS = signed short speed
xx = Serial number given by the board while bonding.

With V2 ESC's throttle packets as far as I noticed only work when the Serial (See product ID in remote) matches your boards.

ps. About the retries; the SPI dump of both the board and controller say SETUP_RETR = 0x1A (10 retries / 250us waiting in between)
* Need to test the on-board ARM's RX buffer for overflows. (could be nasty if you are writing the packet buffer while reading the speed, you only need to rewrite 1 byte at the right time to go from 500 throttle to -500 throttle)
* Need to send all unknown opcodes (with and without ID) and note any reaction while throttle is up.. (could kill board or controller if they allow some sort of OTA updates) -- could some other command make the board lag or loose throttle?
Controller's USB data lines do not seem connected and neither are it's CPU's ISP wires but it does support IAP so maybe Evolve updates the controllers (and boards) wireless..

-- Also need to check if I could dump the firmware of the ARM on the board..

*edit: It's 10 retries at 250us each if it does not get an ACK, the bits are reversed / reading the datasheet helped.

 

Just noticed a packet on the Evolve channel and pipe that didn't come from the board or the remote.
It could be some BTLE packet where the CRC happens to match..
Maybe from my smartwatch, phone or headset or the television from a neighbor.

If the 1st byte happened to be 0x14 Evolve remote of board could pick that up as a command.

 

Meaning, this type of interference could potentially cause a communications malfunction?

 

Yes, it does for sure!
The V2 ESC does look at the ID so it should not throttle but is you get a battery packet with garbage the remote will put the board in ECO because it thinks there's a battery error. (there is NO ID in communication from board to remote, the remote is never sure if the packet is from the board or not...)
That is one instance I'm sure of could and will happen!

 

Stefan...when did Evolve introduce the v2 ESC?

 

Stefan when did the V2 motor controllers come out?

 

I don't know the exact date, you can figure out if you have V2 by testing your remote on V1, if the board responds to your remote on V1 modus your ESC is V1.

 

Did you fly off due to the motors going from full power to NO power.... or from full power to full BRAKE lock up?
I had my gen 2 carbon disconnect from full power to no power due to the remote losing comms..... it was not realy a violent event, just more of a surprise and inconvenience..... it eventually paired back up and I was rolling. I can deal with this type of fault.......

BUT if it went from full power to full brake.... that is another story. can you clarify?

Also BTW just discovered these e boards...... I'm hooked.... have a gen 2 carbon AT, GTX AT, GTX street, and a baja board on order.... w/ jan delivery...... I'm 49 yrs old..... skater from the 80's..... reliving the dream