Jump to content

lizardmech

Full Members
  • Content count

    709
  • Joined

  • Last visited

Community Reputation

665 Excellent

2 Followers

About lizardmech

  • Rank
    Advanced Member

Profile Information

  • Location
    Australia
  1. Refreshing honesty from InMotion

    Sucks that they had to pay solowheel 1.1m but they didn't have much choice, dealing with patent troll lawsuits in the US is something like $10m minimum and if you win you don't get anything back if you win. Though the marketing people sound like they were even more painful. I don't think the solowheel brand has a future, the patent trolling made their brand toxic among enthusiasts and they blew any mainstream appeal by failing to release newer models or reducing prices to be competitive despite having a headstart. The solowheel brand is worth $0 in my opinion.
  2. self made euc

    I just use these mostly. They come with a MCU and debugger on one board, you can get 3 phase inverter add one boards for about $50 as well. Compiler and IDE is free these days, Ti have their code composer studio thing which is a modified version of eclipse and GCC configured for their MCUs. https://mouser.com/ProductDetail/Texas-Instruments/LAUNCHXL-F28069M STM boards are similar with on board debugging, there's many options for compiling for those since they are just 32bit ARM code, IDEs I think you can chose between eclipse or various others. Most of the time I just build straight out of linux via GCC for the STM ARM MCUs. Pretty much any of the STM32F4 variants are fine. This is the closest example I have found to code suitable for a unicycle this one uses brushless gimbal motors, the motor code is different but still closer than the more common slow moving geared brushed DC motor balancing robots, the TLDR more or less is you need to add compensation for reduction of torque as RPM increases, the code is pretty lightweight so any of the 32bit motor control MCUs should handle FOC + balancing without any issues. http://www.instructables.com/id/Brushless-Gimbal-Balancing-Robot/
  3. New Inmotion V10 (V8 Fast)

    I'm guessing they have a 7th mosfet acting as a on off switch for each motor inverter since mosfets fail open. As I said a few times in discussions about EU proposed regulations, I'm uncertain if it actually works, aerospace, defense, automotive and medical systems have trended towards having one highly reliable system rather than multiples. If it can actually prevent a faceplant due to a fet failure while moving it's a good idea if it can't and only means you can still ride home after the faceplant it's a bad idea as you have effectively doubled the probability of a failure with no increase in safety. I was never able to find any sort of demonstration of the dual motor windings on the segway working during a hardware failure. Did inmotion say if they had tested if it works in the event of a failure while in use?
  4. self made euc

    The main thing is picking a MCU with robust motor control software ready to go, the unicycles need a decent FOC motor controller to run well. Texas instruments and ST micro both have decent motor control options, they aren't 100% open source as the sensorless motor observers are in compiled libraries but you can still have the rest completely open you can still upload it to github and anyone can build it. They're fairly barebones they can detect motor parameters and spin the motor in debug but there's a few things you would ideally need to add such as separate current limits for motor current and battery etc. There's the open source VESC software which is quite good the downside is it's extremely complex and not really documented, the person who made it was going to add support for 6 axis IMUs but he doesn't have much time to work on it so it may not happen for 12 months or something. I found the texas instruments motor control to be the best of the commercial options I tried, to get it working all you would need to do is get the IMU working over I2C and have the balance code set the motor torque value in the provided torque control loop. There's not too much code needed for the balancing, besides filtering you need to have offsets for the gyro as it won't be perfectly level and the balancing code needs to compensate for the decrease in torque as speed increases.
  5. self made euc

    I actually made a whole bunch of motor controllers I was hoping to use for an open source unicycle, I completely designed all the 3 phase inverter and hardware needed for motor control. I had it running the unicycle motors with no issue but I could never find anyone to help finish the software, I don't have enough embedded programming experience to do it. I more or less know what has to be done but getting it all together into working firmware is difficult.
  6. Monster Burns Up On Hill Climb

    Could be it's just raw motor phase current and the other brands are calculating the battery current being used instead.
  7. Monster Burns Up On Hill Climb

    It may not draw more than 40A from the battery but the motor is capable of transforming it to very high currents at low speed, at 20% speed it's capable of converting 40A into 200A. The load does get shared around however at one point one phase and associated components will take the peak current in the cycle. It looks like the high side fet is blown here though, maybe the motor phase hit the mosfet driver as it came loose and shorted it. A motor phase coming loose while under load can also potentially generate hundreds if not thousands of volts if it were the one connected to ground, motor inductance resists changes in current so voltage will go up or down depending on the condition.
  8. Monster Burns Up On Hill Climb

    Those mosfets are package limited to 120A even though the silicon is rated for 300A or so. Gotway didn't read the datasheet I suppose.
  9. Firmware

    It should work provided communication between the balance controller and motor controller is possible, the only thing that could become an issue is latency and timings on the various MCUs. I found this the other day, it was quite similar in function to colton code you adapted for your ebike stuff. Runs 2 BLDC + motors + balancing algo but the motor code and balance code were quite closely coupled as torque compensation was required. Still I think this is the only arduino balancing robot using 3 phase brushless motors I have seen that works quite well. The others I have seen always use DC or stepper motors, the brushless attempts were always very wobbly or only manage to work at 1kmh presumably due to torque compensation issues. Another thing I found interesting from some open gimbal stuff is apparently 6 step BLDC is not viable for gimbals or balancing vehicles theres just too much cogging unless you build a motor with hundreds of poles. http://www.instructables.com/id/Brushless-Gimbal-Balancing-Robot/ Though this robot looks pretty good I imagine there's a few things balancing vehicles would have to deal with, the robot has overwhelming amounts of torque for its weight so running openloop motor control is viable as there's no real chance of it de syncing. Secondly the faster EUCs may have to manage phase lag due to higher RPM. This matches up with EUC hardware. The early models are most likely running sensored LUT based sinewave controllers, while the addition of ACS current sense on 2 phases would make sense if they needed to switch to FOC to mitigate hall sensor issues and phase lag. It would be more obvious on EUCs as they have smaller wheels than ebikes but the same number of pole pairs resulting in higher ERPM, this would explain why they didn't just reuse existing ebike controllers. Even with high RPM middrive motors for ebikes they have far fewer pole pairs so electrical RPM is likely still quite low.
  10. Firmware

    Also why are you suddenly angry at me, you ask if the open ebike firmware has reverse (which it doesn't) and you said the existing controllers you own aren't viable, I don't quite get how trying to suggest cheaper and easier options as you wanted is somehow calling you an idiot?
  11. Firmware

    All I'm suggesting if you want a quick and easy motor control solution arduino + chinese ebike controllers is perhaps the most difficult and time consuming way to go about doing it. Even for small little projects balancing or not. I have seen a decent arduino balancing robot but it had the arduino directly controlling the the power stage using LUTs to generate sinewave control as it was controlling the motors it was able to compensate for torque changes across motor RPM.
  12. Firmware

    I get what you want to do but arduino + controllers should be more work and time not less than the other options. Assuming you use an arduino + generic ebike controllers you will have to run the balancing code, output 2 PWM signals and somehow level shift them to the voltage the range the controller expects, then you have to convert it into an analogue signal via a filter which likely introduces latency. Then rework the balance code to compensate for any latency or quirks with the controller inputs. Then even after all that is done the balance controller has no idea how fast the motors are turning and as torque and difficulty in remaining upright varies with speed I'm uncertain if the control loop can function reliably as an open loop system. In comparison to doing it with MCUs that already have motor control code ready to go, all you need to do is get an IMU working via I2C, write the balance control loop and have it set the required torque value. If any compensation needs to be done for motor variables you have access to everything already.
  13. Firmware

    The Ti dev kit + 2 motor drivers is cheaper though, even two chinese vesc clones are only marginally more than those. I don't really get why people think arduino + generic chinese controllers are easier doing it that way means no access to ERPM, current or duty cycle data for the balancing code. Multiple MCUs controllers could work if you write the firmware for everything so they can communicate with each other but operating the motor controllers as dumb components in an open loop makes no sense.
  14. Firmware

    To put it into perspective, 500 x $65 is $32,500 USD, you could easily hire developers to write open EUC firmware, design a custom board and do a 500 unit batch for that much money.
  15. Firmware

    500 units minimum order though. Looks like they aren't making them unless someone orders a large batch.
×