slightly weird behaviour with new motor

Also, it keeps crashing out of the debugger with "Error -1135 @ 0x3F6772".

looking through user.h

I'd change the PWM to 45 instead of 50. Just to get the timing better and lower MIPS.

#define USER_PWM_FREQ_kHz                (45.0)

this is too low for your low flux motor

#define USER_IQ_FULL_SCALE_VOLTAGE_V      (24.0)

it's really borderline for a 0.002 V/Hz motor. I am guessing you aren't running 24V, so make sure to lower this to your bus voltage. I would set to (12.0)

This will give you a bit more flux resolution

bottom line, your motor has almost no information coming back from it. TINY amount of flux and SUPER SUPER low Ls which causes terrible short circuit current, which makes it extremely difficult to sample the currents.

This is the type of motor that really doesn't lend itself to a motor circuit based observer/estimator nor closed loop current control.  It will be extremely challenging. I've seen them still work, but you don't get AS many of the benefits of FOC or InstaSPIN as you normally would.

That sort of makes, except that at 10-15krpm where I'm seeing the torque and current fluctuations I should already have a pretty decent back-emf signal.

Also, since USER_IQ_FULL_SCALE_VOLTAGE_V is nothing to do with the hardware scaling of the ADC and is just to do with scaling to IQ units I have another question. Some of your MCUs support proper native floating point. Shouldn't it be possible to avoid all of this messing around with IQ units on those MCUs? Wouldn't this improve the accuracy or at the very least eliminate a lot of user errors (and presumably make it easier to make a single motor controller that was relatively independent of the motor)? Does it come down to the relative speed of floating point versus fixed-point arithmetic?

I think what you're saying is that my problem is mostly down to the absurdly low inductance. I have to admit that I'm pretty bad at control loops, sampling and filtering theory but it almost seems like we should be integrating the signals somehow rather than instantaneously sampling them/

Thanks Chris - that's all really helpful as usual. Sounds like you have some more interesting developments in the pipeline.

Do you have any idea what is causing the debugger to crash out? I'm assuming that overflowing the IQ variables wouldn't do that. I suppose that if I'm pulling the supply voltage too low then the MCU could be dropping out. Are there any error conditions on the DRV8301 that would do that? What about exceeding the processing capacity of the MCU?

I'll try to post a YouTube (or something) video of my RC car project sometime (such as it is). I've still got the hub motor version but I'm concentrating on a new gearbox version now (mostly because the hub motors were vulnerable to dirt and damage from collisions and because they required expensive and fragile custom 3D printed wheels). The current version uses 6320KV inrunners and InstaSPIN actually drives these really well (it will happily do 85krpm and 100krpm/s). I'm only looking at the Axi motor to perhaps improve efficiency and reduce noise.

I'm not kidding when I say it drives the current motor really well. Having increased the motor current to 15A it will now take off from a complete standstill perfectly smoothly (no forced angle) on just one motor! That's pretty good considering that there are meant to be four of these motors and they are geared for a top speed of well over 80mph! And at the low speed end FAST seems to be working down to about 200rpm (which is something like 10cm/s).

Sam Hawker said:

Do you have any idea what is causing the debugger to crash out?

this is almost always due from a low voltage brown out due to current demand spike (likely your case) or Bemf over-voltage.  sometimes it is due to noise / bad ground, but this is usually in higher voltage systems only.

Sam Hawker said:

What about exceeding the processing capacity of the MCU?

No, you would see this immediately and at any speeds if this was a problem.

Sam Hawker said:

I'll try to post a YouTube

Yes! Can't wait.

Sam Hawker said:

uses 6320KV inrunners

wow! I didn't even know they went this high.  4600 KV from Tekin is the largest I've found and run.

Sam Hawker said:

That's pretty good considering that there are meant to be four of these motors

I think where you will run into more challenges is trying to synchronize the speed of all the wheels if they are driven independently. Small differences in speed or the trajectory / timing can cause some non ideal driving performance.

I'm really curious to see if this is an issue in this application for you. I know in a full size vehicle - where slower launches / speeds are required it is a real challenge for sensorless.

I'm expecting it to be a challenging project but one of my aims is to create a powerful hardware platform at a cost that makes it reasonably accessible so that other people can try developing their own algorithms (but at the same time I'm a software engineer and a physicist so I want to see what I can do too). There are a few other people doing similar things (e.g. https://www.youtube.com/watch?v=ET1HEyqEQJQ). I'm following a very "ground up" approach though, which means getting the mechanics right, then the speed controllers and then the overall controller.

I'm still having problems with it crashing when I try to run my outrunner at high speeds. I'm not 100% convinced that it is related to current spikes - I've tried reducing the supply voltage slightly, reducing the speed gains and accelerating only very gently and it just seems to crash out when it reaches a certain speed.

But I think I might be trying to exceed the hardware limit of the BOOSTXL. I've set USER_IQ_FULL_SCALE_FREQ_Hz to the hardware limit according to the spreadsheet but I notice in one of your posts that this only allows for frequencies up to 1.98 * USER_IQ_FULL_SCALE_FREQ_Hz. That would be about 23.5krpm for my outrunner. It seems to crash around 18-20krpm.

I have much more headroom with the inrunner because it has 7x fewer poles (whereas I'm using a gear ratio only about 3x different).

there is a variable limit for USER_IQ_FULL_SCALE_FREQ_HZ < 4 * USER_VOLTAGE_FILTER_POLE_Hz

with InstaSPIN-FOC (not -MOTION, it does a check) you can still command exactly up to 2x the FULL_SCALE_FREQ.

That's why I put 1.98 in the spreadsheet, just to have some buffer.

That's a variable limit though, nothing really to do with the motor or hardware which could have it's own issues.

Are you doing loaded tests or just no-load?

Sam Hawker said:

up to 1.98 * USER_IQ_FULL_SCALE_FREQ_Hz. That would be about 23.5krpm for my outrunner. It seems to crash around 18-20krpm.

What is your FULL_SCALE_FREQ?

How many poles on this motor?

What is the Kv of this motor?

What is bus voltage?

Can you run to the full speed you expect in proj_lab05a in just torque mode?

I'm testing the outrunner with no load.

I think I still have USER_IQ_FULL_SCALE_FREQ_HZ = 1386.0. From memory, I thought this was the maximum allowed according to the spreadsheet but if the filter pole is 364.682 then presumably the limit is actually 1458? I'll have to go back and check. It's somewhere in that range though.

The motor has 7 pole pairs and 1950rpm/v.

The bus voltage is 12v and I'm using an over-modulation of 1.33.

I haven't done the torque mode test - I'll let you know.

23.4 KRPM is your maximum with 12V and 100% duty cycle.

That's 2730 Hz though.  Pretty dang high. 

Per the spread sheet you need to run controller/estimator at 8x the max frequency, so that puts you at 22 KHz loops. That's not going to be possible on at 60 MHz device.  You can do it on the much more expensive F2806x series.

Essentially, with the 60 MHz device you can realistically run up to about 2 KHz frequencies.

Thanks Chris. I actually have a F28069MISO ControlCARD that I could potentially try hooking up to the BOOSTXL.

So, is it going from 60MHz to 90MHz that is important or is it the CLA and FPU features? Really my question is will the top-of-the-line F2806x have enough capacity to handle two motors running at 2.7kHz? My main concerns are PCB size and weight and power consumption more than component cost. Given the production volume I expect the cost of assembling the PCBs to significantly exceed the cost of the components. I might even be able to justify using hall effect current sensors (especially if I only need them on two phases and if it means I can replace the DRV8301 with simpler gate drivers since I won't need the current shunt amplifiers anymore). I'm a bit worried that straying so far from the TI reference designs might increase the number of design iterations though.

Sam Hawker said:

hanks Chris. I actually have a F28069MISO ControlCARD that I could potentially try hooking up to the BOOSTXL.

we have a 69M LaunchPad coming out in January...we started working on this early in the year and it's been a nightmare to get them built.  I've already tested them though and they work great.

Sam Hawker said:

So, is it going from 60MHz to 90MHz that is important or is it the CLA and FPU features?

It's just the MHz for MIPS to run the control loops faster.  Running the sampling/control at 7-8x the max frequency is straight from control theory, nothing to do with our solution specifically.

The CLA and FPU aren't even used on the F2806x.

Sam Hawker said:

Really my question is will the top-of-the-line F2806x have enough capacity to handle two motors running at 2.7kHz?

It will be tight on MIPS I think with both at 16 KHz...if so you won't have much background time left for anything else.  Also, we haven't released a software project with two motors running. It's complicated and we just haven't made time to make a clean project.  We do have this running in production products though (compressor + fan) but they run at lower frequencies hence lower rates.

Sam Hawker said:

I might even be able to justify using hall effect current sensors (especially if I only need them on two phases and if it means I can replace the DRV8301 with simpler gate drivers since I won't need the current shunt amplifiers anymore).

Hall sensors make it easier, but really haven't made that much of a difference in my experience with other customers. What makes the current look nicer (hence more efficiency and more stable current control) is to put an inductor between the inverter and the phase voltage measurement. There's a good thread on this topic I've posted several times with pictures and results (running over 4 KHz)

Sam Hawker said:

I'm a bit worried that straying so far from the TI reference designs might increase the number of design iterations though

That is true...I wouldn't do it. The BOOSTXL-DRV8301 is a very robust design.

Okay, sounds like trying to get two of these motors running on one MCU is going to be pushing it then. That probably means I need to stick with the inrunner or switch to trapezoidal commutation.

I think I saw the post about inductors. This one right?

http://e2e.ti.com/support/microcontrollers/c2000/f/902/p/339361/1242590.aspx#1242590

But when I looked for inductors I couldn't see any way I could add a meaningful amount of inductance without introducing a significant amount of series resistance. It didn't seem like it would be a net gain in efficiency.

yes, that's the one

we haven't tried to run efficiency numbers...but it certainly makes the current waveform nice, which has to help. the dominating resistance will be from the motor anyways.

I might have missed something totally obvious but when I look for power inductors most of them have lower L and higher DCR than my motors. A few of them are better but they're enormous. You say that these hobby motors have much higher R/L than they need but isn't that basically because they can't make it any lower (just like the inductor manufacturers can't)? Or rather, they can but it would make them heavier.

Leaving aside the problems of low inductance and current spikes I think I might have found a solution to my excessive frequency problem. I've found an outrunner (http://www.scorpionsystem.com/catalog/motors/hk22/HK-2216-16) which has only 6 poles instead of the more normal 14. Taking into account the different gear ratio it should look (to the speed controller) almost exactly like my 2 pole inrunner. The advantage over the inrunner is that I won't have anything screaming along at 60krpm+ and the gear ratios are much more comfortable.

Sam Hawker said:

I might have missed something totally obvious but when I look for power inductors most of them have lower L and higher DCR than my motors

there are some small ones at 50uH, but they don't handle much current. These work well for small current motors. For these hobby motors though you're right, to support 10 or 20 (or even higher) amperage the inductors get enormous....

Sam Hawker said:

You say that these hobby motors have much higher R/L than they need but isn't that basically because they can't make it any lower (just like the inductor manufacturers can't)? Or rather, they can but it would make them heavier.

I've asked some of the motor manufacturers why they make them like this but haven't gotten a good response.  A high R / L is necessary for open loop stability, which is the typical way these are driven. And they keep Rs as low as possible to reduce I2R losses, so that drives a ridiculously low Ls.  We think they could make more normal Rs / Ls with slightly larger Ls. This should mean the air gap can be larger and could potentially be made even cheaper...but we don't really know all the costs associated with the manufacturing process.  I think the volume drives most of the cost so doing a "special run" would probably end up being more expensive.  But, if we could get EVERY ESC to use InstaSPIN..... :)

Another way to go might be to target a manufacturer like Castle Creations that are quite high end and only offer a limited range of motors and have their own ESCs. If they sold the ESC and motor as a matched pair...

that is one way...no comment.

we have some drones in the sky now with InstaSPIN and working on more, but I do agree that making the motors better now that there is InstaSPIN-FOC is a needed step in several markets to take best advantage of the technology.