Jump to content

Firmware


jayjay23

Recommended Posts

The OS level and driver stuff for the VESC is now mostly done. Applications should be able to access IMU data via the OS.

https://github.com/votuananhs/bldc/tree/EUC-VESC_electronics/test 

https://github.com/votuananhs/bldc/tree/EUC-VESC_electronics/applications/MPU6050

Once it's set up writing balancing code should be as easy as on an aduino.

Link to comment
Share on other sites

Link to comment
Share on other sites

  • 2 weeks later...
9 minutes ago, Bruno said:

Hi, i have a Smart Balance Wheel Hoverboard S3000 with a bad gyroscope board in one side. It gots a continuous blue light of death.

Do you know how to repair/fix this bad gyroscope sensor board ? Maybe is there a way to reprogram the STM32F MCU ?

 

video-1483051549.mp4

You're in the wrong bit, mate ! This the EUC bit. You want the hoverboard bit instead.

Incidentally, you probably want a new board, rather than trying to fix that one, unless you know specifically which chip / what else is broken, and feel qualified to solder that sort of thing yourself...

Edited by Cerbera
  • Upvote 1
Link to comment
Share on other sites

12 hours ago, Cerbera said:

You're in the wrong bit, mate ! This the EUC bit. You want the hoverboard bit instead.

Incidentally, you probably want a new board, rather than trying to fix that one, unless you know specifically which chip / what else is broken, and feel qualified to solder that sort of thing yourself...

Oh sorry mate ! Yes, i feel qualified to solder these boards, problem is that if it's a problem with the STM32F mcu (and it seems so), i will not have the proper firmware to write to it.

Thank you !

Link to comment
Share on other sites

  • 2 weeks later...

@electric_vehicle_lover Would you be able to have a look at this? The IMU driver and kalman filter with completed now. All that remains to be done is the PID section for balancing control. The person who did the driver wasn't familiar with motors so he wasn't sure what to do. I think one of the existing control apps can easily be reused but I don't know how to get the kalman filtered data into the control app.

https://github.com/votuananhs/bldc/tree/EUC-VESC_electronics/applications

  • Upvote 1
Link to comment
Share on other sites

@lizardmech I am being busy with other project but I want to give you feedback on the next days. I am happy to see detailed commit logs on that git repo - that will help me to understand the work that had been done: https://github.com/votuananhs/bldc/commits/EUC-VESC_electronics

Link to comment
Share on other sites

@electric_vehicle_lover

My latest PCB that has all the voltage converters to run the logic on board should arrive in a day or two. He has tested the IMU driver on his stm discovery board. What can't quite figure out how to to tell the VESC to increase or decrease current. It looks different in each app benjamin wrote. For now I just want to get it so if you tilt the IMU current ramps up, but I can't make sense of how the other apps do it.

Link to comment
Share on other sites

4 minutes ago, lizardmech said:

What can't quite figure out how to to tell the VESC to increase or decrease current. It looks different in each app benjamin wrote. For now I just want to get it so if you tilt the IMU current ramps up, but I can't make sense of how the other apps do it.

See applications/app_nunchuk.c:

See this lines:

            if (is_reverse) {
                mc_interface_set_current(-current_out);
            } else {
                mc_interface_set_current(current_out);
            }

Edited by electric_vehicle_lover
Link to comment
Share on other sites

The current_out is just a float between -1 to +1, so the kalman result has to be translated from angle to a float value ranging from -1 to +1?

For basic testing using say -90 to 90 tilting you would have something like

current = compAngleX / 90

mc_interface_set_current(current)

?

Of course to actually balance will require more complex PID and ramping etc.

Link to comment
Share on other sites

Yes, you will need to scale/adapt the angle error (as a P/proportional controller) to the current value.

If this first P controller works, then the PID controller can be worked. There is a lot of documentation about PID, even for balance robots on Arduino :-) -- the difficult part/different part are the motors, that Arduino example are DC motors and the BLDC motors are difficult but VESC should be the solution!! :-) :-)

Link to comment
Share on other sites

I am being away from the firmware because I am being doing a fitness tracker and Android app to help me control my obesity/body fat, and this is priority...

And finally my son learned to ride EUC :-) -- and soon the spring should arrive and I will want to focus more on using EUC, being back to this project:

 

  • Upvote 1
Link to comment
Share on other sites

I was looking at other MCUs for long term planning while waiting for my PCBs. These seem to be the best option for motor control. http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/c2000_performance/real-time_control/f2833x_f2837x/overview.page?DCMP=Delfino&HQS=delfino#TMS320F2837xD

They have a full set of open source FOC solutions, the only thing they lack is some of the VESC motor detection and vehicle features like phase voltage sense to measure RPM accurately. It would be easy to add those and set it up to work with the VESC software stack.

At a glance they look fairly mundane however when you take a look at the arch closely it has some very interesting things. It has a 200mhz cpu + FPU but the FPU is not a normal FPU, it has dedicated hardware for the math used for clarke, parke transforms and other FOC code. The hardware mode is so fast it does the calculations in 1 or 2 cycles. Giving FOC performance normally seen on FPGA. If that wasn't enough it has an entirely separate FPU outside of the CPU that can interact with ADC, PWM and others without using the CPU, so you can have it off doing floats for a kalman filter on the IMU with no cpu overhead.

Link to comment
Share on other sites

  • 1 month later...

I am being reading more about motor control, now the Shane Colton (http://scolton.blogspot.pt/) documents and firmware -- very good documentation!! Not compared to VESC almost inexistent documentation. The files were public but seems the original links to google drive are not working anymore so I am sharing on github: https://github.com/EGG-electric-unicycle/documentation/tree/master/Shane_Colton

  • Upvote 1
Link to comment
Share on other sites

5 hours ago, electric_vehicle_lover said:

I am being reading more about motor control, now the Shane Colton (http://scolton.blogspot.pt/) documents and firmware -- very good documentation!! Not compared to VESC almost inexistent documentation. The files were public but seems the original links to google drive are not working anymore so I am sharing on github: https://github.com/EGG-electric-unicycle/documentation/tree/master/Shane_Colton

Great info, seems like the VESC 6 will finally be released in the next few weeks so I have been holding off on the software and sorting out hardware issues. I have been studying MCUs and FOC quite a bit as well. I noticed almost all the commercial options use int with IQ numbers, but I'm pretty sure that is the reason the VESC is easier to configure is due to everything being floats. All the IQ based ones with motor detection tend to be very limited in the range of motors they can detect because they will overflow IQ numbers in extreme cases.

Also I found a really nice FOC code example in the Ti F28377s support software, it's just burried away in their control suite software, the code is totally open and BSD license.

  • Upvote 3
Link to comment
Share on other sites

Just curious - do you think with open source firmware, it might be possible to create a control board that can automatically sense the differences between motors and adapt itself to different wheels?  I mean, if you had a controller that could do some sort of calibration routine to adjust firmware settings, you could use that controller with any sized wheel without needing to reprogram the settings.  I always thought it would be nice if there was a universal control board that you could use with any wheel out there.  Say if your control board blew up in your Gotway, you could pop in this custom firmware control board and get going again.  

But I suppose that can also be a bit hazardous if the motor capabilities are exceeded.  I wonder if there's some way to sense torque/speed capabilities from a free spin calibration?  Or does the number of magnets and coils need to be specified in the firmware calculations?

  • Upvote 1
Link to comment
Share on other sites

9 hours ago, Hunka Hunka Burning Love said:

Just curious - do you think with open source firmware, it might be possible to create a control board that can automatically sense the differences between motors and adapt itself to different wheels?  I mean, if you had a controller that could do some sort of calibration routine to adjust firmware settings, you could use that controller with any sized wheel without needing to reprogram the settings.  I always thought it would be nice if there was a universal control board that you could use with any wheel out there.  Say if your control board blew up in your Gotway, you could pop in this custom firmware control board and get going again.  

But I suppose that can also be a bit hazardous if the motor capabilities are exceeded.  I wonder if there's some way to sense torque/speed capabilities from a free spin calibration?  Or does the number of magnets and coils need to be specified in the firmware calculations?

VESC does this in part already so should be possible. However, VESC is a big project by a developer putting a lot of energy that I will not be able to do the same. So please do not expect that.

But I can imagine a firmware that take some config parameters for each motor and have such parameters listed on the online page or simple, available firmware files for different motors - that is doable. MicroWorks 30B4 board have Bluetooth connection that can send and receive data, like that parameters. An Android app could be developed to flash firmwares and configure them, I am betting on that.

  • Upvote 1
Link to comment
Share on other sites

19 hours ago, electric_vehicle_lover said:

VESC does this in part already so should be possible. However, VESC is a big project by a developer putting a lot of energy that I will not be able to do the same. So please do not expect that.

But I can imagine a firmware that take some config parameters for each motor and have such parameters listed on the online page or simple, available firmware files for different motors - that is doable. MicroWorks 30B4 board have Bluetooth connection that can send and receive data, like that parameters. An Android app could be developed to flash firmwares and configure them, I am betting on that.

You can already do this right now with the VESC though. Only reason it isn't possible to ride a EUC using it at the moment is no one is willing to finish the last bit of code while I finish working adapting the hardware for 60V+.

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