Hi,

I'm a rising freshman at Case Western University, and I would like to make an an electronic scooter to get around campus before I move in in about two months (mid august 2023).

I already have a lot of the parts I would need for the project, like motors and motor controllers, among other things. Aside from a well functioning and customized escooter, I would also like to expand my engineering skills with this project. I would like to improve my PCB design, power electronics, and general EE skills. I also would like to learn about steering mechanics.

There are a few specific features that I really could use some help deciding on a circuit for, or use some guidance on. I would like to use an ESP32 for the brains of this escooter, although I would be open to suggestions of other microcontrollers.


1. Telemetry. I would like to measure battery voltage, battery current consumption, motor current consumption, duration, user inputs, and motor control outputs.

a. For each trip, from when it is turned on to when it is next turned off, I would like to record a csv file with each entry representing these measurements at a point in time. I would like to just sample all of these things at a rate of 20hz, and have the file saved to an SD card. I could use some recommendations for how to best interface between an SD card and ESP32.

b. For measuring battery voltage, a simple resistor voltage divider to the ADC of the ESP32 should be reliable and accurate, right? Or would something else be better, like possibly adding a capacitor to smooth out the signal or something?

c. For motor and battery current consumption, I would like to use a low resistance current shunt. How could I reliably amplify/read this low voltage signal so that I can read it from the ESP32? Is there an IC that you would recommend for this? And is there another method of measuring current that would be preferable here?

d. I could also use some recommendations for date/time modules that will reliably keep going even after it's been powered off for a while.

e. is there a cheap temperature sensing IC so that I can make sure the internal electronics aren't getting to toasty?

f. is there a relatively cheap IMU (under $10) people can recommend?


2. Electronic breaking. I would like to have electronic breaking instead of mechanical breaks, but I am not sure the best way to do this. Regenerative breaking seems like a lot of effort for not a lot of extra battery life, but I still want electronic breaking. What would people recommend for a circuit to do this? Would just a mosfet with a heat sink and low value resistor across the motors (brushed DC motors) work well? Or could I just reverse the motor direction at a lower power to get a breaking effect?

3. Battery protection circuit. I have a high current latching relay on hand. To properly protect the lipo, does a series fuse and latching relay that shuts off when undervoltage is detected sound good? Or would you recommend a solid state circuit, for overcurrent and undervoltage protection here?

4. Satisfying switches. If anyone has recommendations for knobs, buttons, or paddle switches that are both satisfying and durable, while relatively inexpensive, please let me know.

5. PCB design. With everyone's recommendations for different parts, and my own research, I would like to design a PCB to do all this and interface with all the scooter components not on the PCB. When I get to this point, I would greatly appreciate feedback before I actually order the PCB made because I am new to PCB design and I don't want to waste money because of a dumb mistake.

I know I'm asking for help on a lot of different things, so useful suggestions for anything will be greatly appreciated. Thank you,

Simon

 

Wouldn't adapting a E-bike kit of parts more expedient?

 

Wouldn't adapting a E-bike kit of parts more expedient?

I do not want to do that because I will not learn as much, and I already have the motors and motor drivers on hand, as well as several other parts.

 

Hi Simon,

I do most of this for my wheelchairs and currently its all on protoboards but I was just starting to move it to a PCB.


1a SDCard - standard off the shelf module on ESP32 HSPI bus

1b battery volts and current - 28.8v/100A - INA219 or similar with a 50 or 100A shunt - much simpler than doing your own signal conditioning.
BTW, ESP32 ADC not accurate, I use external one, eg ADS1115 4-chan 16bit when needed Currently using DG308 to switch INA219 VBUS input across each battery node. Have also used dedicated TI 10-cell battery management chip but was suspect reliability due to poor PCB layout - will revisit that one day.

1c Motor current/direction I get off the controller CANBus but an INA219/shunt combo might work though the PWM might affect how the INA219 works. A hall sensor (ACS712 or similar) works well with an integrator on the output to give an average reading.

1d I use ESP32 internal RTC + NTP over wifi - RTC is always running even in deep sleep and can be supported with coin cell if you want to power down main processor.

1e DS18B20 one-wire modules, several on one GPIO port

1f I use MPU6050 (6dof) as relatively cheap @ $7. The ageing but still good BNO055 9dof is around $15

2 Can't help here as wheelchair controller does regenerative braking. A good motor controller should also do so...

3 Last thing you need is battery protection cutting in as you accelerate to avoid an idiot driver. Better to monitor battery volts... and just audibly warn user when below a set level.

4 Not my thing..

5 Feel free to ask...

Happy to discuss all above

 

Achieving all of the requirements listed in post #1 would be a very impressive engineering accomplishment that a small team of good engineers could pull-off in a month or two.

 

Congratulations on your move to university. I wish you the best of luck in your pursuit of your degree.

As far as your scooter project, I have some questions:

Your requirements list has some very specific items on it, e.g.:

ESP32, which is not one thing but is a class of things
CSV file
SD Card
(&c)

How did you come up with these things. It seems that your list is a mix of levels of abstraction which could easily lead to replacing a solution to your actual problem with a solution to your solution because the specification was not actually suitable.

This is a very common error, even for very experienced designers. There is nothing inherently wrong with your specifications, but by fixing certain things you force the project to pivot around them which may prove to be impossible while simultaneously solving the original problem (i.e.: transportation and project for learning electronics and design).

So, I encourage you to back up and start with a specification that is completely free of implementation details to start. Design goals are appropriate, so something like “incorporate electrical braking” is good, but “eliminate mechanical braking” would not be since you could easily turn this into a failed attempt to make something safe that doesn’t have a mechanical brake when avoiding mechanical brakes is not the same as, nor required for, effective and substantial electrical braking to be added.

Similarly ”use MCU-based control“ is not the same as “use an ESP32”, is the latter actually a requirement? It could be, but there would have to be some reason that is more important than other aspects of the project to specify it.

Concerning your instrumentation and logging (not telemetry, which is tele- (at a distance) -metry (measurement) something like “record parameters and signals that will allow analysis of scooter performance and usage” allows you to make the latter part a separate requirement (that is, what do you need to allow the analysis?). And, as an aside, maybe to do want telemetry, which would be one reason an ESP32 might be selected. If telemetry is a requirement then choosing an MCU that has wireless peripherals built-in makes sense.

Separately:

1 a,b: discussed above

1 c: ESP32 ADC are notoriously bad. External ADCs are usually used if accurate and low noise results are required. As far as battery state information is concerned, consider a coulomb counter. The SoC (State of Charge) of a lithium battery is not possible to know without actually monitoring the power in and out. There are many options available, but you might find that a BMS (which you will need) provides the information you want.

2: If you aren’t going to use regenerative braking, resistance breaking is the right option. You will need to carefully calculate the heating of the resistors because you might need active cooling (e.g.: a fan) to keep the resistor(s) from degrading or burning up over time. Resistive breaking it very effective, in fact it is used as the principle braking for diesel-electric locomotives but for safety and other reasons you must include mechanical braking as well.

You could do something clever where the braking is managed by the MCU applying the resistive braking first and the mechanical brake for the last deceleration and holding. But even in that case, you must have a completely mechanical brake lever for emergency stops.

3: I strongly recommend that you purchase a commercially produced BMS and battery pack. Not only is the complexity of just this one part of your project very high, it is a critical safety component. When a mistake can lead to a hard to extinguish and very hot fire, it’s best to leave that to experts.

4: There are two sources that come to mind for switches. First, look at switches designed for arcade games. They are designed to be rugged and cheap. They have a retro look and are colorful. They are readily available. They are not weather resistant, though.

Check out switches designed for motorcycle handlebar mounting. These are weather resistant. Check AliXpress for a big selection. You will also find bar-end throttles which might be nice. Also, check electric skateboard controllers, there are wireless ones which might be one way to go for you.

One thing you mentioned in passing concerns steering. If you aren’t already familiar with the concept of ”trail” in bicycle steering, read up on it. Trail is a critical factor in the natural stability of a two-wheeled vehicle with front wheel steering and will make the difference between stable and twitchy, ability to ride hands free safely vs. maneuverability, etc.

 

@Yaakov makes some valid points, however I would recommend you don't use LiPo batteries but go for LiFePO4 which are near indestructible and have no thermal run-away issues. A BMS is less useful with LiFePO4. Depending on the size of your battery pack the balancing/charging aspects are best handled by an off-scooter charger so no BMS needed from that side of things. On the discharge side, your motor controller should current-limit the motor and handle soft-start so over-current protection is not needed - an inline fuse to guard against shorts upstream of the controller is useful but non-essential. Over-discharge protection is best left to the user as stated before. If you're monitoring current in and current out, "coulomb counting", you'll know exactly when you hit 10% SoC or whatever limit you prefer, and LiFePO4 is much more forgiving of over-discharge.

There are many suitable MCU but the ESP32 is as good as any - ADC issues aside. I have some latest VROOM-S3 modules here but not yet tested them to see if the ADC issue is resolved. I use ESP32 Bluetooth to transmit cell voltages, overall battery voltage, estimated SoC (based on current in/out), instant battery current and a few other parameters to a smartphone app for real-time monitoring.

 

A couple of clarifications:

My suggestion of a LiPo pack is due to availability and power density. I agree that LiFePO4 has a lot of advantages, but I haven’t seen a scooter that uses them. I believe this is because of that power density requirement for such a small vehicle.

The second thing is the on-board BMS. As this is intended to be transportation on a university campus, I am foreseeing a need to charge in place, possibly in a classroom or other location on campus. Carrying around a separate charger seems wrong for that. Using something like Type-C would be very handy.

Concerning the ESP32: I have nothing against it, it could be a great choice. My concern was one of design principles. If the ESP32 becomes a fixed point, the project pivots around it. I was not at all clear there was enough known to make it a fixed point, and I have been bitten by my own premature specifications before.

I think the ESP32 can be argued for, very convincingly, in a wide range of requirements. Of course, if someone has tools and knowledge concerning the ESP32 it weighs very heavily in favor of it—but even if not, as you point out it encompasses a very big range of configurations so if it is a fixed point it probably can be accommodated with little compromise. Even the ADC is easily worked around if needed.

The wireless peripherals make actual telemetry easy and you can choose your flavor of radio from quite a list. I have a couple of ESP32-H2-DevKitM-1 boards (they seem to have become unobtainium, but they were engineering samples so maybe it just means the production ones are near). It features the ESP-32-H2-MINI module that has IEEE 802.15.4 for Zigbee and Thread, as well has BLE with BT 5 and BT Mesh with 128 KB SRAM, 320 KB ROM, 4 KB LP Memory, 2/4 MB Flash 19 GPIOs, 3x SPI, 2x UART, 2x I2C, 1x I2S, RMT, LEDPWM, MCPWM, PCNT, TWAI, USB Serial/JTAG, GDMA, ETM, PARLIO, SAR ADC, Temp Sensor, and Timers.

Focused on IoT type applications but those radio options are very flexible for any sort of connected device.

 

"Y" mentioned "trail" relative to handling, and the whole steering geometry is very important indeed. it makes the difference between a bike that is almost self driving and one that is a full-time job just to keep upright. And rather than attempt to design a good arrangement it is safer to accurately copy the geometry of one that rides well and is quite stable.

One other thing is that in most programs at most good universities and colleges, you will not have much free time with a heavier class load. The quarter that I had six three credit-hour courses was incredibly busy.

 

My suggestion of a LiPo pack is due to availability and power density. I agree that LiFePO4 has a lot of advantages, but I haven’t seen a scooter that uses them. I believe this is because of that power density requirement for such a small vehicle.

I'm not 'au fait' with electric scooters but the reports of them bursting into flames means I would never build a bike/scooter with LiPo.

Some thoughts:
LiPo has approx 30-40% better energy density than LiFePO4, but LiPo can only be discharged to 20% if you want them to have a useful lifespan v LiFePO4 can be discharged to 100% without significant impact, therefore there's not really much to chose between them, though I accept they are bulkier by 35% (about 200cc for 8.5A) and heavier by around 50%, (about 300g for 8.5Ah). A 4S LiFePO4 pack gives 12.8v v a 3S LiPo at 11.1v which is another minor benefit.
LiFePO4 have a much flatter discharge curve so hold power output more constant during discharge.
LiPo have a life of around 300-500 charge cycles if not deep discharged v 3000+ for LiFePO4, and LiFePO4 can be charged faster without worrying about temperature, So though upfront cost is higher, TCO is about 50% over a 5y+ period.

The second thing is the on-board BMS. As this is intended to be transportation on a university campus, I am foreseeing a need to charge in place, possibly in a classroom or other location on campus. Carrying around a separate charger seems wrong for that. Using something like Type-C would be very handy.

The BMS is not a charger - it may handle over-charge and over-discharge cut off and provide cell balancing but it still relies on an external supply to manage the constant current/CV process - that's where the bulk & weight come in. For better handling you want that offboard. And since the BMS does nothing useful on the discharge side why have it onboard in the first place?

The wireless peripherals make actual telemetry easy and you can choose your flavor of radio from quite a list. I have a couple of ESP32-H2-DevKitM-1 boards (they seem to have become unobtainium, but they were engineering samples so maybe it just means the production ones are near). It features the ESP-32-H2-MINI module that has IEEE 802.15.4 for Zigbee and Thread, as well has BLE with BT 5 and BT Mesh with 128 KB SRAM, 320 KB ROM, 4 KB LP Memory, 2/4 MB Flash 19 GPIOs, 3x SPI, 2x UART, 2x I2C, 1x I2S, RMT, LEDPWM, MCPWM, PCNT, TWAI, USB Serial/JTAG, GDMA, ETM, PARLIO, SAR ADC, Temp Sensor, and Timers.

Focused on IoT type applications but those radio options are very flexible for any sort of connected device.

The ESP32 radio is very versatile and the rest is just software configuration and protocol code modules. By default it comes with BT, BLE and WiFi licence free and I think Zigbee is a licensable add on. I use the VROOM modules with 16M of ROM and 4M of RAM iirc

 

LiPo has approx 30-40% better energy density than LiFePO4, but LiPo can only be discharged to 20% if you want them to have a useful lifespan v LiFePO4 can be discharged to 100% without significant impact, therefore there's not really much to chose between them, though I accept they are bulkier by 35% (about 200cc for 8.5A) and heavier by around 50%, (about 300g for 8.5Ah). A 4S LiFePO4 pack gives 12.8v v a 3S LiPo at 11.1v which is another minor benefit.
LiFePO4 have a much flatter discharge curve so hold power output more constant during discharge.
LiPo have a life of around 300-500 charge cycles if not deep discharged v 3000+ for LiFePO4, and LiFePO4 can be charged faster without worrying about temperature, So though upfront cost is higher, TCO is about 50% over a 5y+ period.

All true and compelling, but given the ready availability of plug and play LiPo solutions, for a project like this, I think I lean heavily in that direction. However, the safety issues are not to be ignored and must be properly considered as part of the decision.

I’ll suggest this: if the safety cost is too high for the LiPO benefits, another readily available option is NiMH. Many RC models use large NiMH batteries, unfortunately PD is even lower than LiFePO4. You can get 7.2V@10Ah for about 80 bucks and of course BMS and charger systems are readily available.

On the other hand, I did see this, and this, and they do look potentially very nice. I still advocate for USB Type-C PD for the power supply.

The BMS is not a charger - it may handle over-charge and over-discharge cut off and provide cell balancing but it still relies on an external supply to manage the constant current/CV process - that's where the bulk & weight come in. For better handling you want that offboard. And since the BMS does nothing useful on the discharge side why have it onboard in the first place?

Yes, it is a part of the charging (and discharging) system. However, using a USB Type-C PD charger of the larger variety, it is very possible to have most of the brains in the scooter and be able to use any readily available

The ESP32 radio is very versatile and the rest is just software configuration and protocol code modules. By default it comes with BT, BLE and WiFi licence free and I think Zigbee is a licensable add on. I use the VROOM modules with 16M of ROM and 4M of RAM iirc

Yes, I have quite a variety of ESP32 boards, this one, though, has a focus on IoT which means the Zigbee/Thread stuff and full BLE, which is very cool.

 

On the other hand, I did see this, and this, and they do look potentially very nice. I still advocate for USB Type-C PD for the power supply.

IMHO, an expensive way to do it badly - fine if you *have* to replace an existing SLA battery, but a poor form-factor if you're DIYing and can fit cells within your own casing. Also, at least on of those is limited to 10A out.

Yes, it is a part of the charging (and discharging) system. However, using a USB Type-C PD charger of the larger variety, it is very possible to have most of the brains in the scooter and be able to use any readily available

Current USB-C limited to 5A @ 20v = 100W and isn't a bad match for a 12 (4S) or 18v (5S) system. The new USB PD2.1 spec of 240W gives 50v @ 5A and would be a good match for 36 (10S), 44 (12S) and possibly 48v (14S with boost) systems. But a standard USB PSU still won't have the CC/CV management most basic BMS require.

 

Hi all,

I had multiple longer responses planned out to reply to various points, however AAC did not seem to save those responses. Thank you very much everyone for your experience and input about power sensing, breaking system design, battery charging/discharging, and other topics. I think I may revisit this in the future, and I did learn some things.

I actually had a lipo fire recently due to mechanical battery damage, and thankfully no one was hurt and insurance covered the damages. However, it was very disruptive and could've been much worse, so I am a bit more apprehensive about this escooter project, and I will be putting it on hold for some time.

Best,

Simon