2 replies to this topic

[Brian]

I wanted to start this thread to discuss possible enhancements to the UAVTalk library.  This will likely both affect the flight software and the GCS, but I think it is more directly related to the flight side, so I put it here. I hope this thread will help those who are interested to get a deeper understanding of the UAVTalk architecture and to discuss potential enhancements that we might add to UAVTalk.  I plan to start with some initial observations in this post, and updated this post as additional information is discovered.  We could (should?) also create a Wiki page to gather the information.

This thread was precipitated by my experience building prototype prototype hardware and software to perform manual control via a UAVTalk interface, and a related discussion of manual control via a telemetry modem.  The UAVTalk and UAVObjects libraries are very good, and provide a very easy to use paradigm for communication both between modules within the flight computer and between the CC and the GCS vial telemetry, but I think a few enhancements would make them easier to expand as we add more hardware pieces to the system in the (near?) future.


So, why do I think we need to change UAVTalk, and what do I think needs changed?

• There is no general way to route messages through the system.
  
  • Routing works well within a board, and the telemetry module supports routing between the main flight computer and the GCS, but there is currently no easy way to extend this.
    
  • For example, my transmitter module sits between the GCS and the CC.  Currently is simply relays all packets between the two, and injects GCSReceiver messages into the CC stream at set intervals.
    
  • There is no way to e.g. add configuration UAVObjects into the transmitter, etc.  One could siphon off packets for UAVObjects that it finds instantiated on the transmitter CPU, but that's still somewhat of a hack.
    
  • ACKs and NACKs are simply relayed across the transmitter link, which may or may not be ideal.  Bandwidth is decreased due to additional latency buffering the message in the transmitter box.
    
  • I would like to have a mechanism where each link in the communication chain knows where each UAVObject is (ideally via automatic discovery), and is able to route packets accordingly
• Currently there can only be a single (UAVTalk) packet in transit at a time, and only a single transaction (object transmit with ACK or object request) at a time.  Also the receive thread transmits ACKs, NACKs, and objects after a request, which limits synchronous transfers.
  
  • I implemented a mechanism in my transmitter branch that passes messages between receive and transmit threads that could probably be used to offload the transmission at least of object requests to the transmit thread, and would allow synchronous receives in this case, but it would require supporting multiple transactions (recording that an ACK or OBJ_REQ is outstanding).
• It would be nice to support additional functionality of the communications hardware if the hardware supports it (e.g. Xbee API mode, etc).  This could allow multi-point networks, so the flight computer could talk to both the GCS and a transmitter directly, rather than having a pass-though box like I have now.  It could also allow for re-transmission of just a single communication packet rather than the whole object in the case of a failed transmission, etc.  Even more could be done one custom hardware/firmware, like the PipX.
  
• I think most of these requirements could be solved by adding a distinct network layer to UAVTalk that would handle the routing and transmission of packets.

So, where to we go from here?  I would like to have a discussion of whys that we could enhance UAVTalk and try prototyping some of the concepts.

Most importantly, we don't want to break what we already have, so we need to:

• Have minimal affect to the flight software performance (memory / CPU / flash usage) and telemetry link usage.
  
• Minimize code changes, especially to external interfaces.
  
• Minimize complexity
  
• Get core team buy-in (especially James )

The following is some high-level UAVTalk concepts currently in UAVTalk (as I see it):

• UAVTalk essentially implements a distributed database of UAVObjects, where UAVObjects are stored within both the GCS and the flight software.
  
• UAVObjects are defined in XML, with code generated for both the flight software and GCS (and other languages).
  
• UAVObjects also contain metadata that defines how and how often the data is synchronized across the telemetry link.
  
• UAVObjects are also used to communicate between module in the flight software.
  
• UAVObject updates are in the flight software via event queues.
  
• UAVObjects are updated across the telemetry link via the telemetry module using the UAVObject metadata.
  
• Each UAVObject can have one or more instances.

Some aspects of UAVTalk/UAVObjects that I don't know:

• What UAVObjects require more than one instance?
  
• Is there always a single module that writes to each UAVObject (single writer, multiple reader)?

I'm sure I left alot out here, so please fill me in on what I might have missed.

One thing that would be really helpful would be to come up with one or more "worst case" network diagram of what we might have in the future as far as interconnected hardware (GCS, Revo,  Sensor board, OSD, ESCs, transmitter, ...).  I think this would facilitate defining design requirements.

[Andrew]

One concept that has been floating around in my head for a while and is on the same lines as your transmitter is to have a "UAV Listen" plugin on the GCS.
This would allow for a second GCS to connect to the main GCS that is actually talking to the flight hardware and essentially relay the UAV Objects.
I would imagine having the ability to allow the secondary clients read/write access or only read access to the UAV Objects.

I see a few situations for this, one is I have a serial link between the flight h/w and GCS but my phone/tablet only has wifi/bluetooth ... I can have my laptop sitting by my side relaying the flight info to my phone mounted on my Tx...
Another would be to transmit flight info across the world in real time, someone in Australia can watch me fly live in USA (Read only) and even help me debug problems I am having...

If this is a feature others see as worthwhile then it would be good if the changes you propose support it as well...

[XXL-Wing]

I would like to have some place in the Wiki to gather all ideas, maybe use a mind-map to gather and afterwars group them to find out where the next steps could be and not forget things and goodideas that ar eburied in some text in postings here.
We could use FreeMind for that (http://freemind.sour...x.php/Main_Page) it is available on all platforms and very good to use (we are using it as a stadard tool in my development teams to "document" brainstorming and design sessions).

Now for the tecnical part:

I would like to see a timeliness supervision in the transmission of the data, that is esecially useful if time critical data like direct flicht commands are transmitted. Also some notion of moving transmission windows with dynamic acknowledgement like in the TCP/IP protocol would reduce communication overhead.
A +1 from me on basic handling of transmission over the XBee, using API mode will be a defintive plus. For implementation of that i raise my hand except if there is some XBee expert here that can do it way better than me :-)
A automatic discovery of members in the network is ok, but in such a limited environment not a definitive must, definition of the setup in GCS as a first step in my opinion should be sufficient. First we should focus on a strict partitioning of data, data presentation with marshalling/unmarshalling and communication/routing/transmission.
We could use some sort of simplified socket interface that the application layer connects to and the lower layer does all the routing and transmission stuff.