Open-source EUC motherboard

[h3X]

I already have an arduino, but not an stm32 dev board. Do I also need an mpu6050? What is the black board in the upper left? I'd love to help out with anything during the summer, after my exams are done!

[Inductores]

11 minutes ago, h3X said:

I already have an arduino, but not an stm32 dev board. Do I also need an mpu6050? What is the black board in the upper left? I'd love to help out with anything during the summer, after my exams are done!

You can get a cheap STM32 board like this (I would get two, just in case...):

https://www.aliexpress.com/item/Free-Shipping-STM32F103C8T6-ARM-STM32-Minimum-System-Development-Board-Module-Forarduino/32525208361.html

Also the STM32 programmer:

https://www.aliexpress.com/item/Free-shipping-Smart-Electronics-ST-LINK-Stlink-ST-Link-V2-Mini-STM8-STM32-Simulator-Download-Programmer/32756146997.html

The black board in the upper left is just a breadboard "power supply" to get +3V3 and +5V without using the Arduino voltage regulator:

https://www.aliexpress.com/item/Free-Shipping-MB102-Breadboard-Power-Supply-Module-3-3V-5V-MB-102-Solderless-Bread-Board-DIY/32523783614.html

I'm using a MPU6050 module, but it could be upgraded to a newer one, right now is "obsolete" by the manufacturer. Anyway:

https://www.aliexpress.com/item/GY-521-MPU-6050-MPU6050-Module-3-Axis-analog-gyro-sensors-3-Axis-Accelerometer-Module/32246225983.html

And you also need a Bluetooth module. The one I'm using is this one:

https://www.aliexpress.com/item/WAVGAT-AT-09-4-0-Bluetooth-module-for-ble-with-backplane-serial-BLE-CC2540-CC2541-Serial/32826166129.html

But the original board from Rockwheel is this one:

https://www.aliexpress.com/item/Keyestudio-HC-08-Bluetooth-Master-Slave-Module-Transceiver-for-Arduino-Compatible-with-iOS-and-Android/32907441181.html

I guess this is enough to start with the development

Edited April 5, 2019 by Inductores

[h3X]

I probably don't need the Rockwheel BTLE module if I have the other one?

Edited April 5, 2019 by h3X

[pst]

Unfortunately "real life" has been intruding again for me, but glad to see the discussion in the last couple weeks.

Just to mention it one last(?) time: It will be hard to make "an open source EUC motherboard" if some people are working on design #1, others design #2, others design #3,... some using one toolchain, others another, etc.  Prototyping ideas is great, but unless people work on a common design there will be a lot of duplicated effort.

A compromise might be that the "common design" is really a family of building blocks which can be put together by a potential builder... but again that's back to really documenting things thoroughly; what goes on algorithmically and functionally inside each block, and what gets transferred from one block to another.  This way some people could design it with an Arduino, others with NXP, others with TI... some with a commercial ESC and others with a self-built ESC which may have some additional features.  Of course this approach is not as efficient as agreeing on only one formula.

I feel like I am dwelling on the "un-fun" part of planning, and that isn't my intent... but I am worried that without it that there will not really be a coordinated effort, just a lot of parallel ideas.  Especially if multiple people want to be involved in coding, then people will need to invest some learning in a new IDE and possibly even money in debug equipment/etc., so again, best to do this only once.

 

[h3X]

It's a good point, pst. It would be best if we end up with a collection of black box devices that are interchangeable. That being said, the coding is being done on STM32 for now.

[Phunny]

Hope this means shared motion control code from quadcopters.

Do we pick standards now, or wait for next year's model?

If we follow the black box idea, what might be the best way for these boxes to communicate? What information do they actually need? Would, for instance, a 0-5 volt throttle be enough? Why might a motor controller need to return data to mcu?

[Chriull]

10 minutes ago, Phunny said:

Why might a motor controller need to return data to mcu?

EUCs have a thermal problem. The motor controller had to be saved from overheating and from to high currents at low speeds. The mcu should know this values to prematurely "stop this conditions" to give the rider a chance to dismount safely.

Either the mcu measures this values itself or gets them reported by the motor controller.

[h3X]

If the motor is sensored it can report rotational offsets that may be helpful to a control processor?

 

I'm thinking that we should use an established protocol for communication unless we only need very basic signals. CAN bus comes to mind as it's already a standard between sensors and controllers in cars and many other applications, and is flexible towards software based expansion.

[esaj]

2 hours ago, h3X said:

If the motor is sensored it can report rotational offsets that may be helpful to a control processor?

The typical hall-sensor setup has only three sensors, so it can't tell the exact "rotational" position of the wheel. 

Typical EUC motor has a lot more of coils and magnets than the above picture (I think closer to 60 coils on many?)

There are sensorless algorithms for driving BLDC-motors, but I don't know much anything about them.

 

Quote

I'm thinking that we should use an established protocol for communication unless we only need very basic signals. CAN bus comes to mind as it's already a standard between sensors and controllers in cars and many other applications, and is flexible towards software based expansion.

CAN is a good candidate, as the differential signal + twisted pair cable makes it more immune to environment noise (like the motor) and it has CRC for recognizing faulty frames (or at least most of them), but I do see a bunch of downsides:

If the IMU doesn't support CAN out-of-the-box, it becomes more complicated, as there needs to be something in-between to read the data from the IMU (over I2C or SPI or whatever the IMU uses), and then transmit the data over CAN. It would also add delay (read data, pack it into CAN-frames / ISO-TP or whatever, transmit to bus), which may or may not become a problem with stability.

CAN speeds are something like between 100kbit to 1Mbit/s, which isn't bad, but I don't know whether it's for actual payload or for the entire frames. Bit-stuffing and long identifiers (29-bit) can add a lot of overhead, so transmitting 8 byte (64 bits, I think it's the frame maximum) of payload data may require using a lot more bits. Whether that's an issue depends on how much data needs to be transmitted around and how much delay the entire system can withstand.

Single CAN frame with short identifiers (11 bits), 8 data bits (1 byte of payload) and without bit-stuffing pictured.

 

Many STM32's have what I think is called "CANBUS," but do note that you can't just plug it directly into an actual CAN-bus, but need a CAN transceiver -chip in-between. Not that it's very expensive, I think I've seen CAN transceivers costing around 1€ per piece when buying <10 pieces.

Edited April 9, 2019 by esaj

[h3X]

18 hours ago, esaj said:

There are sensorless algorithms for driving BLDC-motors, but I don't know much anything about them. 

In my own experience, the sensorless algorithms are generally less efficient (and a lot more noisy!) and we should definitely use FOC. Matlab's YouTube channel has a decent introduction to its requirements. I suppose the motor driver is the only board that needs Hall sensor data from the motor. Should there be a rotary encoder or another way to sense the wheel angle or does the IMU provide all the needed data?

Regarding CAN, I see the problem with data overhead and lag, and that is definitely something you'd want to avoid in a time critical task like balancing the EUC!

[esaj]

6 hours ago, h3X said:

In my own experience, the sensorless algorithms are generally less efficient (and a lot more noisy!) and we should definitely use FOC. Matlab's YouTube channel has a decent introduction to its requirements. I suppose the motor driver is the only board that needs Hall sensor data from the motor. Should there be a rotary encoder or another way to sense the wheel angle or does the IMU provide all the needed data?

I've never seen rotary encoders used in commercial wheels. The balancing doesn't need to know the position of the motor, very much simplified, it just takes a stream of angle readings (with filtering) to PID (or PD)-control, which then outputs values for motor control, which could be interpreted either as wanted speed or torque (or change thereof). I don't see where the motor position would come into play, it's all about the angle of the pedals to keep the "inverted pendulum" upright.

In a "normal" commercial wheel, the motor is "free" to turn by itself, the rider stands on the pedals that are fixed to the axle (around which the motor turns) and the shell, and the mainboard is fixed to the shell, so the IMU is reporting the angle / rotational speed of the pedals (or everything else than the motor, if you will). Motor position doesn't matter. Also explains why things get "jittery" if the shell or the mainboard is loose

 

Quote

Regarding CAN, I see the problem with data overhead and lag, and that is definitely something you'd want to avoid in a time critical task like balancing the EUC!

CAN could be overkill anyway, unless the modules like the MCU, IMU, motor controller, possibly BMS(s) are further away from each other and need longer wiring. And even if they are, and differential or current signaling is needed to overcome ambient noise, the underlying protocol could still be something simpler than CAN.

I doubt there's any sound reason for moving the IMU away from the "brains" (the MCU), so likely no separate protocol is needed for the IMU data than what the chip itself uses. Separate motor controller could be possibly useful, as it's usually the half-bridge mosfets that get (self-)destroyed, so then it would only be necessary to replace the motor controller (or mosfets). With good application protocol selection/design, it would also make it possible to use different motor controllers, as long as they understand the protocol. Basically, if using modular design, I'd suggest that the motor controller has its own MCU, which "talks" with the MCU handling the IMU-data and PID-loop, and implements the motor control algorithm (like FOC) within itself.

Edited April 10, 2019 by esaj

[pst]

Catching up again.  I agree CAN is overkill (and for the curious, they spec the data rate of the bus, not the data rate of the payload).  The MPU-6050 supports I2C which is extremely common, and I would be a bit surprised if other gyros/etc. would not support it.  I think most "classic" ESCs use PWM or some other protocol which can be easily "bit-banged" so I don't think it needs to be fully black-box in the HW sense, just agree on a HW protocol, and a suitable abstraction layer for the data to be handled internally by the algorithms.  For example, "here is the 16 bit signed value of data in the pitch axis"... not "read the value of register 0x3B and 0x3C and interpret it as twos complement".  And if someone wants to come up with a hardware design that is off the wall, they'd simply have to build in an I2C interface - simple enough - and supply a suitable driver to map to the standard/agreed data interface.

Same with where the motor controller lives.  Whether it's on-board, or several inches away, PWM will not barf.  Or if you want to create a fully new motor controller, have it work with the same pins and use a custom driver.  Maybe set aside some pins (either near the same port, or just GPIOs) for feedback in case you want to have some custom data signals sent back.  Same with charge control, battery temp monitoring, maybe even cell monitoring if you want to get fancy.  Or multiple things can live on I2C, as another alternative.

Then the algorithm guys are free to work on nerdy math (or offload it to an on-chip peripheral if supported by the processor)... the accelerometer nerds can try out the latest equipment as long as it supports I2C, the "human factors" guys can figure out what front panel buttons it should have and whether it should have scrolling LEDs and/or bluetooth and/or multimedia wifi connections and/or an 8-track player, charge port for your cell phone, electric foot massagers, etc.

Oh.. forgot to say, yes, avoid an absolute encoder... the angle of the wheel is unnecessary to know, it is another item to glitch and wear out, and actually the precision will be better with a simple hall sensor (or some-such) mounted on the circumference of the motor, where the radial motion will be at its practical maximum.  All we need to know is that the motor/tire is turning by X amount, how fast, in which direction, relative to the frame.  It doesn't matter to the algorithm which direction the valve stem is facing, for example.

Edited April 26, 2019 by pst

[tudordewolf]

I'm really excited to see this happening, I've got a graveyard of wheels with good motors and batteries but blown circuit boards that are hard to find or replace, or would benefit from better algorithms than they came with... I'd be more than happy to chip in with testing or protoyping or even putting up some money for PCB's.

 

I've got a Gotway Luffy, Kingsong 16C, and Msuperv2 that could all use new / better brains. 

[Inductores]

I worked a little bit more with the schematic and layout, waiting for some photos from the missing SOIC-8 IC's and the "transistor?" next to the right electrolytic capacitor

 

[Inductores]

And finally, (I think) I placed all the components, so now I have to route the missing traces and planes. As you can see, I also added the three additional capacitors implemented in V1.4 for the three motor outputs.

[cbgti]

It's VERY impressive and I'm happy to see the end of this project!

[Restless]

Hey Guys.

 

Love to see there are still other people trying to dev custom mainboar / fw / euc. I was involved in the earlier days of the egg project (

)

 

But due to personal reasons i had no more time for my euc and the project. Sadly the project never really achived the goal.

 

Last couple days i took out my euc and burned my mainboard  So i was looking for a mainboard replacement and there is like nothing anymore for the geuc or my teamgee f3.

I saw the VESC project, but in my opinion its way to expensive for my simple unicycle.

So i still have my st32 programmer and some stuff. I'll follow this thread and if i see a possibility to contribute, i'm happy to get involved again

I got way deeper knowledge in C++ since the last project and the fw scaffold is up, i'll try to spare time to help out there.

 

Nice progress on the mainboard design!

 

Best, kai

 

[h3X]

My first batch of dev hardware came from aliexpress today and I soldered on some pin headers...

[Restless]

On 5/12/2019 at 10:22 PM, Inductores said:

And finally, (I think) I placed all the components, so now I have to route the missing traces and planes. As you can see, I also added the three additional capacitors implemented in V1.4 for the three motor outputs.

 

Your design looks actually pretty close to my cheap teamgee f3 mainboard. So i guess your original mainboard is quite similar. May i ask what specs you are planing for.

60V? How much Amps max.?

Just a general question (since i'm not deep that into hw design), is it possible to switch the stm32 m3 with an stm32 m4 afterwards without big changes to the layout or does pin layout change drastically?

[Inductores]

10 hours ago, Restless said:

 

Your design looks actually pretty close to my cheap teamgee f3 mainboard. So i guess your original mainboard is quite similar. May i ask what specs you are planing for. 

60V? How much Amps max.?

Just a general question (since i'm not deep that into hw design), is it possible to switch the stm32 m3 with an stm32 m4 afterwards without big changes to the layout or does pin layout change drastically?

84V, but I guess it can also be used with 67.2V changing some components (basically voltage dividers and gain resistors). At this moment is just a copy of the Rockwheel GT16 board.

I don't mind to change the uC, but I need someone capable of developing some working FW. If you can collaborate, I can change it, no problem.

[Restless]

53 minutes ago, Inductores said:

84V, but I guess it can also be used with 67.2V changing some components (basically voltage dividers and gain resistors). At this moment is just a copy of the Rockwheel GT16 board.

I don't mind to change the uC, but I need someone capable of developing some working FW. If you can collaborate, I can change it, no problem.

Just a question: wouldn't it be possible to power the system with 67.2V even if it was designed for a higher voltage, without changing parts, only (maybe) small firmware changes? or does this only work for motor rating like switching from 500W to 350W without changing parts, since they would just be less "hard" used.

 

I just send out a big order to banggood (IMHO better then aliexpress, if you find the parts you need. it's way faster (like 1-2 weeks) and less complicated for me in the EU. If ordered with Priority Direct Mail, its not going through German customs, since they forward it from the Netherlands) with a couple stm32-dev boards (should be the same as yours from ali), mpu6050, bt modules, etc. so i will love to contribute with working on FW, but i have no clue if i have the math skills for the important work  But i'll see whats possible and at least bt communication, app stuff etc. should be possible

 

And i think i would need some guidance with setting up a simulation arduino. It probably only needs to generate the correct output.

 

And about changing the uC .. i think we can start with what we have at the moment and if we get it working and reaching the limits, we could still upgrade to an stm32 M4 afterwards. What i've read, they should in general be quite similar coding wise.

Edited May 17, 2019 by Restless

[Inductores]

5 hours ago, Restless said:

Just a question: wouldn't it be possible to power the system with 67.2V even if it was designed for a higher voltage, without changing parts, only (maybe) small firmware changes? or does this only work for motor rating like switching from 500W to 350W without changing parts, since they would just be less "hard" used.

 

I just send out a big order to banggood (IMHO better then aliexpress, if you find the parts you need. it's way faster (like 1-2 weeks) and less complicated for me in the EU. If ordered with Priority Direct Mail, its not going through German customs, since they forward it from the Netherlands) with a couple stm32-dev boards (should be the same as yours from ali), mpu6050, bt modules, etc. so i will love to contribute with working on FW, but i have no clue if i have the math skills for the important work  But i'll see whats possible and at least bt communication, app stuff etc. should be possible

 

And i think i would need some guidance with setting up a simulation arduino. It probably only needs to generate the correct output.

 

And about changing the uC .. i think we can start with what we have at the moment and if we get it working and reaching the limits, we could still upgrade to an stm32 M4 afterwards. What i've read, they should in general be quite similar coding wise.

I still didn't finish the schematic, but some parts (like the shunt for current measurement) are optimised for 84V. If you use 67.2V then some values of the voltage dividers should change, but the changes are basically resistors (and probably some capacitors if bigger capacitance is needed). In any case, I can always make a second variant for 67.2V (even a 100V variant can be made).

 

In fact, I think a good combination of Cortex-M4 and Arduino environment is the use of a MK20DX256VLH7 uC:

https://www.pjrc.com/store/teensy31.html

 

I think it's powerful and fast enough, "easy" to program and relatively cheap.

Edited May 17, 2019 by Inductores

[Phunny]

Teensy boards are awesome! 3.1 is discontinued but 3.2 has a drop in replacement. 3.5 is a little more money, but runs at 180 MHz instead of 72. It's also an inch longer, which should still fit any wheel. I don't know what is fast enough, but I think the faster the better.

I read an article about kalman filters the other day. It was mostly over my head, but I figure if this can be understood, it explains what the code does.

https://ngr.yt/blog/2019-04-10-kalman.html

[Inductores]

27 minutes ago, Phunny said:

Teensy boards are awesome! 3.1 is discontinued but 3.2 has a drop in replacement. 3.5 is a little more money, but runs at 180 MHz instead of 72. It's also an inch longer, which should still fit any wheel. I don't know what is fast enough, but I think the faster the better.

I read an article about kalman filters the other day. It was mostly over my head, but I figure if this can be understood, it explains what the code does.

https://ngr.yt/blog/2019-04-10-kalman.html

The problem with Teensy 3.5 is that the uC comes in a BGA package, being quite more difficult to be soldered...

[Restless]

I just did some more research for the right environment to build a Firmware. This includes the right uC as well.

And what I've learned, the stm32 m3 should have plenty of power for this task, specially because it already has hw solutions for motor controller etc.

One really interesting resource I just found, was that St already provides an SDK / lib for a FOC controlling BLDC which could be very nice. ( https://www.st.com/en/embedded-software/x-cube-mcsdk.html )

 

The next thing is... And as much as I like the Arduino stuff (not the ide though, it's terrible ...) It's nice for stuff like small IoT devices etc, but not likely to be good with performance and complexity. 

And since it's not that far from Arduino to native c/c++ anyways, I would suggest to ditch the idea of using Arduino in this project. I'd say It will cause more trouble, as it helps. And there are plenty of libraries you could use even without Arduino core.

 

That said, back to the st library. From what I understood (only fast dashing through the descriptions on my phone) there is an example for this lib with freeRTOS, which brings me to my next point. freeRTOS.

It might be a good thing to look at this project for building the FW. Since it adds the possibility of multithreading. Which is a very nice thing, for a device which should handle multiple things parallel it also seems to be the biggest open source rtos project for uC atm. Even Amazon features it for its Amazon freeRTOS.

 

So nuff said, I can't wait to get my stm32 devboards and starting to play around with first ideas