Custom building or re-building RC transmitter gear
A thought that occurred to me recently: is it possible to use the spare parts that a lot of RC shops sell, or maybe a semi-dismantled RC transmitter handset, to make your own transmitter? As in, build something from an Arduino/BeagleBoard/Gumstix/custom PCB/whatever and then connect it to the transmitting part of the RC handset, at any level - either some handset that will accept some kind of data input and send it for you, or right down on the raw electronics end, soldering bits together.
Basically, I'd like to get some computer assistance into the loop, using telemetry data to allow the system to act like fly-by-wire software, tweaking and moderating the control inputs to stop the pilot from departing from a safe flight envelope. If done right, it should make the aircraft controllable with just one two-axis thumbstick, trading separate controls for all the surfaces for basic up-down/left-right and a throttle slider. I was just wondering if it would be at all possible to build this into the actual handset (ignoring for a moment the issue of how the telemetry data would get to said handset) so that I could use the tried and tested transmission method, rather than having to fight past the latency and patchy signal issues of something like an XBee.
If not, then hey, back to the drawing board I guess. This is still early concept stages, so no great loss.
Basically, I'd like to get some computer assistance into the loop, using telemetry data to allow the system to act like fly-by-wire software, tweaking and moderating the control inputs to stop the pilot from departing from a safe flight envelope. If done right, it should make the aircraft controllable with just one two-axis thumbstick, trading separate controls for all the surfaces for basic up-down/left-right and a throttle slider. I was just wondering if it would be at all possible to build this into the actual handset (ignoring for a moment the issue of how the telemetry data would get to said handset) so that I could use the tried and tested transmission method, rather than having to fight past the latency and patchy signal issues of something like an XBee.
If not, then hey, back to the drawing board I guess. This is still early concept stages, so no great loss.
Replies to This Discussion
-
Permalink Reply by Marco Glattfelder on -
In many legislation you will need to have a "standard" rc gear that controls the plane. There are no real rules, and I guess not even a real control on that but in the case someone "official" checks your uav and/or rc he will dislike to see some wires going out to a self made box instead of a classic rc tx/rx. The reason is that you need a tested "best practice" equipment beside any uav or self made system. And that is good, because uav technology is far to be reliable as it should.
If you have a standard rc system that can take over in case of emergency you can surely build your custom system. The best option is to use the trainer port of the rc handset itself, mostly accepting so called PPM signals. These can be modulated by an arduino board. One example of many: http://www.ianjohnston.com/content/index.php?option=com_content&... but there are some other projects following that path. Doing it this way allows you to use the rc gear in case the self-made solution won't work.
-
Permalink Reply by Michael Smith on -
Why would you want to place your anti-crash system at the mercy of your telemetry, when you could put it in the model itself?
-
Permalink Reply by Nicholas Budd on -
That's actually a very good point. Basically, the data stream has to go to the ground at some point, because there's human input. Somewhere along the line, the telemetry and control inputs have to meet, so that a piece of software can use them both to figure out what signals to send to the aircraft's moving parts. So either the telemetry comes down, or the inputs go up. I don't really mind which one of these happens, but I don't know how big a board will be required. If it requires a processor that the aircraft can't lift, then the telemetry will have to come down.
Also, the endpoint of this project is a combined control and groundstation handset (no idea if it'll ever get that far, but that's the dream). It'd have a 2-axis thumbstick, a throttle slider, and a screen. So when this handset is built, that thumbstick will need some way of sending its inputs up to the aircraft reliably.
I don't know, though - I'm still kinda new to this. What would you suggest?
-
Permalink Reply by Michael Smith on
-
I'd suggest that you click a few of the links at the top of the page, and read a bit about ArduPilot, the UDB and some of the other things that this site is all about.
-
Permalink Reply by Nicholas Budd on
-
Ok, I'm not that new - I have my ArduPilot half assembled already. What I meant was that I'm new to the in-depth electronics of radio transmitters. I'm just looking ahead to the things I want to try once I have my drone flying, and one of those is fly-by-wire. Before I got into UAV building, I'd only flown RC once, with a very experienced pilot standing by, and he actually landed it for me. I'm not a great RC pilot, and I'd like to have some fun with this thing, so I'd like to be able to fly it manually without worrying about whether I'm going to crash it. A pilot-assistance system of some sort seems the most sensible solution. I figure it you can get a computer to do all the work, then how hard can it be to make a system that does half the work?
-
Permalink Reply by Michael Smith on
-
My point was that the sort of thing you're talking about is already implemented by these systems. You were proposing implementing something more complex and less reliable that would do a worse job (since from control inputs alone you can't deduce anything much about the airframe's orientation).
-
Permalink Reply by Nicholas Budd on
-
Er... that's why the telemetry data is needed as well. As I said half an hour ago:
"Somewhere along the line, the telemetry and control inputs have to meet, so that a piece of software can use them both to figure out what signals to send to the aircraft's moving parts."
I've looked over the ArduPilot system and as far as I understand it, it doesn't do quite what I'd like to. Not to the same extent, anyway. And how is it all that complex? All I'm proposing is to take all the data that the autopilot system is collecting already - orientation, airspeed, altitude etc - and use them to moderate the incoming control inputs to stop you from stalling, or spinning, or doing anything else that might endanger the aircraft or anyone in the vicinity. The hardware my idea would need is all there as part of the ArduPilot system already. Any complexity is in the programming, and as I'm programming a flight simulator from scratch as a degree project this year, that's not really an issue for me. A slightly more powerful processor might be required, but if necessary there's always a Gumstix board or similar. The only problem I see is a reliable way of transmitting it back to the aircraft, because I'm told that the XBee is not a good choice for this (haven't got mine yet, so I can't test it). I figure the standard RC transmitters must be reliable enough or else they wouldn't be used as standard RC transmitters, so I was simply asking if anyone knew of a way I could use one of them instead of an XBee in this application.
-
Permalink Reply by Michael Smith on
-
I go back to my original question; why are you doing this on the ground where your data link introduces a great deal of unreliability, when you could be doing all of the work onboard?
You should look at the 'fly by wire' modes.
-
Permalink Reply by Nicholas Budd on
-
I can't do ALL of the work onboard, because the human pilot needs to have some input, and they'll be stuck on the ground. The computation can be done on the aircraft, but I still need some way of transmitting the pilot's inputs up to the aircraft. The pilot will be holding a custom-built simplified control handset with a single thumbstick and throttle, so I need some kind of transmitter that can send the signals from the thumbstick to the aircraft. Just like I said an hour ago:
"the endpoint of this project is a combined control and groundstation handset. It'd have a 2-axis thumbstick, a throttle slider, and a screen. So when this handset is built, that thumbstick will need some way of sending its inputs up to the aircraft reliably."
I'm aware that there is already a fly-by-wire mode, but it doesn't do all the things I'm planning to put into this (some, but not all) and even if it did, I still need some way of getting the inputs from the handset to the aircraft.
So, back to MY original question: can I use the transmitter from a standard RC handset to do this?
-
Permalink Reply by John Church on -
In response to your question, yes- It can be done. However, as Mike suggests, that's what stable mode is all about.
Keep at it though- it can certainly be done. Get a flow chart going to clear up your idea and post it here for more input. There's more than one way to skin a cat. :) -
-
Permalink Reply by Michael Smith on
-
"I still need some way of transmitting the pilot's inputs up to the aircraft."
This sounds very much like a a conventional R/C transmitter to me. It has a lot of advantages (industrial design, volume market, FCC certification, etc.).
"the endpoint of this project is a combined control and groundstation handset"
You're trying to drive your design from your implementation, which is like putting the cart in front of the horse.
- Why do the two have to be combined?
- Why the screen at all, since you want the pilot to be watching the model?
All that being said, you can certainly get get modules like the FrSky setup that take PPM into the transmitter, and push PWM out servo channels on the receiver. -
-
Permalink Reply by Nicholas Budd on
-
"This sounds very much like a a conventional R/C transmitter to me. It has a lot of advantages (industrial design, volume market, FCC certification, etc.)."
Indeed, but I'm after a simplified control setup for less experienced pilots, and an integrated display.
"You're trying to drive your design from your implementation, which is like putting the cart in front of the horse."
How so? I have a goal, and I'm asking what hardware can be used to achieve it. If I had hardware and was asking how I could work it into a design, then you'd be right.
"- Why do the two have to be combined?
- Why the screen at all, since you want the pilot to be watching the model?"
Yes, the pilot would be watching the aircraft, but a glance down at the screen would show them the telemetry data, which would give them extra info that they can't see from looking at the aircraft. I want the screen for the same reason that cars have dashboards and not just huge windscreens - there's stuff you can't tell by looking, like battery level, or exact altitude (CAA regulations for UAVs include altitude limits). The plan is also to have the same handset act as the groundstation when the UAV is in auto mode, showing telemetry, video or a moving map as desired. The system will support mid-flight course changes, so the map would also be used to view, add, remove and edit the waypoints. Also, some people fly FPV, so the screen would give somewhere to show that video with a HUD-type display, I guess, but that's secondary.
"All that being said, you can certainly get get modules like the FrSky setup that take PPM into the transmitter, and push PWM out servo channels on the receiver."
Now that looks promising... -
Top Content
Groups
-
ArduCopter User Group
478 members
-
ArduPlane User Group
299 members
-
ArduCopter (traditional …
77 members
-
ArduPilot (legacy) User …
77 members
-
Moderators
50 members
-
ROS User Group
31 members
-
Team Prometheus
11 members
© 2012 Created by Chris Anderson.
