Parallax Servo Controller Baud Rate
QuadrtrFlyr
Posts: 73
Hello folks,
I am curious as too why I cannot get the parallax servo controller to communicate at 115200 baud? 38400 is too slow for my current setup. Modified code posted below
Thank you,
PSC Propeller Firmware Mod.spin
Robert
I am curious as too why I cannot get the parallax servo controller to communicate at 115200 baud? 38400 is too slow for my current setup. Modified code posted below
Thank you,
PSC Propeller Firmware Mod.spin
Robert
Comments
Does the other device work with some other program at 115200 bps?
Robert
At 38.4kbps, it takes about 2ms to send a servo position over the serial line (if I did the math right). I'm pretty sure the PSC uses the standard refresh rate of 20ms. So unless you need to set a lot of servos positions (>10) very quickly, I doubt increasing the baud would help much.
What are you expecting the servos to do and what do they do that's unexpected?
Could the lack of response be caused by something else?
When you tried a higher baud, I assume you also set the Raspberry Pi to the higher baud as well? (Sorry for asking, but I'm not above making this type of mistake myself.)
How are you communicating with the RasPi (USB or TTL)?
So to send 4 servo position commands to the PSC it takes a total of 28ms?!? (4*2ms+20ms) That is wayy too slow (~35Hz) for my current project. I need all 4 motor to refresh at at least 200Hz preferably.
I am communicating with the RasPi over USB.
When I set the Propeller Servo Controller to a higher baud rate (115200) I first attempted to send the "!SCVER?" command to the PSC in the parallax serial terminal (works at 38400 baud). However I received no response therefore assumed a set servo position command sent by the RasPi would not be read by the PSC either (tried it & changed both baud rates).
The code on the raspberry pi is running at a very high frequency with no delays and basic calculations so I believe the PSC is the limiting factor
These motors are hooked up to a quadrotor. The IMU is sending values to the RasPi at ~300Hz and based on a simple one axis pivot test I can see that the motors are lagging. When I til the quadrotor in one direction, I can see that the angle is instantaneously changing on the screen but the motor takes a moment to actually respond to this change in angle. You could hear the motor buzzing at a different frequency when its trying to spin faster or slower. The PID loops is executing at 264Hz so that is not the limiting factor either..
No, I think it's closer to 8ms.
What is controlling the motors?
Most servos and ESC expect a 50Hz refresh rate (20ms).
I think some servos and ESC can work with a higher refresh rate but I believe these are the exceptions.
My bet is the ESCs are the limiting factor.
I think you may be overloading the PSC with commands that don't do any good.
I'd suggest changing your RasPi software to only send data at 50Hz. I think to get higher refresh rates with your motors will likely require specialized equipment rather than normal RC stuff. There are a lot of robots and quadcopters that do well at 50Hz refresh rates so you may not need to go that route.
I am controlling the motor with this ESC which states that it has an Operating frequency of 8.5kHz. I am assuming that this is an exceptional ESC? Previously I have also done ramping tests on this ESC using the raspberry pi and have gotten great results in terms of fast response. I could be wrong but it seems to me that these aren't the limiting factor.. This problem has been frustrating me for days...
The 8.5kHz is what the ESC uses internally (I don't understand brushless ESC very well but it needs to convert one DC voltage to another. It does this by switching the voltage on and off very quickly and runing it through inductors and capacitors (lame explanation). The 8.5kHz is how fast the regulator is turning on and off.) It is not the refresh rate.
50Hz isn't very limiting. Here's a fun example of what can be done at 50Hz.
You may want to backup a bit and learn a bit about servos and ESCs.
My guess is Parallax wanted to keep it simple. I can't think of a reason why the firmware couldn't be changed to run at 115200 bps. Again, I don't think the baud is the source of your problems. I think you're sending too much data to the PSC which is filling its buffer and slowing down its ability to update the ESCs quickly.
Wow that is crazy! So is 50Hz a standard rate for all ESCs?
I can modify my code to send a command to the PSC at less frequent intervals. Would you recommend me sending the servo position values at 50Hz since the ESC most likely operates in this range or even a little faster? I think you are definitely right about the PSC buffer filling up too quickly and having a delayed response.
I suppose it wouldn't hurt to send data a bit faster than 50Hz. My guess (though you should test it) is 100Hz would be okay.
Motors can't change their speed instantaniously anyway so I doubt a faster refresh rate (on the ESC) would make a noticable difference.
There are some "tail" servos for RC heicopters that work with a gyro that have faster refresh rates than 50Hz but these are the exception.
I think the ServoPal Parallax sold used a 100 Hz refresh rate (IIRC).
There's a lot of good information in the free Parallax books about servos. I think the books "What's a Microcontroller", "Robotics with the MOE-Bot" and "Understanding Signals" have information about the servo pulses. The book "Understanding Signals" has a lot of useful information. It's written to used with an oscilloscope but I think it's a good book to read/look through even if you don't have an oscilloscope just to know how electronic items communicate. I'm also sure theres lots of sites online with this information.
Your motors will have to have a good amount of torque (relatively low-Kv rating) and your motor controllers will need to be set for very fast response time for the higher refresh to make any difference.
How does one tell if an ESC or servo can accept the 250Hz rate?
As a general rule, unless a servo says it'll handle it it's risky to try. ESC's are entirely microcontroller driven though, so the worst that'll happen is they'll ignore the signal completely, or just not improve with the higher frame rate.
J
I took a look at your code and work and it is truly inspirational! The videos looks great too! My motors are rated at 950Kv (rimfire 400) and are being controlled by the greatplanes Silver Series 35A ESCs. I bet my hardware would benefit from your servo8fast code especially if I need high speed response. However integrating your code into the current PSC firmware might prove to be a very difficult challenge for me since I am not too well versed in Spin and PASM. Any ideas where to start? I did some preliminary testing and found that the limiting factors in the code were the serial communication functions (getdatabytes). However the PSC firmware uses FullDuplexSerial which supports 115200 baud so I am not quite sure how to approach this problem..
With regards to tuning my PID loop, I was currently trying to use the Ziegler-Nichols tuning method but am having extreme difficulty finding a point where the quadrotor oscillates with a constant period (only proportional control on one axis (roll angle) pivot tests) due to the fact that my motors are not 100% mechanically similar and small differences causes my axis test to tilt in one direction. My goal right now is to make the quadrotor hover. Do you have any tips on tuning the PID loops? I would really appreciate your expertise. I will take a look at your code in much closer detail as soon as i get the opportunity, hopefully this afternoon.
Best,
Robert
It's possible that their "throttle off, full, off" cycle to arm the ESC is setting the range, so make sure your PID loops aren't functioning during this time or they'll be sending different values to the ESCs, causing them to have different throttle ranges.
Definitely, I initialize the motors before and PID loops are called via the off, full on, off sequence. Then the values I used for my "off" and "full on" state specify the bounds of my throttle range. Any recommendations on tuning the PID loop?
Robert
Being able to toggle between a pair of settings is useful, too - Set a "stable" set, and an "experimental" set. Toggle back and forth until you can see for sure that the "experimental" set is responding better, and then copy that into the "stable" one.
Regarding the motor controllers, if you have a way to test it, you should. (An RPM meter like an optical tach, for example). Any difference in the throttle response of the motors will cause you grief.
Got it, I was hoping to get an oscillatory effect with just the proportional part of the controls, but was having some difficulties. Time for more trial and error.
This is actually a really good idea considering I have asked myself whether or not my new experimental set was better than my previous one. Definitely will implement this.
Never hear of an optical tach RPM meter, but seems like a legitimate solution to finding the RPM vs throttle relationship. I previously skipped out on finding the RPM vs throttle relationship and instead directly found the throttle vs thrust since this was needed in controls. For those interested and aware of the rather new VICON motion capture system technology, these camera are also able to measure RPM on a blade through fast frame rates and ability to sense reflective tape. However you most likely will only find them at research institutions since they do come at a hefty price (>100K).
Robert
It senses the fluctuations in lighting as the blade breaks the line-of-sight to the sun, so don't use it indoors. Fluorescent lighting pulses and that throws it off.
If you apply the same throttle value to all your motors, they should all be moving at the same RPM (or very close). If they aren't, you'll never get the thing to fly right.