16 replies to this topic

[Malx]

Hi!
Just ordered a tunity 9x RC system even though I actually would be glad to skip it and just use GCS or other computer/phone based solution.
However, while pipX will work good for telemetry it may not be suitable for direct control in all environments. (Interference and such things)

So I thought. The pipX is based on the ARM processor like all the other openpilot components. It should have more power than needed for handling its own communication. If you just make sure some PWM outputs are available on the pcb you can use it to control a RC-transmitter. That way the PipX can take data from the GCS and seperate control commands from telemetry and push it into a standard rc transmitter module.

What do you think?
I attach a small picture of my imaginary setup.

Attached Files

•  radio.png   26.31K   92 downloads

[peabody124]

I'm fairly confused what this is for.  Where is the input to GCS coming from that you're sending for control?  Probably a transmitter right?  So you'll have TX <-> GCS <-> PipX <-> Tx module <-> Rx <-> OP.

[dankers]

The final PipX will have PPM stream ability, in fact it can do a lot of things, it could for example take a PPM stream from a TX and even convert that in real time to UAVObjects, that would take a bit of work to do in software and I don't think the code supports that yet but it could be done. Additionally there is a PipX RX version planned, this will take some time to complete yet but this is a PipX with servo headers, so can be used for long Range RC as well as pass back telemetry.  That might be more suited to what you are looking at doing?

[Malx]

peabody124, on 22 January 2011 - 01:13 AM, said:

I'm fairly confused what this is for.  Where is the input to GCS coming from that you're sending for control?  Probably a transmitter right?  So you'll have TX <-> GCS <-> PipX <-> Tx module <-> Rx <-> OP.

No, of course skipping the first TX, otherwise it wouldn't make much sense!
I planning on using something else to control the model (Maybe even skipping the GCS step). Think a smartphone or just anything. The reason for not using pipX radio for the fast control signals was for the redundancy of modern 2.4 GHz modules with frequency jumping and preserve the bandwith for the telemetry. I can also see a scenario when I skip OpenPilot and the pipX reciever and just control an ordinary RC model with my mobile.

My first thought was more or less a hardware that I can send signal from a computer or other device, converting it to PPM for the TX module. (Not involving pipX or a full TX transmitter for that matter). But then i thought, why not involve pipX since that hardware is probably something I already will have present at the ground and have the capabilities of doing the work. It also one thing less I need to connect to my computer and ev. GCS.  

In the end, I just wanted to be sure that some extra, not used PPM outputs of pipX is exposed if there is place for it on the PCB. (Of course without pins as default but with the possibility to put them there)

[Malx]

dankers, on 22 January 2011 - 01:41 AM, said:

"The final PipX will have PPM stream ability"

Thanks, that was what I more or less wanted to be sure of. For more long range control that or/and not involves fast direct servo commands I think the pipX radio will be suitable and that is probably what I will use most. I was more thinking of shorter range transmissions in a high interference environment with large demands for fast response. But I may be wrong and the pipX radio may be suitable for that as well.

[Pip]

Well the PipX could indeed be used for PPM but it will need a firmware reconfigure for that, as you probably don't want telemetry using up the available bandwidth when all you want is fast transfer of PPM signal.

Still not sure on range yet, it's been good for me but not so good for others, but it depends a great deal on the surrounding terrain it's used in really. In open air free from building etc it should do real fine (LOS). I wanted to add diversity reception to it as well (a new board design) but also a little more power output, it all takes time etc though, which I have been short of for a while.

[Malx]

Pip, on 22 January 2011 - 08:17 AM, said:

Well the PipX could indeed be used for PPM but it will need a firmware reconfigure for that, as you probably don't want telemetry using up the available bandwidth when all you want is fast transfer of PPM signal.

But I wanted it possible to use both at the same time ! (Look at the picture in first post)
You don't think it can handle that? I thought the radio connection is the limiting factor on a pipX, not the processor?

Oh well, it was just an idea I got when I ordered the TX transmitter I actually just see as a necessary evil . Now turnigy 9x is cheap but without that one it feels like putting out hundreds of dollars just for some joysticks/mixer that "easy" could be replaced with a phone or something else is not so good. I mean, even good chinese tx/rx modules is quite cheap. It may also be one thing less to carry with you when going to a field.

[Pip]

Well so long as the telemetry data doesn't decrease the PPM latency too much it could do both, so the amount of telemetry data would have to be kept smaller than normal, the modems could drop as many telemetry data packets as it needed to maintain PPM latency. Will see but at the moment I need to do other things (like modem configuration from GCS).

[osnwt]

Side notes:

- first, you already can control UAV from GCS using joystick or other source via  the same telemetry channel (assuming that latency is acceptable - for  autopilot it should be ok);
- second, since modems are (will be) UAVTalk-aware, they can drop low-priority packets in favour of controls (pip already said that).

So the only problem is to provide PPM inputs to the ground modem to accept Tx outputs... But maybe it is simplier to use ADC and feed them from resistors, etc... Saying about phone solutions, if you can connect the PipX to the phone, then you don't need another link, and phone will just emulate GCS UAVTalk stream to send control updates instead of GCS. Or you want something else?

Another possible solution is to use your WiFi phone to send controls (using accelerometers, for example, like AR.Drone does) to the GCS through WiFi which will forward it to UAV. The same way you may send controls to PipX, but you need to connect them while in the case of WiFi it is already in place. The only problem again is the latency, but if you don't do some 3D and use position hold and guidance, then it should not be a problem.

[Malx]

osnwt, on 22 January 2011 - 11:33 AM, said:

So the only problem is to provide PPM inputs to the ground modem to accept Tx outputs...

? That one I really don't understand .

My idea was using UAVTalk to the pipX. The pipX then divides the traffics between its own radio module and the standard TX module (converted to PPM). Just so everyone understand. Of course it's better to have pipX radio handling all traffics but I'm not talking about future hardware, I'm talking about what I have seen today. My idea was about getting the total solution to work with minimal cost. I'm also talking about direct fast control, not about autopilot commands.

My solution versus just using "todays" pipX
+ diversity
+ more bandwidth, I guess that direct control could take alot of the available pipx radio bandwidth causing it to drop other packages?
- higher cost
- more complexity
- more weight on UAV (reciever and it's cabels)

My solution versus using pipX and external TX
+ lower cost (no external TX, just the module)
+ less to carry with you
+ can use "any device" to control the model
- May have larger latency.

[osnwt]

Malx, on 22 January 2011 - 12:05 PM, said:

My idea was using UAVTalk to the pipX. The pipX then divides the traffics between its own radio module and the standard TX module (converted to PPM).

Oh, you are about sending controls both ways to UAV via PipX and RC module!

The diversity - yes. But you'll have both streams not syncronized. An I am not sure how the UAV should choose which channel to use first.

And I am afraid that latency will be unacceptable. You need two UAVTalk streams to PipX (using which physical channel?) and from PipX to UAV. That's why I said about autopilot, I am not sure that in such configuration you'll have acceptable delays for really fast control.

[peabody124]

Having tried it, I can say the current implementation has a very uncomfortably long latency.

[Malx]

peabody124, on 23 January 2011 - 03:47 AM, said:

Having tried it, I can say the current implementation has a very uncomfortably long latency.

What are causing the latency?
I guess you are talking about GCS->pipX->pipX->OpenPilot->ESCs or GCS->XBee->XBee->OpenPilot->ESCs?

If it's the XBee->XBee that is the cause like I can read about at diydrones, then maybe my idea isn't that bad. We have to see if it can be improved with pipX->pipX. It can also be the case that you need a hardware on its own as converter between UAVtalk and the Tx module if pipX isnt up to the task. (That was my original idea until I thought that the hardware "already present" could do the job.)

oswnt, My idea involving pipX was with only one UAVTalk stream from the computer to the pipX:
* One high priority thread handling communication with GCS/computer and dividing incoming UAVTalk messages between a radio buffer (telemetry) and a PPM output.
* One lower priority thread handling the radio buffer and the radio.
However, it may be that the ARM cpu is not strong enough for the task. It was my hope that the small divide to a PPM output thing could be done without affecting the speed of it's internal radio.

[peabody124]

It's definitely doable.  Currently the latency comes about because each step has a nice big buffer and no prioritization.  I haven't tracked down which buffer is the weakest link - my guess would be the GCS one honestly since when I move the joystick I see errors about the sending queue filling up.  The PipX CPU has more than enough power for prioritization.

[Reddog]

This project could be of interest here - http://diydrones.com...ject-pcbs-ready

[neontangerine]

Reddog, on 11 February 2011 - 11:27 AM, said:

This project could be of interest here - http://diydrones.com...ject-pcbs-ready

I saw that but I think there are going to be some major problems a number of places with non-compliance to local regulations especially since I don't see any filtering on the 7W amplifier module to block out of band frequencies which will be artifacts of the amplifier module.

[peabody124]

Yeah the PipX has a PPM input/output as well, although we haven't used it yet.