Jump to content
Inductores

Open-source EUC motherboard

Recommended Posts

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!

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 by Inductores
  • Upvote 1

Share this post


Link to post
Share on other sites
Posted (edited)

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

Edited by h3X

Share this post


Link to post
Share on other sites

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.

 

  • Upvote 1

Share this post


Link to post
Share on other sites

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.

  • Upvote 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)
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. 

maxresdefault.jpg

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.

709px-CAN-Bus-frame_in_base_format_witho

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 by esaj
  • Upvote 1

Share this post


Link to post
Share on other sites
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!

  • Upvote 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 ;)

Freeman_A4_7.jpg

 

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 by esaj

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×