Jump to content

lizardmech

Full Members
  • Content count

    701
  • Joined

  • Last visited

Community Reputation

655 Excellent

2 Followers

About lizardmech

  • Rank
    Advanced Member

Profile Information

  • Location
    Australia
  1. 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.
  2. 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?
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Firmware

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

    @Tomek Trying to hack an arduino and existing controllers together is a dead end, the motor control software provided by MCU manufacturers is far easier to use. I know the Ti F28069 even has a dual motor FOC example running off the one MCU, I can't recall if the STM one has a dual motor version, NXP one doesnt. All you have to write for any of them is the code to talk to the IMU via i2c and connect your balance code to the provided torque controller. Here's a guy running 2 segways motors off the one f28069m
  9. Firmware

    Just get these + a mpu 6050 breakout board. Less than $100 and all you would have to do is get the mpu 6050 working via i2c then write balancing code. Probably not quite strong enough to ride an EUC properly but it would take little effort to get it working enough to kickstart a viable open EUC project. All the motor code is provided, I tried all the off the shelf motor control options, the Ti instaspin one is the most powerful still, the STmicro and NXP are a little more user friendly but lacking in documentation, less open and generally less advanced, the Ti MCUs are just much better at motor control overall as it was designed for motor control rather than being general purpose MCUs. https://mouser.com/ProductDetail/Texas-Instruments/BOOSTXL-DRV8305EVM https://mouser.com/ProductDetail/Texas-Instruments/LAUNCHXL-F28069M
  10. Firmware

    The EUCs are definitely using inverted pendulum, I think the IPS brand name is even a reference to that. There's plenty of code examples that can easily be used, the problem as always is no one with programming experience is willing to work on open EUC firmware. I think once a very basic one is created it would be very easy for people to iterate on it and add features but with 3 years worth of posts and not a single person willing to write any EUC related code the thread just goes in circles.
  11. Social Media

    You need more interesting content, for chinese units there's always detailed teardowns, people testing them off road and on slopes and poeple testing them on dynos to see torque and power output almost as soon as they launch. At the moment for uniwheel there's just a few generic pictures and very basic riding videos.
  12. Spherical Tires for EUC

    I have seen a balancing robot using something similar online once. It used a spherical induction motor to allow rotation in all directions.
  13. An open letter

    Great that it got released. Any reviews or production units that have been pulled apart by owners yet? People will want to see more than manufacturer claims before spending money on a premium product. Hopefully @EcoDrift will review one.
  14. Firmware

    Is there any detailed pictures of the insidess and list of components for those 72V controllers? I would be hesitant to trust the ratings they provide.
  15. Firmware

    Depends on the reason for the voltage increase. If the motor remains the same increasing the voltage will give it a higher maximum RPM. If the motor has different windings for the higher voltage you can have the same original performance with lower currents which can be useful for unicycles where they're limited by wire thickness due to the axle. On the original VESC hardware one of the main components has a maximum voltage of 60V, it can't really safely handle more than 55V. Solving that limitation requires a complete redesign as I did. the austinglider looks interesting there's no technical information though, with the amount of vapor ware around balancing vehicles I'm always skeptical until they show proper details.
×