You got the wrong Matlab model there. Try this one:
http://au.mathworks.com/help/physmod/elec/ref/inductionmotor.html
Are you sure? I mean a permanent magnet motor surely is not an induction motor. Induction motor needs to create magnetic rotor flux in order to create torque, while a permanent magnet motor already has the magnets providing a constant flux.
Actually, I correct myself that this: http://www.mathworks.com/help/physmod/elec/ref/femparameterizedpmsm.html Would be the correct model for 3-phase BLDC motor.
That ones close too. But its defined in terms of flux linkage. Induction and BLDC motors are pretty much equivalent.
Okay, so. Discussed my motor theories with my electronics lab teacher and he agreed with all the hypothesis and also confirmed the 1st and 2nd hold true. I also figured out how to model the regen braking.
The whole point of my theory is to mathematically figure out the AC/DC currents and power, when we know the characteristics of the motor (kV, pole count and internal winding resistance), it’s RPM, battery voltage and duty cycle. This means my controller has to only be able to measure the battery voltage and motor RPM. And everything else is configured as a constant value.
1 Like
I’m looking forward to seeing that implementation!
I have already ordered the PCBs for the next iteration of my controller. Currently waiting for the boards to arrive, but I’m having a delay with Digi-Key until 28th, because unfortunately they have a backorder on one of the components for the board.
It’s also going to take time to learn the ARM-platform. Lots of testing, debugging and blinking LEDS with registers, but I believe it will be worth it in the end (because otherwise I would have stayed with the familiar AVR-family).
Also development team news. I have interviewed the 5 interested students and 3 has been selected into the team. I held an orientation with them on Monday. Basically going a bit deeper with what we’re trying to achieve and looked at different executions of products available on market today. I have established comms with the group (telegram) and we meet on Mondays for face-to-face time. I’ll update things as we start the progress.
Control scheme wise, I also brought it up with the teacher and we agreed that speed control would most likely feel the most natural to control the board. So I’ll use the algorithm to figure out the AC/DC currents and make sure they stay within safe limits, so we don’t burnout our motor or battery.
Speed control as in RPM control? Torque control is the one that feels more natural to me and as far as I’m aware to most people here.
Yes.
I know that constant torque = true constant acceleration, but RPM control has a bit easier time to truly control the speed at which you want to move.
I don’t actually know exactly how it works on the VESC, but I hope you could elaborate on that. How do you control speed with VESC? Because as far as I know, the throttle position is linearly linked to the motor amps and motor amp limit. AKA 100 Amp motor limit, 50% throttle = VESC will try to maintain 50 Amps of motor current.
Because the problem I see with torque control is that it’s controlling the rate at which speed changes, at least in principle. But as an example. if your board tops out, let’s say 40 km/h, at what position do you have to hold the throttle to go 20 km/h? because it’s not 50%. With speed control it would be 50% This is what I’m interested in when controlling torque and speed control.
Have you seen Benjamin’s comments about the different control modes at http://vedder.se/2015/01/vesc-open-source-esc/?
Funny, I have that webpage bookmarked, but don’t remember reading or seeing that “control mode” section before 
I guess I’ll implement at least the torque and speed modes and then add a configuration menu to the smartphone app, where people can decide which they want to use, along with max speed and max torque settings.
Also PCBs arrived today!
1 Like
Rage… RAGE!!!… *Sigh, disappointment in myself…
Finally, parts arrived for the new motor controller and I was going to keep myself busy with it the whole weekend… Or so I hoped.
See if you guys can locate the problem in the picture attached below…
Turns out TQFP packages can have different lead pitches… The PCB has a 0.8 mm lead pitch and the ARM MCU meant to be used has 0.5 mm pitch… dangit!
1 Like
Got the new boards today and immediately got to work assembling it and I’m happy to say it’s ALIVE!
I’m finally able to start messing around in the ARM architecture and start learning it 
Plan is first to learn how to use the ARM’s peripherals and then copy the functions over from the older controller and start driving some light loads.
Will update as things progress!
Update time!
Motor is spinning, timers are running, LCD-display is outputting, AD-conversions are converging, Bluetooth communication works and interrupts are being serviced!
Still some work to do before going for a test ride, but I’m aiming to do it this week!
I also met up with our dev team’s smartphone guy and we did some test transmits between his WIP phone app and the motor controller and we had working comms! We then discussed a bit about the packet framework for actual use case and developed a first draft of the protocol. Bluetooth will only be used for non-critical communication! If you wanna check out some concept mock-up pictures for the smartphone app, check here https://drive.google.com/file/d/0B45b0uNJKZ0eQ3VQMUFFRXN1RDA/view?usp=sharing
Our remote controller developer is prototyping with the Nordic nRF24-modules (2.4 GHz RF), for more stable and reliable remote connection.
7 Likes
Nice thread, once again! You should have written more precisely it is DIY controller or something I think not that many people develop their own controllers 