I'm doing the opposite as I wait for money or objects in the mail and it's a bit mind blowing. I already have a Pico W running code for PWM out like a throttle and the ESC/Brushless motor with BEC connectors. On an oscilloscope I get a square wave from the Pico pin. In stage 2 I want to hook in to "something" for auto throttle control which can be a heat sensor or the other servo. An RC car with a propeller is the original idea. Also removing the need for 2 hand controllers.
That sounds like a fun project. I usually take that approach as well. I start with a controller and then I use sensors or some other input to create autonomous motion.
Thanks, nice video! Keep up the good work! FYI, "baud" rhymes with "clawed," not "cloud." It might be nice if you occasionally dipped into the "why" behind some of your decisions. For example, why 9600 baud? As far as I can tell, it just controls the maximum rate at which you can write new values to the serial output port, and just needs to be fast enough keep up with the 50Hz input rate -- but that's not obvious, and it would be good if you said so (and perhaps even showed what happens if you pick a different value). I'm not sure how big an int is in Arduino land; guessing 32 bits. So that's 50 * 32 = 1600 bits per second, which means that any rate higher than that would be sufficient here, and anything faster would make no difference (except, I suppose, the _tiny_ change in latency between input and output). Google says the Arduino can go up to 115,200 baud (12x faster than 9600), so you'd be looking at a potential latency change from ~100µs down to ~8µs. At first I thought that the _input_ was 9600 baud, but I did the math on that and determined that it would only give you enough resolution to differentiate about ten levels of pulse width. Your output graph clearly shows at least an order of magnitude more resolution than that!
Thank you for this! My apologies on the mispronunciation. The "why" is something that I could have delved into more. Generally speaking, I try to focus more on how to do something, but in this example, you're right in that the "why" could provide more insight in some other specific applications.
This is a great video -- very well-done and educational about interrupts. But ... the way this is constructed, won't this have the interrupt handler routine called with each pulse of the PWM signal? Even if the duty cycle hasn't changed? Won't this swamp the processor? ALSO, what is the point of a PWM port if it doesn't convert the PWM duty cycle into some value for us? Aren't you treating the PWM port like any other digital port?
You are correct that an interrupt happens at each pulse, but I haven't had any issues with simple projects so far. I was able to use this to read an RC signal and control a stepper motors without a problem. Yes, I am using this PWM port simply as a digital port. I could use the "pulseIn" command to measure the PWM signal, but I didn't have great performance with it.
@@TheBoredRobotLLC Very interesting. I had the opposite result with my Arduino Mega 2560 ... the interrupt method absolutely swamped my board and it basically prevented any other processing. Here's another consideration: You're calculating the pulse width using an interrupt (which ties up the proc for the duration of your algorithm, no?). Is that any different from pulseIn()? I'm guessing there may be a slight difference but ... is your algorithm more efficient than the Arduino pulseIn() function? If so, congrats. But by how much? I suspect both methods take up approx. the same proc cycles per iteration. BUT, you're video is a stellar tutorial on how to implement hardware interrupt handlers. Sincere congratulations. It's well-done in every way and highly valuable. I'm just contesting this usage context ... or rather hoping someone will suggest a trick so that the interrupt isn't called on every pulse cycle. Best wishes!
@@DaveFer Thanks for the feedback. Perhaps there is a better approach for this application. It's strange that your Arduino Mega is struggling with this. Generally speaking, interrupts are faster than pulsIn(), but I think it could be a cool experiment to quantify that.
Thank you for this nice video, very instructive. It is a nice start for a RC project. I am however experiencing soms troubles. When using this sketch on a Nano, it stalls after about 35 minutes. Do you have any idea what might cause this?
To be honest, I have never let it run for that long. I'm not quite sure what the answer is here, but there could be some sort of overflow issue here. I would have to do a bit of research on that.
The micros() value is 32 bit unsigned integer which overflows after ~70 minutes (see the arduino language documentation). The reason you got 35 minutes is probably because you had signed int in your code.
I playing around with this stuff for a fuew weeks. I have the problem thatt at the 0 position, the arduino reports values between 1505 and 1490, it ist'nt stable. At a stable position with an switch at the radio, defined 40% , isn't stable too. Is woobling around 20 digits. Is this an issue on arduinohardware or the used library?
That seems normal. The value is going to bounce around a bit. You can implement some sort of smoothing function or filter if it doesn't work for your application.
2.4GHz is the carrier frequency, not the signal rate. So long as your transmitter and receiver are on the same carrier frequency (aka channel), you should be good to go -- and I'd expect that you'd still see 50Hz signal rate.
The ESC in that scenario would be acting as a digital-to-analog converter, taking the digital PWM signal and outputting an analog voltage signal. And then you want the arduino to take that analog signal and convert it back to digital? It'd work (given that you stay within the voltage limitations), but it seems kinda silly.
I want to do the same but with an Raspberry Pi Pico. Should I wire Servo Anode to ADC Ground and Servo Signal to ADC0? The Servo Signal and Servo Anode Pin give a low Voltage between 0.2V and 0.5V which is fine for the Pico's max Voltage of 3.3V
@@TheBoredRobotLLC No problem, I found out there are RC switches that can measure the length of the signal and switch something when the signal is low or high
I have a question, I am currently using this technique to try and controll a servo, but everytime when i pull on the elevator, the servo starts twitching
The first thing I would check is how smooth the signal to your servo is. If there is a lot of noise, then you might want to use a smoothing technique for the signal being sent to your servo. If that's not the case, I've had issues in the past if I am powering the servo directly from the 5V output from the Arduino.
It would work in the same way. Instead of a continuous set of pulse lengths, it would just be two discrete pulse lengths when you flip the switch. You would just have to measure what those two values are when the switch is flipped back and forth.
Do you have any documentation on the type of the signal coming from the Bluetooth module? If it's the same PWM signal as an RC receiver, the process should be the same.
Assuming you have everything wired up correctly, you might be able to get away with just using the analogWrite() command. This pin sending the command could be sent to the gate with a resistor to protect the Arduino.
This can be a number of things. My first thought would be to check the output settings on your transmitter. I do have an update to this video to make things easier. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-MsUL-RY8ZrY.html
Thank You for the Idea 🙂checking old time < new time will eaven make it easy to reset the variables. I am doing it in your interrupt @@TheBoredRobotLLC
You'll have to map the values you read from remote control to some sort of value that relates to the time between steps for the stepper motor. I'm working on a video to do this.