Receiver to ESC protocol
02-02-2018, 12:01 AM
#1
Thread Starter
Join Date: Jun 2017
Posts: 11
Likes: 0
Received 0 Likes
on
0 Posts
Receiver to ESC protocol
Hello, I'm trying to build a robot car with each wheel powered by a brushless motor. For that purpose I have 4 ESCs which I'll need to control. The onboard computer is a Raspberry Pi 3 B, but I'll also have an onboard Arduino pro mini for interfacing with sensors, etc. It is my understanding that an ESC, typically controlled by a receiver, gets a standard 50Hz PWM signal of 1 to 2ms length, with 1.5ms being neutral. Preliminary testing seems to confirm this, as I've sent 30Hz (close to 50) PWM signals to the ESC with the motor moving roughly as I expected.
I have a couple of questions for more knowledgeable members: Am I correct in assuming that the protocol for the ESCs is about the same as for standard servos? That is, 1ms pulses and up for breaking/reversing, 1.5ms neutral, above 1.5ms and up to 2 for going forward? Is there a place where I can find the full protocol so I can program around that? Finally, if the ESC needs roughly 50Hz refreshing like a standard servo (that's my working assumption for now, so please correct me if that's wrong), then the closest I can get to that on say an Arduino is about 30Hz using the timers, and then the resolution of the PWM timers (8 bit) will severely limit what I can actually use to drive the car. That is, 30Hz equates to roughly 33ms intervals, and with 255 total values for the duty cycle I can choose I'll only have between the numbers between 8 and 15 to control the motors, with 11 or 12 being neutral. That seems like a fairly major limitation, is there a way around that? Does the receiver usually use a high-resolution timer to get around this? Thanks for humoring me, I'm pretty new to this.
I have a couple of questions for more knowledgeable members: Am I correct in assuming that the protocol for the ESCs is about the same as for standard servos? That is, 1ms pulses and up for breaking/reversing, 1.5ms neutral, above 1.5ms and up to 2 for going forward? Is there a place where I can find the full protocol so I can program around that? Finally, if the ESC needs roughly 50Hz refreshing like a standard servo (that's my working assumption for now, so please correct me if that's wrong), then the closest I can get to that on say an Arduino is about 30Hz using the timers, and then the resolution of the PWM timers (8 bit) will severely limit what I can actually use to drive the car. That is, 30Hz equates to roughly 33ms intervals, and with 255 total values for the duty cycle I can choose I'll only have between the numbers between 8 and 15 to control the motors, with 11 or 12 being neutral. That seems like a fairly major limitation, is there a way around that? Does the receiver usually use a high-resolution timer to get around this? Thanks for humoring me, I'm pretty new to this.
02-02-2018, 06:58 AM
#2
It is EXACTLY the same, but the ESC can probably be programmed to interpret the information differently.
An Arduino is a poor platform for this if you're working at the level of sketches. If you skip the crap that makes it an Arduino and go 'bare metal' you can get better performance.
Your RPI can do this better than an Arduino.
Andy
An Arduino is a poor platform for this if you're working at the level of sketches. If you skip the crap that makes it an Arduino and go 'bare metal' you can get better performance.
Your RPI can do this better than an Arduino.
Andy
02-02-2018, 10:46 AM
#3
Thread Starter
Join Date: Jun 2017
Posts: 11
Likes: 0
Received 0 Likes
on
0 Posts
Thanks for your reply! Could you elaborate a bit on how the RPI is better for this? It has 1 PWM pin accessible, and I believe I'll need at least 2 to control the wheels (for turning).
By bare metal I'm guessing you're talking toggling registers? I'll be doing that since I'd like to save on some performance overhead. I could also add a servo controller board which I'm guessing has higher resolution PWM, but was hoping to get away with the hardware I have.
By bare metal I'm guessing you're talking toggling registers? I'll be doing that since I'd like to save on some performance overhead. I could also add a servo controller board which I'm guessing has higher resolution PWM, but was hoping to get away with the hardware I have.
02-02-2018, 11:01 AM
#4
A GPIO pin can be driven by a software timer. You could have a timer interrupt which controls each pin, cycling through the pins one by one in round-robin fashion, generating a pulse of the required width, and then pausing with no pins high until the frame time (22-ish ms) expires.
You don't need to use PWM hardware, just a timer. Do the GPIO high/low control yourself.
You can do this reliably by adjusting interrupt priority and keeping the time in the ISR very short.
Andy
You don't need to use PWM hardware, just a timer. Do the GPIO high/low control yourself.
You can do this reliably by adjusting interrupt priority and keeping the time in the ISR very short.
Andy
02-02-2018, 12:11 PM
#5
Thread Starter
Join Date: Jun 2017
Posts: 11
Likes: 0
Received 0 Likes
on
0 Posts
Right, that would work. RPi clock frequency should be high enough to emulate PWM while doing other processing in the background (I'd like to send a video stream while moving, and do some CV processing). I've never used interrupts before so that's something I'll have to look into.
Further research shows that the servo controller board I was talking about has 16-bit PWM, so that's where the resolution comes from. I can't do this with an arduino short of doing a software timer as you suggest, but the Pi is better suited for that.
Further research shows that the servo controller board I was talking about has 16-bit PWM, so that's where the resolution comes from. I can't do this with an arduino short of doing a software timer as you suggest, but the Pi is better suited for that.
