Jump to content
Inductores

Open-source EUC motherboard

Recommended Posts

Posted (edited)

@Chriull, if someone introduces themselves as employee or owner of a company and gives the link to said company, that's definitely not advertisement, but part of how anyone should be free to introduce themselves. If the company is EUC related it is also quite desirable under the idea of full disclosure of possible conflict of interests. Apart from that, we are all (I assume, I am) eager in getting to know people working in the field and their work.

Edited by Mono
  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
5 hours ago, Chriull said:

Yes - inappropriate is the wrong word i used. Advertising restriction are not 100% strictly enforced. This one was reported.

Once he shows his EUC project and coloaborates, as written with the EUC open source motherboard project there won't be problems anymore.

First time posts with conpany introduction and offering ones services can be too easily understood as just advertising/spamming. @jmt30897 Sorry if this was just a wrong decision and made a bad impression to start here.

I was not here for advertising. You didn't read my post clearly, and assumed that I was here for advertising. I said, I am already working on developing an EUC controller. @Chriull I am attaching screen shot of my designed PCB, in case you need a proof. 

339941951_EUCPCB.thumb.jpeg.847cf8e7b2b00e93bb0db7b81fbcd97e.jpeg 

733524113_EUCDesign.JPG.343ed195dd87505cd9e8ced8993367a1.JPG

 

I also said, I'd be happy to collaborate with others, who are already attempting to make a controller.

Along with that, I said, I also run an Electronics Manufacturing Company in India, since the last 30 years. 

And I said so to clarify that, I being a member of this forum, can support manufacturing of the PCB, i.e. assembly of the PCBs here in India, with no quality issues. 

That's not advertising. And, I didn't even speak a word about what services I offer. 

I just posted the link to my website. It's up to the users of the forum, whether to visit that link, or not. 

 

 

 

Edited by jmt30897
  • Like 1
  • Upvote 2

Share this post


Link to post
Share on other sites

I would like to share my basic knowledge about the working of electric unicycles, so that further productive discussions can begin on this thread. I am making an attempt to keep this discussion in such a crude language, that any person, even if he/she doesn't know electronics, electrical, or computer programming, could easily make sense of what I'm trying to say.

As far as I know,

electric unicycles run on BLDC Hub Motors. The image pasted below shows, how exactly a BLDC Hub Motor looks like:

 

Image result for hub motor

BLDC hub motors are also known as, in-wheel motors. These hub motors, are specifically designed for electric vehicle applications.  Over the circumference of your motor, there sits a tubeless tyre, which makes it completely ready to be used as a wheel, in your electric vehicle. A good example to explain my point is, if you carefully observe any electric moped/electric scooter/electric two-wheeler like the one, whose image is pasted here:

Image result for electric moped scooter

In such electric vehicles, the rear wheel is always a BLDC hub motor. 

For those who are not familiar with what BLDC is, for now just remember few basic things:

1.) BLDC is an abbreviation for Brush-less Direct Current. So, a BLDC hub motor is a short word for Brush-less Direct Current Hub Motor.

2.) These motors provide the best torque output and are highly efficient and durable, as compared to other types of motors. That's the reason why, everyone prefers to use these BLDC hub motors, for manufacturing an electric vehicle.

3.) The construction of a BLDC hub motor is totally different than the normal DC (direct current) motor.  For further information about its construction and all, you can always Google it. So, I won't be explaining the construction of the BLDC hub motor, over here, just to keep things simple, for now.

4.) Being able to rotate a BLDC hub motor, in a desired direction, with a desired speed, is NOT AT ALL A SIMPLE TASK!!! :/

 

For making the BLDC hub motor rotate in a desired direction, with a desired speed, you need a huge electronic circuit, which is referred to as "BLDC hub motor speed controller". To keep things simple for understanding, I'd say that, this speed controller is built using few switches (typically 6 switches, but however the number of switches may vary according to the construction of the BLDC hub motor). In such BLDC motor speed controllers, the DC power obtained from the battery of your electric vehicle, is plugged to one side of each switch, and the other side of the switch gets connected to the BLDC hub motor. These switches need to be switched "ON" and "OFF" in a desired sequential manner to deliver the power to the BLDC hub motor, so that the motor starts rotating in a particular direction, at some desired speed. If you wish to rotate the motor in clockwise direction, there's one type of sequence for switching. And, vice versa, if you wish to rotate the motor in anti-clockwise direction. 

There's a certain rate at which the switching of these switches happens. If you wish to increase/decrease the speed of your motor, then you need to respectively increase/decrease the rate at which these switches are being switched. The job of switching these switches is done by a very small computer, which is programmed to do so. To be specific, this "very small computer" is called as a micro-controller.

Now, the image which is shown below, is of a principle of physics, which is referred to as "THE INVERTED PENDULUM PRINCIPLE". The electric unicycles exist today only and only because of this principle. I have pasted an image which illustrates the principle.

So, according to this principle, 

A pendulum always attains a state of equilibrium,  i.e. all the forces acting on the pendulum become zero, only when the pendulum is either at the middle position or the extreme positions. Now, if you happen to catch the bob of the pendulum, and if you happen to invert it by making it upside down, and now if you happen to release it, then, due to the Earth's gravitational acceleration the bob of the inverted pendulum, would naturally fall either forwards or backwards. So, a control system can be designed which can sense the direction where the bob of the inverted pendulum is going to fall, and the control system thus can prevent the bob from falling in that direction, by applying an opposite control action, to help and make the falling bob straight. 

That's how the electric unicycle works. I have pasted an image which illustrates the principle.

1542819650_invertedpendulum.JPG.ed9797743bcc1a0e14e94d5c436c56b4.JPG

 

In this image, the circular object which is drawn at the bottom, which is seen to be touching the horizontal, resembles the electric unicycle. The stick which is drawn emerging from the centers of those circular object resembles the body of the rider, which is leaning in some direction. The electric unicycle and the center of gravity (COG) of the rider, and the perpendicular distance between them, resembles the inverted pendulum. The COG here, acts like the bob of the inverted pendulum. Now, if the rider stands still, and doesn't lean his body in any particular direction, the inverted pendulum is balanced, so the electric unicycle doesn't move anywhere. Now, let's assume that the rider has leaned his/her body in a particular direction, just as shown in the image above, the COG automatically, is shifted forward, which resembles like the inverted pendulum is facing an imbalance. So, in this case, the control system of the electric unicycle, senses the direction of shift of COG, or the direction where the inverted pendulum is falling. Thus, after understanding that, the electric unicycle's control system balances the weight of the rider, in such position, and makes sure that the rider doesn't fall anywhere. And thus, while balancing the weight of the rider, the control system of the electric unicycle makes sure to rotate the BLDC hub motor in that direction where the rider is leaning his/her body. 

That's why if you stand on the electric unicycle and you lean forward, the electric unicycle takes you forward. The more you lean forward, the more it accelerates and takes you into that forward direction. And vice versa for backward direction.

This is how electric unicycles work. :)

  • Like 1

Share this post


Link to post
Share on other sites

Perhaps a head start on the arduino code. https://www.instructables.com/id/Self-Balancing-Unicycle/

I have a variety of esp8266 boards laying around (wemos d1, d1 r2, d1 mini, node mcu), i think the only mods from the Arduino code are changes to pin #'s...). At least that seems to be the case for any other Arduino-Esp8266 conversions (not that I have tried a bunch)

Share this post


Link to post
Share on other sites
Just now, Blueblade said:

Perhaps a head start on the arduino code. https://www.instructables.com/id/Self-Balancing-Unicycle/

I have a variety of esp8266 boards laying around (wemos d1, d1 r2, d1 mini, node mcu), i think the only mods from the Arduino code are changes to pin #'s...). At least that seems to be the case for any other Arduino-Esp8266 conversions (not that I have tried a bunch)

I have seen this Instructable already, which you have mentioned.

Here, they aren't using a BLDC hub motor for building their EUC

What they are using is a normal DC motor. So, they have managed to make an EUC, by using a normal DC motor. 

Following that Instructable, won't prove much helpful for our purpose.

When its a DC motor, then the circuit which runs this DC motor and the code which is meant to run this DC motor are too simple, as against of a BLDC hub motor. 

In my opinion, migrating from this code and the circuit, to our purpose would become way too difficult. So, I feel we should not refer to that Instructable.

So, what to do?

I have a solution for this problem too! :)

Here's another Instructable where in, few bunch of Polytechnic students from Indonesia, have successfully built their own complete electric unicycle using a 60V 500W BLDC hub motor.

Here's the link to it:

https://www.instructables.com/id/DIY-Self-Balancing-One-Wheel-Vehicle/

They've even attached some drawings and some part of their code, for this project. However, not much information is disclosed about the controller, which they're using. All I could understand is, they've used an STM32 microcontroller for this purpose.

Besides that, you'd be amazed to see the results of their work, in this video.

 

The work which these guys have done, could be our source of inspiration, for developing our open source controller. I had tried to get in touch with one of these guys, who have developed this EUC. I wrote an email, saying hello to him, but i didn't get any reply... :(

Anyways, but the good part is that, now, we do have a reference code in our hand for developing an electric unicycle, using the STM32 micro-controller in this Instructable. 

Those who are well-versed with programming in Embedded C, could have a look at the code, and could give some review on it, on this thread. :)

Share this post


Link to post
Share on other sites
On 1/18/2019 at 4:49 PM, Inductores said:

Hi all, I was wondering if some of you would be interested in developing an open-source EUC motherboard to substitute some of the current motherboards provided by the manufacturers. The advantage of this? Completely custom design and free for the community!

I'm able to design the board related to the hardware (from schematics, to layout, manufacturing and assembling), but I'm definitely NOT good at firmware in any of the cases (uC, FPGA, SoC...). That's why I would like to know if there is some interested person to collaborate with the SW/FW part in this project. I would like to make the design for my current EUC (Rockwheel GT16), but I don't mind to make the layout for any other EUC (the schematics would be 99% the same). If there is a REALLY interested person to help me, I offer myself to give away a custom motherboard(s) for free to test and develop the FW (and SW if possible, but I guess Wheellog would be a good start).

Any interested to collaborate?

Just in case you did not see that till now - here was already something in this direction:

There should be quite some information available in this 52 pages topic...

  • Like 2
  • Upvote 1

Share this post


Link to post
Share on other sites
Posted (edited)
14 hours ago, jmt30897 said:

Anyways, but the good part is that, now, we do have a reference code in our hand for developing an electric unicycle, using the STM32 micro-controller in this Instructable. 

Those who are well-versed with programming in Embedded C, could have a look at the code, and could give some review on it, on this thread. :)

On a quick glance, I don't think this is going to be really useful. At least a couple of the files seem to be modified from STMicroelectronics examples, the entire source wasn't there (at least I noticed just 4 files in the instructable). They're apparently using a prebuilt motor controller and  a rotary encoder instead of hall-sensors. I couldn't make heads or tails how the motor's actually controlled, thanks to no comments and functions and variable names in (I think) Indonesian, but maybe it's somewhere there... :P I only glanced it over in like 5-10 minutes, so maybe I missed something. The only (maybe) somewhat useful piece could be the Kalman-filter code. After a second look at the Kalman-code, nope, find a better example or study the mathematics behind it and roll your own... :rolleyes:

The "hard" parts of the firmware are likely reading the IMU with proper filtering (a process control/automation M.Sc -guy at work mentioned the Kalman-filter on a short discussion about IMUs a while back, since he's the maths guru, I trust that it's pretty important ;)), FOC for motor control and the PD or PID -loop (not coding wise really, but finding the "correct" constants).

Projects like this have the additional problem that getting the hardware isn't exactly cheap (motor + controller + batteries), and making the frame can be problematic. And trying to write the software without the actual hardware is pretty much impossible. I do have a Firewheel motor + shell + some batteries (and finally lab power supplies capable of up to 100V) lying around, but I wouldn't trust my electronics design skills so much that I'd actually try to ride something I made :P Probably should try to design a simple motor controller at some point just to see if I can get the FOC running properly, now that I've dipped my toe in ARM Cortex M3/M4's and get more "exercise" in C programming ECUs at work nowadays. Then again, not sure how much I want to write embedded code at home when I do it all day at work... :D 

Edited by esaj
  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, esaj said:

On a quick glance, I don't think this is going to be really useful. At least a couple of the files seem to be modified from STMicroelectronics examples, the entire source wasn't there (at least I noticed just 4 files in the instructable). They're apparently using a prebuilt motor controller and  a rotary encoder instead of hall-sensors. I couldn't make heads or tails how the motor's actually controlled, thanks to no comments and functions and variable names in (I think) Indonesian, but maybe it's somewhere there... :P I only glanced it over in like 5-10 minutes, so maybe I missed something. The only (maybe) somewhat useful piece could be the Kalman-filter code.

The "hard" parts of the firmware are likely reading the IMU with proper filtering (a process control/automation M.Sc -guy at work mentioned the Kalman-filter on a short discussion about IMUs a while back, since he's the maths guru, I trust that it's pretty important ;)), FOC for motor control and the PD or PID -loop (not coding wise really, but finding the "correct" constants).

Projects like this have the additional problem that getting the hardware isn't exactly cheap (motor + controller + batteries), and making the frame can be problematic. And trying to write the software without the actual hardware is pretty much impossible. I do have a Firewheel motor + shell + some batteries (and finally lab power supplies capable of up to 100V) lying around, but I wouldn't trust my electronics design skills so much that I'd actually try to ride something I made :P Probably should try to design a simple motor controller at some point just to see if I can get the FOC running properly, now that I've dipped my toe in ARM Cortex M3/M4's and get more "exercise" in C programming ECUs at work nowadays. Then again, not sure how much I want to write embedded code at home when I do it all day at work... :D 

What if, we use a trapezoidal/square wave control algorithm for developing our open source EUC controller?

Reasons why we should go for it:

1.) Trapezoidal/square wave algorithm is the cheapiest and the easiest to implement.

2.) Implementing a sinusoidal or FOC control algorithm is very difficult and costlier to implement.

3.) From the above points, we understand that, the amount of effort and cost needed for developing a sinusoidal or FOC controller, is too much against as that of the trapezoidal/square wave controller.

4.) So, from point 3, what I think is, even if we are able to develop a sinusoidal or FOC controller on our own, we should not make those efforts publicly available for free. That's a trap. Real business lies in developing and selling the FOC or sinusoidal controllers as a product.

So, I think, trapezoidal/square wave algorithm being easy to implement, and requiring less effort and cost to build one, strategically makes it the right choice for an open source purpose.

Your opinions and comments on this are welcome. :)

  • Upvote 1

Share this post


Link to post
Share on other sites
Posted (edited)
52 minutes ago, jmt30897 said:

What if, we use a trapezoidal/square wave control algorithm for developing our open source EUC controller?

Reasons why we should go for it:

1.) Trapezoidal/square wave algorithm is the cheapiest and the easiest to implement.

Trapezoidal is easy, but my suspicion is that it won't be "accurate" enough (too jerky?) for something like a self-balancing device... but if someone proves me wrong, then why not, at least it's really straightforward to implement. If adjusting the PWM fast enough, it could maybe get "close enough"?

 

Quote

2.) Implementing a sinusoidal or FOC control algorithm is very difficult and costlier to implement.

Difficult yes, but if the MCU has kick (the Indonesian guy/guys used a Cortex M4, those things have hardware FPU and the M4 I have runs at 180MHz at max clocks), it doesn't really add cost IMHO. ATMega-based Arduino on the other hand probably won't be fast enough for the matrix and vector calculations, even if using fixed point maths (again could be wrong though ;))

Quote

3.) From the above points, we understand that, the amount of effort and cost needed for developing a sinusoidal or FOC controller, is too much against as that of the trapezoidal/square wave controller.

4.) So, from point 3, what I think is, even if we are able to develop a sinusoidal or FOC controller on our own, we should not make those efforts publicly available for free. That's a trap. Real business lies in developing and selling the FOC or sinusoidal controllers as a product.

AFAIK, the guy who made VESC gets flown by private jets to help big companies with motor controller design, but then again VESC is open source. Big semiconductor companies offer their own tools, code and development kits for FOC development. @lizardmech built controllers with FOC (as far as I know, btw, are those available somewhere? ;))...  I don't really think that business/financial reasons are a sound justification for not using a more complex control method / not making it open source. The "cost" of workhours put into the project is essentially zero, since open-source software/hardware projects are usually made by volunteers, not paid programmers/hardware designers. Of course there are exceptions and companies that provide software / schematics / PCB designs for free, but sell premade hardware.

 

Quote

So, I think, trapezoidal/square wave algorithm being easy to implement, and requiring less effort and cost to build one, strategically makes it the right choice for an open source purpose.

With good modular design of the firmware and interface to the motor control, the control-module could be replaceable with any type of control, so the method could be changed as needed (ie. balancing algorithm "requests" some certain torque or speed value, and the motor control code acts as a black box, so the actual method is hidden from outside). Of course it will likely need fine-tuning and adjusting between different motors and control methods, but at least leaves open the possibility to "pick and combine" as needed.

The big step is making the hardware "cheap enough" (although likely it still won't be cheap, even a smallish 10-14" BLDC/PMSM -motor with shipping and customs from somewhere like Aliexpress is something like ~200€ because of the weight) and easy enough to get/build, plus a solid, well documented and sound software to work with, so that bigger crowd picks up the project.

Edited by esaj
  • Like 1

Share this post


Link to post
Share on other sites

Quadcopter flight controllers are cheap (usually STM32 based now, F3/F4/F7) and run sensor loops (gyro/accelerometer/etc.), tunable PID loops and filters, control ESC's, and have UART's for interfacing.  They run multiple modes which control how much the user can vary pitch and roll vs. the controller maintaining level attitude (EUC could be switchable from granny mode to carving mode to sprint mode to vary response to user input, limit speed, etc.).  They also have OSD built-in so it's easy to transmit a video image with realtime info overlay.

I haven't looked at the code but it seems like a good place to start.  They are easily dealing with much higher speeds and 4 motors concurrently.   They are also flashable through USB.  There are several open-source versions of firmware.

betaflight 

  • Upvote 2

Share this post


Link to post
Share on other sites
6 hours ago, wtf said:

Quadcopter flight controllers are cheap (usually STM32 based now, F3/F4/F7) and run sensor loops (gyro/accelerometer/etc.), tunable PID loops and filters, control ESC's, and have UART's for interfacing.  They run multiple modes which control how much the user can vary pitch and roll vs. the controller maintaining level attitude 

...

I haven't looked at the code but it seems like a good place to start.  They are easily dealing with much higher speeds and 4 motors concurrently.   They are also flashable through USB.  There are several open-source versions of firmware.

betaflight 

This should be much soft- and hardware which could be reused for EUCs! 

Just with the ESCs there will be a problem - no active cooling by rotors, in a closed compartment instead of in "free air", much higher voltages needed.

 

On 3/14/2019 at 4:20 AM, jmt30897 said:

The link "For detailed information about electrical system and control, you can refer to this paper for reference >>http://ieeexplore.ieee.org/document/7860971/" sounds interesting:

"From the simulation and application in the real vehicle, the use of PID control is capable driving the vehicle in maintaining the balance condition within ±10° tilt angle boundary on flat surface, bumpy road, and inclining road up to 15° slope."

With a nice simulation the control loops could be tuned to prevent such things as the oscillation bugs.

  • Upvote 2

Share this post


Link to post
Share on other sites
22 minutes ago, Chriull said:

The link "For detailed information about electrical system and control, you can refer to this paper for reference >>http://ieeexplore.ieee.org/document/7860971/" sounds interesting:

I don't know if you have access to the paper, but I do, and the picture of the designed EUC is very similar (I would say almost identical) to an Inmotion V5:

EUC1.PNG.89c9223fc67fc066c850dd593c74d296.PNGEUC2.PNG.bcdf83f4d16a25e357b17e484db184c1.PNGEUC3.PNG.35bb06ef99d69b50b923f0bb6b05a827.PNG

It would be interesting to know the uC used in the Inmotion V5 board to know if the design is identical.

 

  • Upvote 1

Share this post


Link to post
Share on other sites
18 hours ago, Chriull said:

This should be much soft- and hardware which could be reused for EUCs! 

Just with the ESCs there will be a problem - no active cooling by rotors, in a closed compartment instead of in "free air", much higher voltages needed.

Yes, the ESC's are usually separate from the flight controller board, and sized for handling motor amps.  Most quads are using brushless motors.

Share this post


Link to post
Share on other sites

I guess here's where I talk in circles but shouldn't somebody understand the actual design, like the concepts and then the math behind the algorithms, or how to charge a battery and how much power is needed, etc., before we start worrying about  square/trapezoidal/sine wave decisions, or what to re-use from drone firmware?

At least speaking from experience, I find projects are more successful when they go in the order of design -> algorithms -> hardware decisions -> building the hardware.
 

  • Like 1

Share this post


Link to post
Share on other sites
48 minutes ago, pst said:

I guess here's where I talk in circles but shouldn't somebody understand the actual design, like the concepts and then the math behind the algorithms, or how to charge a battery and how much power is needed, etc., before we start worrying about  square/trapezoidal/sine wave decisions, or what to re-use from drone firmware? 

At least speaking from experience, I find projects are more successful when they go in the order of design -> algorithms -> hardware decisions -> building the hardware.
 

You're right, so getting the schematics from the original board is a way to understand how it works and then it can be a point of reference for a new design.

Share this post


Link to post
Share on other sites
27 minutes ago, Inductores said:

You're right, so getting the schematics from the original board is a way to understand how it works and then it can be a point of reference for a new design.

Yes, it is... I'm not sure why this is directed at me.  My statement is that people should worry about understanding the problem before they try to solve it.  Backwards-engineering is one way to understand the problem... at least through the window of how someone else went about solving it.

As you say, it is "a point of reference."  Not a full design.  So people need to be working on other things in parallel which will help educate us on how to develop a full design, and maybe leave a bread crumb trail if needed to help people customize it in the future for their own needs.  Right?

Edited by pst

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

×