While working on my new autopilot control board (for quads) I realized that using 6 (or more!) MCU pins just to read data from the RC receiver is too taxing for the MCU as well as for the “real estate” on my board – there should be a better way to communicate with the receiver! A quick search on the Internet brought me to the Lemon-RX UART-enabled receiver (http://www.lemon-rx.com/shop/index.php?route=product/product&product_id=97). That same Internet search brought me to Jordi’s post (http://diydrones.ning.com/profiles/blog/show?id=705844:BlogPost:64228) – apparently Spectrum satellite receivers talking serial protocol back to main receiver. Another post (http://www.rcgroups.com/forums/showthread.php?t=922566) confirmed it.
I have a few Orange RX satellite receivers as well as Lemon-RX UART-enabled receiver, so I decided to check them for details of the serial communication.
For tests I use Orange RX 6-channel DSM2 radio with the end points on each channel configured for linear curve with the +/- 100% end points. I connected receivers to my computer using FTDI 3.3 serial cable.
The first one I tested was the Orange RX satellite; using the RealTerm application I analyzed the data stream – it is 115,200 bps serial stream with 16 byte frame. The frame starts with 0x0303 and ends with 0xFFFF; in between there are 12 bytes of the data for 6 channels:
After establishing the frame I used my Windows-based data capture program to get the data stream from the receiver and put it into Excel; the data stream was generated while I moved all the controls end to end and flipped back and force all the switches. Captured data represented in the chart where values for each channel are plotted against time:
It really looks like a digitized PPS signal – each channel has a center point at around (512 + 1024*N), where N – is the channel number starting from 0. The swing from min to max on each channel is 716, thus the Throttle goes from 0 to 100% in 716 steps and Aileron, Elevator, and Rudder channels go from 0 to +/- 100% in 358 steps – seems to be quite impressive resolution!
Then I tested the Lemon-RX UART-enabled receiver using the same settings on my radio. Serial frame for Lemon-RX provided on the documentation page – the frame starts and ends with 0x13 with 10 bytes – one byte per channel between the start and end sync bytes. Knowing the frame, I proceeded directly to capturing data stream into Excel and plotting results:
Each channel has a center point at around 127. The swing from min (38) to max (217) on each channel is 178, thus the Throttle goes from 0 to 100% in 178 steps and Aileron, Elevator, and Rudder channels go from 0 to +/- 100% in 89 steps. The resolution seems to be quite lower than the Orange RX satellite receiver, but still should be sufficient for most practical applications.
I ordered a few Lemon-RX satellite receivers and plan to test them as soon as they arrive. Meanwhile I have decided that my next control board will use serial interface to get the feed from the receiver and, probably, I will use just a satellite one.
Comments
Hi , do somebody have clarity on how to hook up the spekteum satellite ppm connection to APM2.5?
Yes, the serial signal just disappears if the connection to transmitter is lost.
Oh, and I meant less aggressive PID values for a bigger quad as opposed to the tiny one. I used the tiny quad on top of the big one to control the motors and found I had to reduce almost every parameter. Which I sortof expected given the entirely different power to weight ratio of the larger quad.
Yes, that trick doesn't work for every RX (probably not even for many).
Marko's trick could help in the case of zero gap between channels or'ing odd and even channels. But again, I think using the serial data is a much more elegant solution.
Do the packets you received correspond to actual received packets? What I'm asking is, does the data stream stop when the quality of the signal deteriorates or you switch off the tx? It would be very useful to be able to detect a loss of signal which is kinda hard by listening to the servo channels which are often maintained during LOS on digital systems.
Forgot to mention - I am designing a new control board now that will use still 16-bit PIC MCU but at 64 MHz and it will use two MPU6050 at 60 degrees to each other (+/- 30 degrees relative to the model front). Hopefully by fusing data from 2 MPUs I could achieve better stability and potentially bring my control loop speed to 250 or 500 Hz.
Very neat trick, Florian! When analyzing data train from an OrangeRX receiver I noticed that all channels are smpled sequentially with about 70 usec interval between the channels. However on my older 72 MHz receiver the channels were also sequential, but there was no "dead space" between the channels so ORing would result in one long signal summarizing all channels.
I also checked your site that you referred to in your post. I am currently using 16-bit PIC MCU at 40 MHz and also do not have to resort to any speed-up tricks while using 32-bit floats for all my calculations. Presently I run my control loop at 100 Hz (which allows me to average 10 samples from MPU6050 for each DCM calculation), but I could raise the speed to about 450 Hz. Did not do it for 2 reasons - first, that generates too much data for my MicroSD data logger, and, second, without averaging of at least several data points from the MPU6050 I get too much drift in my Yaw estimate. My board has a magnetometer for Yaw drift cancellation, but it is rather useless during the flight as the high currents in the nearby Quattro ESC and power lines skew magnetic field too much.
I find interesting your note about "less aggressive" PID parameters for a larger quad. My quad is rather large (450 mm) and my PID control is quite aggressive - the Kp and Kd set to about 10 times larger values than what comes from Ziegler-Nichols PID tuning method. The catch here is that after calculating the total PID control I limit it not to exceed 25% of the current throttle value. This results in a very fast control without making the model unstable. If you are interested, please contact me directly and I will share with you my spreadsheets from the data logger for actual flights.
--Alex
In the past I found it convenient to OR all the signals together and use a single pin to read all channels. This works only for the slow dsm2 receivers though and still requires a lot of headers on the board. I like your take of reading the serial directly from a satelite. Will have to try that at some point.
Oh, here's that OR thing I mentioned: https://sites.google.com/site/fpgaandco/minimabl
I do not have DSMX radio, so was not able to test, but from the Lemon-RX product page for this receiver:
8 Channels Receiver (Failsafe with UART output)
Yet another trick is to take advantage of the fact that in most receivers (at least all the ones I have tried) the pulses on the individual channels are staggered in time (just like the original PPM signal). One can therefore get away with simple reading every other channel pin and deducing the value of the skipped channels from the gap between the end of the preceding channel and the beginning of the next. This way one can read 7 channels with 'only' 4 pins:
I.e. only channels 1, 3, 5, 7 are connected to the MC; the end of the pulse on channel 1 also marks the beginning of the pulse on channel 2, the beginning of the pulse on channel 3 marks the end of the pulse on channel 2 and so on...
I have used this trick successfully on a couple of homebrew control boards. The resource overhead for reading pulses via pin change interrupts and a free-running timer is actually extremely low, even on a small 8-bit microcontroller.
Going fully digital with a UART enabled receiver is a much better solution, of course. Among other things, it is much more robust with regards to timing jitter in nested interrupts and such...
Marko
Is the firmware also compatible with DSMX ?
-
1
-
2
of 2 Next