Jump to content

lizardmech

Full Members
  • Content count

    686
  • Joined

  • Last visited

Community Reputation

647 Excellent

2 Followers

About lizardmech

  • Rank
    Advanced Member

Profile Information

  • Location
    Australia
  1. Firmware

    The VESC seemed ok with hall sensors for startup. Not sure if an audiuno would complicate matters you probably need to make minor adjustments to the VESC itself for balancing vehicles, just sending it current commands via uart may not be enough. The only real downside with the VESC is it's overly complex for an EUC, it doesn't boot instantly. Either an instaspin or cut down VESC fork without the RTOS would probably be better for most users. Most of the code needed for everything exists, I can never just figure out how to combine it all. Hobbyking sells cheap VESC 4 clones now, for driving a hoverboard motor there's not much need for expensive versions. https://hobbyking.com/en_us/turnigy-skateboard-esc.html Ti have cheap kits as well you can combine these two to make an instaspin controller that can run hoverboard motors. https://mouser.com/ProductDetail/Texas-Instruments/LAUNCHXL-F28069M/ https://mouser.com/ProductDetail/Texas-Instruments/BOOSTXL-DRV8305EVM/ You could connect a stm32f407 dev board to the ti motor driver board and use it with VESC firmware as well.
  2. Custom Built to Spec Electric Unicycles Now Available

    Did you design a custom motor controller for it?
  3. Firmware

    I'm just confused why you have been doing all those things. This is the exact kind of thing I'm talking about, you could easily just calmly explain your perspective and refute what I wrote. Instead all we get is "someone dared to disagree with me on the internet now I will ignore you all!!!" as if answering anyone or considering others ideas is beneath you. You don't like criticism but you have no issue deriding others attempts with false accusations in the thread and discouraging others from working on any other attempts to come up with a solution.
  4. Firmware

    I'm trying to understand this, you're worried about faceplants caused by cheap motor controllers, but you're opposed to more reliable ones because hardware must be even cheaper than the ones that already fail? Therefore the solution is to not ride EUCs? What kind of logic is this?
  5. Firmware

    Well that's the problem, everyone gave up because he basically sabotages the project. As soon as I showed my controller running a motor his reaction was to start attacking me in the thread and start spreading slanderous accusations that I was going to steal peoples code and use it for some closed source product. Even on those microworks controllers there's already existing options for running FOC on stm32F103 MCUs but those aren't allowed to be used because of unknown reasons, anyone with programming experience is told to work on creating an entire FOC control system from nothing which realistically is too hard for anyone without significant engineering experience, so it goes no where, they get burnt out and stop working on it. I even had a person PM me complaining that they thought he was just doing online advertising for various chinese parts manufacturers and that they didn't believe there was any actual realistic plans to ever release a working EUC firmware. People have tried asking him politely about various issues many times however he just ignores them or becomes hostile. I don't understand what he wants, sometimes I get the impression the microworks thing didn't work out as planned so no one else can be allowed to succeed. Even just a few posts up hes now FUDing EUCs saying they're too dangerous and everyone needs to ride chinese ebikes instead? He keeps telling people to buy those $14 36v ebike controllers as if they can somehow be used for EUCs in the future, it's physically impossible, totally dishonest and misleading.
  6. Firmware

    If you never discussed the hardware I was building why exactly were you demanding access to the prototype hardware design files in exchange for assistance with software? The VESC price thing isn't entirely true either, early on in the thread others were telling you where you could buy chinese VESC clones for $50 or $60, you just ignored them or dismissed them as the VESC is unsuitable for EUC due to 60V limit. Every time anyone tries to find an open solution for hardware the reason why it's not good enough changes but the solution always remains the same: everyone must purchase proprietary hardware from specific chinese vendors. Those $15 controllers can never be used for an EUC, implying you can get an EUC controller similar to what is found in the 30km/h controllers at that price is totally unrealistic. Some of the higher voltage controllers you have suggested are even more expensive than the microworks models while lacking an IMU and being unable to even fit in EUC cases. Low cost hardware can easily be designed but because you always change the criteria of what is acceptable when any solution is offered it gives the impression you are focused on selling chinese hardware and opposed to open source.
  7. Firmware

    Surely you can see how telling someone to invest time making hardware then waiting almost a year until it's ready only to say "oh I changed my mind" is maybe a little bit offensive? Telling people you are going to do something then refusing to do it isn't "evolving your opinion" it's outright lying and dishonest. It's not like you got busy with other things or no longer have time to work on it, you specifically chose to screw over everyone else for whatever reason. Look back throughout the thread, it's 50 pages of many people working on it that would always help you out with motor control information or electronics when possible, yet when the situation is reversed you will never help anyone else. You have the nerve to call me complaining "misleading and unfriendly" your own posts explicitly state you want people to develop open hardware then you change your mind and hurl insults accusing people of some conspiracy to steal open source stuff. How do you possibly justify your behavior? I know english isn't your first language so I'm willing to attribute it to misunderstanding. You keep saying you have explained your reasons, this is completely untrue, you were fine with the price of the microworks controllers and I have repeatedly said I'm fine with designing you low cost hardware only to be ignored. Please clearly explain from your perspective what the problems are and what you think you meant when you were telling people to work on custom hardware.
  8. Firmware

    It looks exactly what you would expect when the hall sensor readings no longer match the q axis due to phase lag and various changes that occur as current increases. The EUC motor is doing the same thing when you run it at higher speeds just not to the same degree. I'm still confused you spent a year telling everyone you wanted open hardware for EUC and electric vehicles and encouraging people to develop. Now you hate open hardware? Did you forget you had said all that or were you just lying when you said you wanted open hardware and would help work on the software? Very confusing.
  9. Firmware

    Yes technically "doing FOC" is quite different from making a useful FOC controller as I have tried to explain over and over again. It's a dead end using old 8-bit micros, a decent MCU costs $10. Using low cost controllers is not low cost because you will have to spend more money on every other component in the vehicle. None of those cheap ebike controllers have any chance of working in an EUC, even ignoring voltage problems, poor quality controllers are not something you want on an EUC where failure = faceplant. I don't understand why you refuse to work on anything that has a possibility of making a working EUC controller? There's approximately three decades of scientific research detailing how to create FOC controllers based around clarke and park transforms + SVM, trying to invent your own system is crazy and incomprehensibly wasteful. With your experience in embedded programming it would take very little time to make a functional EUC controller if you didn't ignore all conventional FOC development.
  10. Firmware

    That's microsemi not Onsemi. It's most likely the motor values are are in the speed controller as the document is for a specific kit that comes with a motor. I read up on it a little more, technically you could call a controller that ignores motor flux and resistance while using physical sensors FOC, however as I said earlier without anyway to compensate for phase lag it will no longer align with the Q axis once moving. For direct drive servos and gimbals it's fine as they rarely exceed 1hz but not vehicles. Basically the efficiency and performance will be bad to the point batteries and motors will have to be larger to reach the same level of performance. No one does it anymore because proper controllers are far cheaper than motors and batteries. I was looking at some older FOC systems from before 32bit MCUs were common they relied on various hacks like switching to 6 step BLDC once moving or gate drivers that could be configured to shift the sinewaves based on frequency.
  11. Firmware

    So where are the OnSemi and Ti examples of FOC that do not rely on know motor inductance and resistance values to determine magnetic properties? Saying you can perform FOC on a very slow 8 bit microcontroller without needing to know any of the motor variables is a very large claim but you aren't providing anything that supports what you are saying.
  12. Firmware

    Again where are you getting this idea? Can you link to Onsemi and Ti employees saying you do not need clarke and park transformation to perform FOC?
  13. Gotway ACM just died @ 30kph+

    Sounds like overcurrent limit was hit. Could either be the motor controller or battery BMS current limit. At lower speeds the battery does not have to supply much current to generate large amounts of current in the motor. At 10km/h if 30 amps of current is needed to stay upright the motor controller takes 70V 10A from the battery and converts it to 23V 10A. Running close to full speed the motor requires the entire 70 volts or so, if it needs 30 amps to stay upright the battery will have to supply that much current.
  14. Firmware

    Where? If you're talking about that microsemi FOC guide, it's for a cortex-m3 + FPGA it's using the FPGA to do the complex FOC calculations. At no point does it suggest you can delete all the FOC sections.
  15. Firmware

    That image has the hall sensors feeding angle data into the park and inverse park calculations. Unless I'm missing it somewhere I cannot find any clarke, park or inverse park transformations in the code you made for the 8 bit controllers. If there's no calculation of the magnetic fields you can't have "Field orientated control".
×