Propeller 2 Live Forum - Early Adopter Series: Jon McPhalen's "Tao of Spin2 Programming"
(oh, they will probably eventually have it on the first post like the others, replacing the registration link..)
I didn't notice all those videos before.. either im blind or those were just added..
Great now I have to play video catch up.
Chip,
I think there was someone asking about using the smartpins to read a 3-phase encoder ... and you didn't know what it was, and kind of apologised at the end. I'll say right now, there isn't really such a device.
What the question was about is commonly called "hall-sensors". They are used on older 3-phase brushless motors, aka DC-brushless. The purpose is solely for absolute commutation of the rotor - not as an incremental position counter. There is only six hall steps in the rotation, very low resolution. The motor drives for powering such motors are low complexity analogue designs. Not a DSP in sight. A normal incremental quadrature encoder, with 1000s of steps per rotation, is also attached to these motors.
More modern servo motors (since the 1990s) use a DSP in the drive with a resolver on the motor. The resolver supplants both the hall sensors and the encoder. These get the title of AC-brushless. Such drives emulate a quadrature encoder signalling for the servo controller. Many modern industrial encoders are actually emulating too - resolvers are just a lot tougher in construction, not to mention a single device can cover the gamut of desired encoder resolutions.
Chip,
I think there was someone asking about using the smartpins to read a 3-phase encoder ... and you didn't know what it was, and kind of apologised at the end. I'll say right now, there isn't really such a device.
What the question was about is commonly called "hall-sensors". They are used on older 3-phase brushless motors, aka DC-brushless. The purpose is solely for absolute commutation of the rotor - not as an incremental position counter. There is only six hall steps in the rotation, very low resolution. The motor drives for powering such motors are low complexity analogue designs. Not a DSP in sight. A normal incremental quadrature encoder, with 1000s of steps per rotation, is also attached to these motors.
More modern servo motors (since the 1990s) use a DSP in the drive with a resolver on the motor. The resolver supplants both the hall sensors and the encoder. These get the title of AC-brushless. Such drives emulate a quadrature encoder signalling for the servo controller. Many modern industrial encoders are actually emulating too - resolvers are just a lot tougher in construction, not to mention a single device can cover the gamut of desired encoder resolutions.
Thanks, Evanh. What should we be covering, if anything, then, for these resolvers/motors?
I've not gone that far sorry. I've been happy to stick with industrial drives doing that. ManAtWork has studied the workings for driving of 3-phase motors directly. Both motor types are readily available still.
Resolvers are a transformer tech with an excitation winding and a sine/cosine pair of signals returning to be processed. Presumably there is a defined relationship with the three motor phases. Excitation is an AC signal supplied by the drive and the sine/cosine is an amplitude modulation of the excitation frequency back to the drive.
With the hall sensor method, the sensors are mechanically matched to the motor phases. They're usually open collector 5 to 24 volt digital signals.
With resolvers you're essentially taking a sine and cosine analog input and trying to find the shaft angle. Seems simple in theory.
Now, resolvers are often multi pole, meaning there could be like 4 sensed revolutions for one actual shaft revolution.
As resolvers are analog pickup coils, they pick up everything and anything. Signals need to be heavily filtered (to remove modulation and wobble and cogging), but at the cost of lag. So then it needs a bit of dead-time compensation, adding overshoot.
Despite the seemingly glowing reviews here of robustness, resolvers are junk at acceleration critical, jerk-limited control. (Noise is 50 times higher than the acceleration signal, so in closed loop control motors hiss white noise).
Resolvers for whatever they "saved" in a few hundred dollars, added 2 months to a project early in my career. But I could see the allure of their cheapness to manager types.
As resolvers are analog pickup coils, they pick up everything and anything. Signals need to be heavily filtered (to remove modulation and wobble and cogging), but at the cost of lag. So then it needs a bit of dead-time compensation, adding overshoot.
Despite the seemingly glowing reviews here of robustness, resolvers are junk at acceleration critical, jerk-limited control. (Noise is 50 times higher than the acceleration signal, so in closed loop control motors hiss white noise).
I disagree. Yes, there is a lot of noise if you use a sample/hold ADC and randomly pickup spikes of a switching PWM power stage but you can avoid this by using a sigma/delta ADC with the sample period matched to the PWM period. With the P1 I got 16 bits resolution without any noise and without any additional filtering except the ADCs internal filters. They add ~170µs delay which is below the velocity control loop iteration period. My latest P2 design is a bit noisier (~15 ENOB), I have to find out why (higher clock or PCB layout?).
I like resolvers because the behave nearly the same across all manufacturers. Yes, you can get cheaper (absolute) optical encoders with high resolution theese days. But you need a complex communication protocol for them. Encoders with standard interfaces (BISS, EnDat) are expensive and cheaper ones use proprietary protocols which differ for different manufacturers.
I have drivers and example schematics for both P1 and P2. If anyone is interested we could start an extra discussion.
What the question was about is commonly called "hall-sensors". They are used on older 3-phase brushless motors, aka DC-brushless. The purpose is solely for absolute commutation of the rotor - not as an incremental position counter.
These sorts of motors are very very common in the small electric vehicle world. Electric skateboards, scooters and
bicycles commonly use these sorts of motors with the low res encoders. They are also commonly used in RC cars.
In most of these applications, a reduction drive is used so the even though they're at low res, thy end up with better resolution than used in many Parallax robots with quadrature encoders.
I think these encoders have enough resolution to allow one to control the speed of a motor and there is certainly enough resolution to provide good odometry data.
I doubt these are good reasons to accommodate these encoders in dedicated smart pin modes but these encoders are certainly very useful in robotic applications.
The three channel encoders can be read using normal quadrature encoder techniques but I lose resolution. I think the higher resolution offered by using three channels will have the biggest advantage at low speed. I'm hoping to use the encoders to provide smooth startup acceleration. This should reduce the likelihood of having someone thrown off the board from abrupt acceleration.
The nature of it being angular commutation means it's still only six steps per motor rotation! The step rate is so slow that software polling would breeze through it.
I'll say right now, there isn't really such a device.
These sorts of encoders are ubiquitous in portable electric vehicles. Quadcopters generally use sensorless brushless motors but RC cars often use these hall sensors. The encoders included in brushless motors I'm using in my current project, provide better resolution than the quadrature encoders used in the Arlo robot.
I have a hard time believing I'm the first person who wants to take advantage of these encoders for use in robotics projects.
I'll use the suggested strategy of polling the encoders as I have done using quadrature encoders on the P1. If the encoders could have been read using smart pins, I would have likely taken advantage of the capability.
I certainly don't think Chip should feel bad that these sorts of encoders aren't supported by the smart pins. I do think these encoders are useful in robotic projects using these sorts of brushless motors.
I'll use the suggested strategy of polling the encoders as I have done using quadrature encoders on the P1. If the encoders could have been read using smart pins, I would have likely taken advantage of the capability.
I've found a solution! But please continue this discussion in that thread because this here should be about the live presentations.
For those of you interested in watching Chip's Audio Effects with the P2 on this week's live forum, the YouTube video suffered from resolution issues again due to Chip's luxurious display.
This morning I did some video magic and was surprised at the results (I feel like a CSI lab tech now) and I improved the video from looking like the first three samples here, to looking like the second three samples.
I'll provide this back to Ken for upload to YouTube to replace the former video. Either I or Ken will let you know here when the improved video is posted.
Thank you from me as well. I had all sorts of computer and tablet problems when trying to watch live. I could receive audio over my tablet and my PC would crash soon after logging into the Zoom meeting. Now I can at least view the information after the fact.
Yep, but one of them died, so I've only got two now. Walmart doesn't sell the same 4K TV's, anymore, which I made these brackets for that keep them sitting on my desk like a tri-fold picture frame. They were only $249 each when I bought them 3.5 years ago. If 8k TV's were affordable, I could just use a single unit, as it would be equivalent for four 4k TV's.
Price is relative. 25 years ago, 20” VGA screens cost $3500 so thats probably equivalent to a ~65” 8K in today’s money. It’s just that prices have dropped so much we now consider 8K ultra expensive
The first 5MB HDD for Apple //e and /// cost $10K.
The updated P2 Live Forum: Audio Effects on P2 - Chip Gracey video is now on our YouTube channel; it's a much better viewing experience than before. You can also find it linked on our https://propeller.parallax.com site on the P2 page here:
They has been a fine mix between fantastic contextualized contents, at the "official" part, and many delicious "jam sessions", of all kinds and for all tastes, up to the end.
Comments
Propeller 2 Live Forum - Early Adopter Series: Jon McPhalen's "Tao of Spin2 Programming"
(oh, they will probably eventually have it on the first post like the others, replacing the registration link..)
I didn't notice all those videos before.. either im blind or those were just added..
Great now I have to play video catch up.
Tom
The current location is shown in this picture, which might look different after November 2020. But for now, this is where you'll find his resources.
Ken Gracey
I think there was someone asking about using the smartpins to read a 3-phase encoder ... and you didn't know what it was, and kind of apologised at the end. I'll say right now, there isn't really such a device.
What the question was about is commonly called "hall-sensors". They are used on older 3-phase brushless motors, aka DC-brushless. The purpose is solely for absolute commutation of the rotor - not as an incremental position counter. There is only six hall steps in the rotation, very low resolution. The motor drives for powering such motors are low complexity analogue designs. Not a DSP in sight. A normal incremental quadrature encoder, with 1000s of steps per rotation, is also attached to these motors.
More modern servo motors (since the 1990s) use a DSP in the drive with a resolver on the motor. The resolver supplants both the hall sensors and the encoder. These get the title of AC-brushless. Such drives emulate a quadrature encoder signalling for the servo controller. Many modern industrial encoders are actually emulating too - resolvers are just a lot tougher in construction, not to mention a single device can cover the gamut of desired encoder resolutions.
Thanks, Evanh. What should we be covering, if anything, then, for these resolvers/motors?
Resolvers are a transformer tech with an excitation winding and a sine/cosine pair of signals returning to be processed. Presumably there is a defined relationship with the three motor phases. Excitation is an AC signal supplied by the drive and the sine/cosine is an amplitude modulation of the excitation frequency back to the drive.
With the hall sensor method, the sensors are mechanically matched to the motor phases. They're usually open collector 5 to 24 volt digital signals.
Now, resolvers are often multi pole, meaning there could be like 4 sensed revolutions for one actual shaft revolution.
As resolvers are analog pickup coils, they pick up everything and anything. Signals need to be heavily filtered (to remove modulation and wobble and cogging), but at the cost of lag. So then it needs a bit of dead-time compensation, adding overshoot.
Despite the seemingly glowing reviews here of robustness, resolvers are junk at acceleration critical, jerk-limited control. (Noise is 50 times higher than the acceleration signal, so in closed loop control motors hiss white noise).
Resolvers for whatever they "saved" in a few hundred dollars, added 2 months to a project early in my career. But I could see the allure of their cheapness to manager types.
I disagree. Yes, there is a lot of noise if you use a sample/hold ADC and randomly pickup spikes of a switching PWM power stage but you can avoid this by using a sigma/delta ADC with the sample period matched to the PWM period. With the P1 I got 16 bits resolution without any noise and without any additional filtering except the ADCs internal filters. They add ~170µs delay which is below the velocity control loop iteration period. My latest P2 design is a bit noisier (~15 ENOB), I have to find out why (higher clock or PCB layout?).
I like resolvers because the behave nearly the same across all manufacturers. Yes, you can get cheaper (absolute) optical encoders with high resolution theese days. But you need a complex communication protocol for them. Encoders with standard interfaces (BISS, EnDat) are expensive and cheaper ones use proprietary protocols which differ for different manufacturers.
I have drivers and example schematics for both P1 and P2. If anyone is interested we could start an extra discussion.
Register at link on first post!
bicycles commonly use these sorts of motors with the low res encoders. They are also commonly used in RC cars.
In most of these applications, a reduction drive is used so the even though they're at low res, thy end up with better resolution than used in many Parallax robots with quadrature encoders.
I think these encoders have enough resolution to allow one to control the speed of a motor and there is certainly enough resolution to provide good odometry data.
I doubt these are good reasons to accommodate these encoders in dedicated smart pin modes but these encoders are certainly very useful in robotic applications.
ManAtWork just posted a great list of various brushless motor types.
I have two threads discussing my attempt of making a smarter skateboard. I request help on ideas about detecting tilt in this thread. I share my attempts of deciphering the VESC protocol in this thread.
The three channel encoders can be read using normal quadrature encoder techniques but I lose resolution. I think the higher resolution offered by using three channels will have the biggest advantage at low speed. I'm hoping to use the encoders to provide smooth startup acceleration. This should reduce the likelihood of having someone thrown off the board from abrupt acceleration.
Agreed. Still, if smart pins could monitor the encoders, it would be useful to me and perhaps others.
Chip probably shouldn't worry about these sorts of encoders.
I just think you were incorrect when you said:
These sorts of encoders are ubiquitous in portable electric vehicles. Quadcopters generally use sensorless brushless motors but RC cars often use these hall sensors. The encoders included in brushless motors I'm using in my current project, provide better resolution than the quadrature encoders used in the Arlo robot.
I have a hard time believing I'm the first person who wants to take advantage of these encoders for use in robotics projects.
I'll use the suggested strategy of polling the encoders as I have done using quadrature encoders on the P1. If the encoders could have been read using smart pins, I would have likely taken advantage of the capability.
I certainly don't think Chip should feel bad that these sorts of encoders aren't supported by the smart pins. I do think these encoders are useful in robotic projects using these sorts of brushless motors.
I've found a solution!
This morning I did some video magic and was surprised at the results (I feel like a CSI lab tech now) and I improved the video from looking like the first three samples here, to looking like the second three samples.
I'll provide this back to Ken for upload to YouTube to replace the former video. Either I or Ken will let you know here when the improved video is posted.
Makes my 3 x 24" 2K displays (which I still think are awesome) pale into insignificance
Yep, but one of them died, so I've only got two now. Walmart doesn't sell the same 4K TV's, anymore, which I made these brackets for that keep them sitting on my desk like a tri-fold picture frame. They were only $249 each when I bought them 3.5 years ago. If 8k TV's were affordable, I could just use a single unit, as it would be equivalent for four 4k TV's.
The first 5MB HDD for Apple //e and /// cost $10K.
Ken Gracey
They has been a fine mix between fantastic contextualized contents, at the "official" part, and many delicious "jam sessions", of all kinds and for all tastes, up to the end.