Jump to content

Open-source EUC motherboard


Inductores

Recommended Posts

@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
Link to comment
Share on other sites

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
Link to comment
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)

Link to comment
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. :)

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

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

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 2
Link to comment
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
Link to comment
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
Link to comment
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
Link to comment
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.

Link to comment
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
Link to comment
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
Link to comment
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
  • Upvote 1
Link to comment
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?

  • Upvote 1
Link to comment
Share on other sites

19 hours ago, Chriull said:

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. 

I don't think at least the cheaper microcontrollers have multiple cores ever, some higher end models might have? There are fairly simple barebones "operating systems" for them, like FreeRTOS, which usually consists of pretty much nothing but a simple scheduler to run separate tasks (one-by-one) with pre-emption and prioritizing. It's still doable without an RTOS of some kind, but care should be of course taken that the main control loop is still being run fast enough with all the other bells and whistles taking up cycles. 8-bit microcontrollers with slower clocks might become a problem though, simply not fast enough.

Also, an "environment" like Arduino gives the false idea that everything must always happen "sequentially", a good example is analogRead():

int analogRead(uint8_t pin)
{
   ...
        // start the conversion
        sbi(ADCSRA, ADSC);

        // ADSC is cleared when the conversion finishes
        while (bit_is_set(ADCSRA, ADSC));
   ...

}

Look at the while(bit_is_set(ADCSRA, ADSC)); -line, the software stops to wait until analog conversion is done, which, depending on the ADC settings, can take a while. If you write the code yourself, you can trigger the analog conversion, do other stuff in between, and then check that the conversion is complete (or wait for it to complete, if there's nothing to do until the results come in). Arduino documentation for analogRead says it takes about 100µs (0.0001 seconds), which may not sound like much, but with 16MHz core clock, that's about 1600 cycles, which again may not sound like much, but could be put to use (in practice it's not that much, it's the time between starting the conversion and it finishing, which depends on the ADC settings, but still). If you dig around the Arduino core code (you can find them in  hardware\arduino\avr\cores\arduino\   under the IDE-directory), you'll quickly notice that a lot of the stuff is "bloated", which is not really an issue with simple programs, but when you need speed (like "hard realtime" applications usually do), using the avr-libraries or registers directly can make a BIG difference, with the tradeoff that they may be more difficult to use.

I don't know if ATMegas have DMA (Direct memory access) with ADC, I did an audio spectrum analyzer with a STM32F446 a while back, there I set one of the ADCs to a continuous mode with DMA, running in the "background" and filling sample data directly into a memory buffer. I don't have to do anything but start the conversion when the software starts running and then get interrupts each time when one half of the buffer is full, so I can run FFT to get frequency data on the buffer half that was just filled and update the display, while the ADC/DMA is at the same time filling the other half. It's not "multi-tasking/threading" in the same sense as with larger operating systems, but resembles it, since the ADC measurements and FFT-calculations/display update are running in parallel (as an analogy, you could think of it as having a separate "ADC-core" and "normal CPU core" which share a buffer in memory). And of course it can be set up differently (one-shot, start/stop from your code...), the point is, there are "blocks" of the MCU that can work independently in the background at  the same time as your own code is running, even without any separate scheduler or "threads/tasks".

 

Edited by esaj
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...