3D Brushless Gimbal

Status
Not open for further replies.

jwatte

Well-known member
Long description, so I'm summarizing the questions from the bottom here: (See below for details)

  1. Does the Teensy 3.2, 3.5 or 3.6 have enough timer hardware to run three channels of current-control BLDC?
  2. If so, are there software libraries that make configuring such timers easy?
  3. If hardware but no software is available, where should I be looking to start driving the hardware peripherals myself, and what other Teensy functions might that hardware interfere with?



I'd like to build a custom sensorless Brushless Gimbal assembly.
The way these work is:

  • There are 2 or 3 axes of freedom in a Gimbal mechanical assembly (I've built custom mechanical assemblies before)
  • Each axis of freedom is driven by a high-pole-count brushless DC motor
  • The BLDC is used as a multi-phase stepper motor (in fact, there really isn't a difference between these configurations) in open loop configuration (sensorless)
  • There exists one three-phase driver per BLDC output
  • Each driver has at least three PWM inputs (for UVW phases) and possibly also a global enable/disable input
  • The center of the Gimbal (the stabilized mass) has an IMU attached (at least a 3D gyro; typically also accelerometer and perhaps magnetometer)
  • A controller board reads the IMVU at high rate and runs a Kalman filter to calculate pose and acceleration of the stabilized mass
  • A PID controller outputs position-delta information to the motor driver software
  • The motor driver software modulates the PWM to move the BLDC motor to the appropriate position for the stabilized mass to stay at the desired attitude

In my application there are three additional concerns:

  • I'd like to micro-step the poles of the BLDC motor -- let's say I want a 25/75 duty cycle ratio between phases U and V (with W being idle in this case)
  • I want current control, because maintaining level altitude needs less force (and thus less current/power draw and heat) than compensating for actual movement. The motors I use can draw > 20A but typically I need 1A for maintaining.
  • This is open-loop driving the motor (closing the loop only with the IMU) so I don't need to detect EMF zero crossing, as I hold position, not velocity

I will build my own PCB for the motor driver chips and MOSFETs needed. I've built power-driver PCBs before.

What I would like help with is understanding exactly how much support there is for something like this in the Teensy infrastructure.
Specifically:

  • I need three separate PWM generating output timers, for the 3D control.
  • Each timer needs a separate "active range" -- I want U and V to be complementary, not be active-high at the same time, while W may be low. After commutation, I may get U low, V and W complementary, and so forth.
  • For current control, I may want the complementary control to not sum to 100% duty cycle. I e, if the timer runs from 0 to 255, I'd like the U output to be active in the range (0,20) and the V output to be active in the range (128, 148) for a 50% micro-step between U and V, and a 15.6% duty cycle.
  • An alternative is to use a fourth PWM channel that modulates ("chops") the control signals to a given duty cycle. However, because I want UVW control to be ultrasonic (in the best of worlds,) to get reasonable resolution in chopping, it would have to run at 200 kHz or more, putting more stress on the gate drivers.


Does the Teensy 3.2, 3.5 or 3.6 have enough timer hardware to run three channels of this?

If so, are there software libraries that make configuring such timers easy?

If hardware but no software is available, where should I be looking to start driving the hardware peripherals myself, and what other Teensy functions might that hardware interfere with?
 
Does the Teensy 3.2, 3.5 or 3.6 have enough timer hardware to run three channels of three-face BLDC motor drivers?

If so, are there software libraries that make configuring such timers easy?
 
I don't know, because I need control of the phase of the timers.
It says the 16-bit timers are "very flexible" but doesn't give any more details.
It talks about analogWrite(), which doesn't give any phase control.

In the best of worlds, I could use three timers (16-bit or 10-bit could both work) and I could tell three pins per timer to each go high at timer value A{0,1,2} and go low again at timer value B{0,1,2} where the compare values are individual to each of those pins.
As long as I had that control, I could do what I needed.

The Kinetis documentation I've found is "here's how to fill out a form in Eclipse" like this nightmare: https://community.nxp.com/docs/DOC-95537
Totally devoid of useful information.
I could go look up the specific data sheet of the specific chips on the Teensies, and then find the specific timers, and then figure out how those specific timers map to the Teensy support libraries.
Or I could ask here, where presumably someone already knows how these timers work and what they can do!

(Page 9 of this is a little more helpful, but doesn't talk about possible interactions with Teensy code:
http://cache.nxp.com/assets/documents/data/en/application-notes/AN5142.pdf )
 
Last edited:
If you want phase control for the PWM channels, you can use pairs of FTM timer channels (you can specify turn-on and turn-off timing). That means, you would need 2 * 3 * 3 = 18 FTM timer channels (Teensy 3.5 / 3.6 have enough). You will need to use multiple FTM timer modules, but the counters can be synchronized.

Deadtime control is supported as well, but I would use a driver that takes care of that, e.g. DRV8305 (which would also have a current shunt amplifier).

Look at the manual, 'FlexTimer Module (FTM)' chapter, 'Combine PWM' mode.

I'm not aware of libraries doing what you want.
 
I checked the manual, and the key word is "flex timer module" as you said. If I can synchronize all those channels, that would work. If they would skew over time, though, I would perhaps be in trouble. Some kind of interrupt task that owns making sure they stay in sync would probably be a good idea. (Or at least, something that verifies they are in sync and then reports back and if it turns out they never, ever, skew during testing, then I don't need forced re-sync.)

The Teensy3.5 has two 8-channel flex timers (I only need 6) and two 2-channel flex timers. So, to drive 3D, I could use the spare 2 channels for each 8-channel FTM and an additional 2-channel FTM and do what I need.

Does any part of the Teensy library use any of the Flex Timers, other than the analogWrite() bits? For timing, or whatnot? Or do they all use PITs or similar?

The 8305/8303 is on my short list of possible drivers, yes!
 
I checked the manual, and the key word is "flex timer module" as you said. If I can synchronize all those channels, that would work. If they would skew over time, though, I would perhaps be in trouble.
They won't skew. Look at the manual, K66: '45.5.28 Global time base (GTB)'. The FTM modules need to be configured with same clock source, clock dividers and modulo.

FTM synchronization for register updates is described in app note AN4560.

Does any part of the Teensy library use any of the Flex Timers, other than the analogWrite() bits?
If you are concerned with conflicts, other core stuff doesn't use them.

There are various libraries using FTM, e.g. PulsePosition, FreqMeasure, TimeOne.
 
Status
Not open for further replies.
Back
Top