1. Description

I built an electric skateboard, using a Li-ion battery pack I made. And created a portable remote controller that can display real time speed data, using custom PCB I designed, RF-chip, and a customized open-source code.

2. Where it all began

Casey Neistat

As a high-school student back in 2016, watching Casey Neistat’s vlog like every other day, I couldn’t help but notice the ‘Boosted Board’ he owned. It was quick, portable, powerful. Just the kind of transportation I needed (especially since I didn’t even have a driver’s license). So I always had this thought in the back of my head, of buying / building an electric skateboard someday.

Great Scott! – Youtube Channel

Then, sometime during my freshman year(2016), I came across this video by ‘Great Scott!'(An electronics focused YouTube channel, that occasionally posts DIY projects like this). After watching the video, I was hooked. I decided that I was going to build it.

3. The Board (January 2017)

I basically followed the exact same step the video above took. Start with plywood, stack them, glue them, cut them, and attach some trucks. Which, I did.

But after building, riding around with it a bit, I quickly fell into that routine. I somehow forgot about the ‘electric propulsion’ part. Sometimes things like that happen 😛

And since the school started again, I couldn’t really focus on this project, so the time passed.

4. Electric conversion (January 2018)

After spending a summer vacation making a 5 meter wingspan solar airplane, I finally got back to this project exactly 1 year later in 2018.

Now, I had two choices. Either make my own motor mount / drive-system like the video did, or buy parts from a vendor. Being a hard-core maker, I definitely wanted to make the whole thing myself. But critically, I didn’t have a CNC machine to cut the motor brackets, nor prior experience in belt drive system. To minimize the chance of totally failing, I went with the second option.

4-1. VESC (open source motor controller) : Link.

It was pretty intuitive to set up the whole thing. So mechanical things aside, I was left with this mysterious open-source motor controller called “VESC”.

VESC is an open source HW/SW project, that was pretty popular in the electric-skateboard community. People who wanted to customize their motor control(current / duty-cycle / regenerative braking, etc.) beyond typical boat/RC ESC(Electronic Speed Controller) usually went for VESC. As a user, I can confirm that it’s a good HW/SW.

So I tweaked some parameters and tried out various features of VESC. Then, I knew that there was a potential to add some amazing features using the VESC.

4-2. Electrical System overview (Version 1)

This was basically a proof of working- prototype. It consisted of :

Lithium Polymer battery (not powerful enough, but for testing)

(not powerful enough, but for testing) VESC (for tweaking the settings, USB line is connected, as visible above.

(for tweaking the settings, USB line is connected, as visible above. Motor (Diameter 63mm, Height 55mm) / Truck & mounting system.

(Diameter 63mm, Height 55mm) / & system. RC-receiver. I used the transmitter I use on drones, for this 😛

Oh, and after indoor trials, I slapped on a waterproof container, loaded it with 2 Lipos and VESC, then tested the system outside. As calculated, top speed was at around 35 km/h.

+) Some cool pics I took while riding it.

4-3. Li-ion Battery pack & Carbon Enclosure (Version 2)

Battery pack

So after feeling the upper limits of the Lipo batteries, I built a custom Li-ion battery pack, weighing at about 2.5 kg, with a whopping 585[Wh] capacity.

Detailed blog post on how I made the battery pack can be found at : Making Li-ion Battery Pack (6S8P).

The battery pack was pretty huge, so I needed a case for it.

Carbon Fiber battery enclosure

So I hand-crafted Carbon Fiber and Glass Fiber with Epoxy, to create a custom Carbon enclosure 🙂

Detailed blog post on how I made CFRP Enclosure : Making CFRP Battery Enclosure

The performance was much, much better. I took it out for a 20 km ride, and no problem, torque was great too.

The difference in total energy available / performance degradation was quite surprising. Since theoretically, the new battery pack could give a range around 50 km(You read it right, ha ha), it just didn’t lose torque like LiPo batteries did in the Version 1.

Now, remember the ‘potential use case’ of VESC I discussed above? Here it comes.

5. Portable Remote Controller! (using capability of VESC, 2018 – Summer)

I briefly mentioned above that I used ‘Rc-receiver / transmitter’ for controlling the skateboard. That was because I didn’t have a better alternative. And every second I was riding on it, I wished that there would be a more portable / lighter remote I could carry.

5-1. Firefly open source remote (Link)

While looking through electric-skateboard forum, I couldn’t help but notice that remote. Exactly what I wanted, both in portability and ease-of-use!

But, I didn’t wanna just copy that. So I gave it some improvements :

5-2. Custom PCB design & fabrication for Tx & Rx

So as you can see in the photo above, the remote itself has a lot of wires hanging around. I didn’t like that. I wanted to try a more modular approach. Let PCB take care of all the complex / trivial wirings (especially the SPI connection with Radio Communication Chip, 6 lines!), and focus on it’s compact-ness.

So for the first time, I designed & fabricated a custom PCB.

Bit more detailed blog on this PCB design : nRF24_esk8_Remote PCB design v1

I used EasyEDA for designing & fabrication. It was challenging, but also rewarding!

The first 2 in the photo above are front / back side of the ‘Transmitter‘, which is about the size that can be comfortably grasped with one hand. And the last two are from ‘Receiver‘.

You can see that both of them have a RF-chip pin-out (with text ‘MK1’). Which played the vital part of this remote.

5-3. Customizing code for TX / RX

Both TX and RX use a ‘Arduino Nano’ board, which I’m familiar with. And so I read the code for the remote and came up with some optimization/customization Ideas.

Receiver code refactoring

Starting with the Receiver, it is important to note that it is responsible for communicating with VESC via ‘Serial’, to get RPM / Battery Voltage, etc. in real-time.

And with the original project’s code, it used ‘Hardware Serial’ to communicate with the VESC(motor controller).

For the detailed reasons as to why I thought using a Hardware Serial port would be a problem, refer to ‘Appendix 1’.

So, I modified the code to use ‘Software Serial’ for VESC communication.

This was challenging because unlike Hardware Serial, this is purely done via software, no registers, no hardware buffers. So for sending commands, I had to implement a loop to send each byte sequentially. Which took a lot of processing time. So that’s an area I can try to improve in the future.

I also created my own Timer2 based Servo library that can simultaneously control 10 servos(PWM output). -> More in ‘Appendix 2’.

You can find my Timer2 Servo library at: Here.

Transmitter Code refactoring

Transmitter code was a mess! So right off the bat, I fixed these problems :

Moved all the RAM-wasting LCD display data into Program Memory

I created a PR for this actually, and was accepted by the original developer of Firefly remote(PR_Link). With this, I saved 144 bytes of RAM, which is about 7[%] of total SRAM inside the Atmega328 Chip.

Removed the ‘fixed’ hall sensor(throttle) calibration value, and represented throttle in [-1, 1] floating-point value.

In the original transmitter code, the ‘hall sensor’ threshold/margins were fixed. But this can be a problem because everyone’s hall sensor and magnets are different.

const uint8_t hallNoiseMargin = 10; const uint8_t hallMenuMargin = 100;

To improve this code, I added a support for representing throttle as a floating point value in the range : [-1, 1]. Since the hard-coded margin is now gone, the throttle value gets better represented.

This was partly inspired by one PR back in 2017, in open-source flight control software ‘iNAV’, with the exact same issue as above. Legacy constants vs floating points.

Added checksum-based RF communication verification

I personally thought that this was the most important thing I’ve implemented in the remote project. Because when human is on board, mistakes should be absolutely minimized. Not just because I was riding it, but also because without this safeguard, someone else can get hurt.

So the logic wasn’t that complicated, I added an extra int16_t type crc value in the RF communication packet. It was checked at both Transmitter and Receiver.

5-4. So the Receiver and Transmitter was Complete!

The transmitter design was elongated to have PCB sit flush inside.

6. The End result (ver.2)

In the end, I made an electric skateboard with a 50km range, a custom battery pack, and a remote that gave me live speed and battery voltage data!

It was really fun to make, and I can’t wait to make Version 3, with advanced carbon-fiber deck and more organized electronics. As well as a smaller battery (because it was too heavy!). Below is a video I took onboard Version 2, paired with an RC-remote.

Acceleration is great! Top Speed is just enough to race against the cars beside 🙂

Appendix 1.

However, I thought of that as a problem because :

When uploading a sketch to Arduino Nano, it is done via Hardware Serial. Especially, it also uses ‘ tx ‘(Arduino->Computer), since it is connected to VESC’s ‘ rx ‘. And since VESC’s rx receives it’s own message protocols, I reasoned that there could be potential interference (ex. VESC acknowledging an unwanted / faulty command) between VESC and the Arduino .

Especially, it also uses ‘ ‘(Arduino->Computer), since it is connected to VESC’s ‘ ‘. And since VESC’s rx receives it’s own message protocols, (ex. VESC acknowledging an unwanted / faulty command) . The hardware serial port could be utilized for a bluetooth / data-logging purposes. Which requires much higher bandwidth compared to the VESC communication. So using the Software Serial for VESC communication opens up possible future use cases.

And with the original project’s code, it used ‘Hardware Serial’ to communicate with the VESC(motor controller).

Appendix 2.

I created my own Timer2 based Servo library that can simultaneously control 10 servos(PWM output).

The reason I created it was because while building the Receiver, I found out that VESC wasn’t reading the PWM signals correctly (ex. Oscilloscope confirms pulse width of 1500 us, but VESC reads it as 1700us, etc.).

Having suspicion about the reliability of Arduino’s Servo library, I basically built a Servo library from the ground up, mostly relying on Timer2 Overflow & Compare-match Interrupts.

But, still no luck. I reported this symptom to the electric skateboards forum, but still nobody found out exactly why that was happening. This is definitely a good bug-hunting opportunity for VESC developers, but I couldn’t figure out why 😦