I have programmed a PIC to record the length of a servo pulse sent out by an RC car receiver. This is then sent serially to a PC, but now the value jumps around. Such as between 2-3 values and each value is in increments of approximately 5uS. So, do servo pulses have between 100-150uS of 'play'? The more I think about this, the more it appears to be a dumb question, Sputnik
Are you moving the servo? If so, the pulse duration is going to change. servo pulses should be between 1ms to 2ms (left - right) occuring at least 20hz.
In any position it varies. The RC transmitter is untouched. I believe servo pulses are such that 1.25ms is full deflection one way, 1.5ms is center and 1.75ms is full deflection the opposite way. With a pulse having to occur atleast every 20ms (so that's 50Hz)! Maybe I'm wrong about the frequency, but that's not important, neither the problem. My solution then is to take 10 samples and display an average thereof. My next problem is then a VB problem and so will have to be posted under the Development section. Thanks, Sputnik
Duh, meant 20ms. You are mostly correct about 1.25 and 1.75, depending on the servo, you can get more deflection. 5uS seems like a small amount of drift. I would think that could be caused just by the serial overhead.
Serial over-head? What's that? Anyway, I have decided that I know bugger all about VB and so am going to use Java. Although I still just need to know how to receive data serially. Sputnik
What I mean about overhead, is just interrupts and whatnot. I don't know what else you have the PIC doing, but let's say you have a 4mhz clock. It takes most instructions 4 clock cycles to complete. So you get roughly 1,000,000 instructions per second. In this case, you're getting about 1 instruction per usec. So a drift of 5 usecs is easy enough if an interrupt hits, etc. How are you measuring these anyway? If you're not actually using the CCP module, you should look into it. As far as VB & Java, I'm not much help. Perl is my expertise.
After the 1.25ms baseline delay, it then records the offset from the baseline delay: Code: loopy btfss PORTB, 0 goto finish incf DATA_REG goto loopy Then DATA_REG is sent serially to the PC. There are no interrupts in my program. Hmmm, doesn't matter, I'll just calculate an average. CCP module? Sputnik
It the Capture Compare Pulse module. Meant for capturing pulses and generating them with high accuracy. Check out Hazer's tutorial here. What are you using for the clock? Crystal, Resonator,Resistor?
I'm using a PIC16F84, no CCP module, no UART and it's running at 1MIPS from a 4MHz crystal. By calculating an average from about 5-10 samples yields quite a stable result. Although, perhaps to make life easier, I may build a programmer for my PIC16F876 which has many more features than a PIC16F84. Now the problem is which programming language to use, I have found that Java is beginning to become more and more work just to get this project to function, let alone function effectively. Thanks, Sputnik
Please hold your laughter for the end! I love RC cars! I currently own two electric models, the one is a Tamiya M-chassis and I don't know anything about the other, except that it is a dune-buggy. So, what's more fun than a 1/10th scale RC car? Well...how about a life-size version? LMAO! I have seen it done so many times on Mythbusters and Top Gear Xtra, but theirs were on automatic cars and so was supa simple! The reason for the capture of servo pulse... automatic cars are quite expensive (here), so why not have fun with a manual. (2) Servos for gear stick, (3) servos for foot pedal. All of these servos are controlled from a PC situated in the car from the single RC channel. The steering is directly controlled from the RC receiver. I still require a donor vehicle, I'm not using my car you understand, LOL! You may now laugh at my insanity, Sputnik
As long as your careful about it, I see nothing insane. I was quite disappointed when the Darpa Grand Challenge was one this year. I thought after the first, it would have taken another 2 or 3 before someone completed giving me time to try and get in on the fun. I'd be real concerned about handling a loss of communication or bad signals on that one channel or you could have a lethal accident on your hands. Also OS and hardware problems. Servo's might not be the best bet either. I would think for the pedals, linear actuators would be better suited. What's the purpose of measuring the pulses? Is it to confirm the signal from the receiver? Even if the pulse would be correct, it doesn't mean the servo would be in the right position.
I have thought of all those situations and my solutions are as follow: -Loss of signal Either I could have a circuit monitor the strength of the incoming AM signal or have a circuit remotely activated on a different frequency that would kill the ignition and apply the brakes. Fortunately, I haven't seen anybody in my neighbourhood who drives RC cars, so that shouldn't be a problem with frequency collision, although once again, the remotely activated safety device would be used in such a case. -Foot pedals Yes, servos will indeed not be strong enough. I have thought of linear actuators (although I will have to fabricate my own) as well as perhaps attaching springs to counter-act the force. -OS/software problems/crashes The PC will be required to send specific data to the PIC controlling the servos, should this data fail to arrive within a designated time period, the PIC will cut the ignition and apply brakes IMMEDIATELY. This could also be done via the remotely activated safety feature should the car not respond. -Purpose for the monitoring of the servo pulses You simply have forwards and reverse on the stick (push it up and down). The onboard PC will respond to the increased/decreased servo pulse length by steadily releasing the clutch and applying the throttle, as the RPM of the engine reach the currently applied throttle position, the PC will need to change gears (ie. dis-engage the engine, reduce throttle, change gear, engage engine and apply throttle) Sputnik
We measured the PWM signal with some fancy oscilliscopes in my Engin 100 course - pulse period was ~18.5ms, pulse width i unfortunately don't remember, but they were pretty precise. You probably shouldn't drive this thing in populated areas [because **** happens] and when you get it working, you definately should hook us up with some videos By the way, got any good resources for pic programming? i want to learn it in my free time this semester.
