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
  • Upvote 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.

  • Upvote 1

Share this post


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

Share this post


Link to post
Share on other sites

Okay,  so here's the flowchart of the algorithm, which I have designed. It's a very basic one. Let us have some further discussion over this. :)

image.png

Edited by jmt30897

Share this post


Link to post
Share on other sites
On 3/17/2019 at 2:40 AM, 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.
 

It's a good point, it's easy to get stuck in the smaller details before the entire big picture, but all those small details have to be handled sooner or later.

I've been away from the forums for a while, as I currently have my hands full with learning the ropes at a new job and, out of the blue, was made an offer to do some hardware design on a commercial product on the side, so most of my spare time is pretty much full :P

But on the topic, excluding all the bells & whistles of modern wheels (lights, Bluetooth, app etc), here's what I think are the main issues:

 

On the hardware side:

Motor:

3-phase PMSM/BLDC seems the "obvious" choice, seeing that all the commercial wheels use those, although it's probably possible to build one with a different kind of motor (I think I saw a seated design that used brushed 1-phase DC motor somewhere, but it was capable of something like 10km/h max and was easy to overlean) don't know if it could work with steppers, maybe with micro-stepping? Still, I'd pick a BLDC. Since the motor control hardware and software are somewhat specific to the kind of motor used (and still likely need to be fine tuned for motors from different manufacturers, even if they all were the same "kind"), the decision is pretty important and has to be done before mainboard motor control (well, you could use 2 of the 3 half-bridges to drive a 1-phase motor, even if the motor driver is originally made for 3-phase motors). Probably no-one or very few people can make their own motor, so likely it has to be a prebuilt one.

Batteries:

Some people may be able to build their own packs, if they have the equipment (I personally wouldn't trust cells soldered together, needs a battery spot welder), and maybe even design the BMS-board(s), I'd go with premade packs. Packs can be charged through the BMS, so the mainboard doesn't have to have anything related to the battery charging (although it still can).

A couple of points on these:

-Make sure that the BMS used has separate charging and discharging. I can tell that it's NOT FUN when the overvoltage (overcharge) protection cuts the power because regenerative braking pushes the voltage too high going downhill with full batteries and both the charging and discharging go through same protections... better let the battery soak up a slight overvoltage for some seconds rather than faceplant, ie. usually the BMSs in the EUCs don't have overvoltage protection on the discharge-side  ;)

-Make sure the rated discharge current is high enough, again you don't want the BMS cutting all power to the wheel during fast acceleration or sudden current surge due to a bump, Gotway BMSs don't have overcurrent protection at all?

Shell:

Technically, the shell could come from an old (broken) wheel, be 3D-printed (there's at least one design in the forums that has been used in practice with the Microworks -board & -motor) or built from whatever material you have, I made one from flat aluminum bars and leftover floor laminate a few years back using Firewheel mainboard & motor:  https://imgur.com/a/orjAz

lTAggL4.jpg

Lesson learned: don't put a mainboard from a commercial wheel much further away from the wheel axle than it is originally (in this case it was something like >2 times farther). In this case, the top-heavy design and the difference in the angular acceleration (which should have been obvious; the further away from the axle the IMU is, the higher the acceleration / angle speed for the same change in angle over the same time), if that's even the correct term, made it like riding a bull heaving back and forth at times, although it did "behave" when riding on flat streets. Hitting a smallish stone on a forest path, the wheel would quickly jerk forwards and then shoot straight very fast, as it tried to correct the error... just not getting thrown off required some acrobatics :P  Again a point where the software may need to be at least somewhat fine-tuned separately for each design?

Mainboard:

This is the most complex hardware-side thing, and pretty much everything on the board is critical (well, except possible lights, speakers or Bluetooth, but if these break, they can take other things with them), so I broke it down into more "main" issues. A couple of years ago, I traced most of the Firewheel PCB and the circuits there, which might give some ideas: 

Commercial boards can give good clues at how to do things (or how to not do things ;)). Designing the board is certainly not an easy task, here's the main issues as I see them and some thoughts (although remember that I'm just a hobbyist):

Motor driver:

Three half-bridges ("3-phase inverter"?) made with power MOSFETs seems to be what all the wheels use. A good quality 3-phase gate-driver chip is probably a lot better solution than trying to build something from discrete components, as it can handle the needed voltage boosts for high-side N-channels, dead time insertions etc. Power dissipation needs to be carefully considered, it's easy to kill the MOSFETs with overheating by pushing too much current through them or through switching losses. Or by transient voltage spikes. Or gate ringing. Or shoot-through. Or... ;)  Read a ton of manufacturer application notes, Electronics Stackexchange and grab a book or two on power electronics. Remember that you're driving inductive loads, which can cause all sorts of hairy issues with peak currents and transient voltages. Depending on the software-side motor drive algorithm picked, the PWM frequency might have to be decided early on..?

If you haven't been around the forums for a few years, it might come to you as news that even the commercial manufacturers had a lot of issues with the MOSFETs dying on the wheels, up until a couple of years ago, and it still might happen on occasion (but usually through an abnormal situation, like a crash or wheel stuck tilted against an obstacle). "Over-engineer", use much larger tolerances and worst-case scenarios than you think you need etc., and simulate & test it like hell before even thinking of putting your bones (or life) on the line with it  :P   For a seasoned electronics engineer, designing this is probably isn't that much of a hurdle, but some of the finer points are easy to miss. You'd think that you just turn MOSFETs on and off, but scratch the surface, and it's much more complex than that in an application like this.

Motor current measurement probably also goes under this topic, but that shouldn't be so much of an issue (sense resistors or current sensors, ADCs).

Of course, there are probably at least some ready-made solutions for this, but usually the heavy-duty ones (remember, we're talking several hundreds or kilowatts of power to be controlled) are pretty costly. Plus, what's the fun in getting a ready-made solution in a complex engineering problem like this? ;)

MCU:

I still doubt that Arduino would work very well if any more complex motor drive algorithm is to be used, but it can certainly do trapezoidal... one of the first things I did when I started getting into electronics a few years back was to build a 3-phase inverter from discrete components (it took 3 breadboards and dozens of jump-wires) and use an Arduino to do trapezoidal control for a small BLDC with hall-sensors. Still, I'd go with an ARM Cortex M<something, 3, 4?>. The most common chip in commercial wheels seems to be (or at least used to be) STM32F103, an ARM Cortex-M3 from ST Microelectronics. It's relatively cheap (something like ~5€ in single pieces? Depends on dealer and Flash size), packs a punch (up to 72MHz core clock), and programming it isn't black magic (take a look at something like CubeMX from ST, you no longer need to remember a ton of registers by heart or dig through a several hundred page datasheet to get things done or calculate the clock multipliers/dividers by hand, the basic setup is pretty easy). It could still use trapezoidal control, but at least the MCU won't be the limiting factor for going into more complex controls.

Power supply for the low voltage components:

A switching step-down converter needs to be designed and carefully tested, most ready-made controllers are limited to something like 40V max input, but there are models that can handle more. The Firewheel used LM5007, that's rated up to 75V, but it was also the weak point of the board (multiple members here, myself included, have had their board die, and I think the usual culprit was the step-down failing), so probably don't look at the Firewheel design on this.

Most MCUs are 3.3V, but even if they were 5V, that's still a large voltage to drop from the batteries, and during regenerative braking it can go higher, so you can probably leave a margin of at least 5V above the maximum battery voltage, if not more, just to be on the safe side. Linear regulators are out the window immediately, the power dissipation will kill them pretty much instantly even if you draw a few tens of mA, although they could still be used to drop the voltage for low amperage loads once the battery voltage is regulated down to something like 5-12V first through a switching mode power supply.

Luckily, most datasheets for switching controllers (external power transistor) or switching regulators (internal power transistor) have application examples and step-by-step instructions for calculating the external component values when you know the maximum and minimum input parameters, so it's not that difficult. For example, I've never made a switching power supply with SEPIC-topology (a certain type of step-up/step-down -converter) before, but was able to design something that should work (in theory) for up to 60W of output power at 12V and pick prototype components in a single evening just by following some Analog Devices datasheets and app notes and "oversizing" things, doesn't even seem to need heatsinks. Of course that's just the first prototype and probably needs a lot of testing and tweaking still. Since "only" a buck (step-down) -converter is needed here, it should simpler, but the high input voltages make it more trickier to find suitable components.

The Firewheel used a HIP4086 3-phase MOSFET gate driver, which could work directly with the battery voltage (up to 80V): https://www.renesas.com/eu/en/doc/datasheet/hip4086-a.pdf   I guess the gate driver might work at a much lower voltage than the full battery, meaning it gets its power from the step-down, even though it needs to push the high-side gates to 10-12V above the motor phase (which might mean over 80V on a "67.2V" -wheel), but I haven't really ever dug up into them that much. That's one more point to dig deep into.

I didn't mention the IMU above, because I don't think it really is a hardware "issue" (more of a software-side issue), since there's no point even in debating about the idea of anyone building their own. :P Just pick a premade one that's commonly available (I didn't know MPU6050 has come to end of its life, better pick something newer).

On top of these, there's still of course a lot of design decisions to make with "smaller" issues...

 

On the software side, the main issues are:

Motor control algorithm:

I won't go back to debating which method should be used, suffice to say that there are multiple options with varying complexities. The more complex algorithms can take a lot of time to get "right". Patience is a virtue  ;) 

Reading and filtering the IMU data:

This can get complex with the filtering maths needed, but if ready-made libraries are available somewhere, it could actually be pretty simple. Still probably needs someone strong in mathematics and such, rather than "just a programmer".

P(I)D-loop:

The feedback control loop isn't complex as a piece of software (it can be done with only a handful of lines of code), but the issue is "finding" the correct factors so that the entire thing is stable at all situations. I don't know if the commercial wheels use something that has dynamic parameters ("auto-PID") or just static constants... There's a big difference with something that can somewhat balance itself (when nobody is standing on it) and the precision of balance the commercial wheels have with pretty much zero over/undershoot, I managed to make a small self-balancing robot some years back, but I searched the PID-constants just by trial and error to get it to balance, I wouldn't trust this method with something that's supposed to keep me from falling ;) :

Somebody with a background in control theory (automation engineers, usually) is probably the best person to deal with this.

Probably there's a ton of things I forgot and didn't go into even nearly enough detail, but I think is enough of my ramblings for now  :P 

 

 

Edited by esaj
  • Like 2

Share this post


Link to post
Share on other sites

Boy, @esaj, you don't cease to amaze me with the depth and breadth of your replies!

I imagine you are very good at your job!

  • Upvote 1

Share this post


Link to post
Share on other sites
On 3/22/2019 at 11:58 AM, jmt30897 said:

Okay,  so here's the flowchart of the algorithm, which I have designed. It's a very basic one. Let us have some further discussion over this. :)

image.png

Imo the main loop is just a "normal" controler loop:

- read (and preprocess) input values (IMU, current and hall sensors)

- perform the "transfer function" calculations (filter, PID, ...)

- "apply" extraordinaly limits (sidewards tilt, tiltback)

- motor control: "apply" the output values (H Bridge control for the motor - PWM duty cycle and "operational mode" selection of the H-Bridge)

One could think of putting everything else (Led control, user communication, ...) on an independend core (to the stm32s have multiple cores?) or a second uC. 

In the before linked firmware thread afair were links to EUC firmware projects? And measurements of actual EUC hardware?

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

×