wisar:wonderbox-xml-protocol [CS Wiki]

Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+Warning Request - for requesting warnings from Phairwell
+<pre>
+ WiSARIIII
+ <warningRequest/>
+</pre>
+Warning Response - 3 tier severity levels. 1 being the most critical.
+<pre>
+ WiSARIIII
+ <warning>
+ 	<source type="UAV" id="1032"> 	<!-- There may be many different telemetry sources, need unique identifier -->
+	<time>
+		<year> </year>
+		<month> </month>
+		<day> </day>
+		<hour> </hour>
+		<min> </min>
+		<sec> </sec>
+		<milli> </milli>
+	</time>
+        <severity> </severity>
+        <message>  </message>
+</warning>
+ </pre>
+Stream Request - for requesting video streams
+<pre>
+ WiSARIIII
+ <streamRequest>
+	<!--- channel is required -->
+	<channel type="video|still" id=int />
+	<!--- everything in control is OPTIONAL --->
+	<control>
+		<includeTelemetry type="last|interpolated|all" filter="all|tag">
+		<includeMeta when="once|all" />   	<!-- the image meta data (size, formaT) shouldnt change
+								after it has been sent once -->
+		<includeTiming value="true|false" /> 	<!-- optionally include timing information; useful for
+								real-time playback (e.g., where there may
+								have been dropped frames and we dont want
+								to make the video jerk forward -->
+		<includeID value="true|false" />	<!-- I won't store these, but instead will seek based
+								on the frame number.... -->
+		<seek startAt="frameNumber" pause="true|false">	<!-- startAt can be empty if the user want
+									to start with paused stream? -->
+		<!--- processing is performed in real-time on the wonderbox for
+ 			the subscriber - NOT on the source imagery.  It is needed
+			(for me) because i may be displaying on space-constrained devices
+			with weak processing units... we could also include things like brightness
+			and contrast here.  -->
+		<process>
+			<resize width="320" height="240" />	<!-- resize is always performed before window -->
+			<window x1="100" y1="50" x2="200" y2="200" />
+			<colorMode value="rgb|grey" />
+		</process>
+		<log enable="true|false">	<!-- if logging is disabled, seeking is not possible
+							We include this control mainlt for debugging purposes
+						-->
+		<echoControl enable="true|false|intital">	<!-- if enabled, anytime a control value is changed the set of control values is echoed.
+									if initial is set, the control values are sent only initially. -->
+	</control>
+ </streamRequest>
+</pre>
+Frame - a video frame response from the WonderBox
+<pre>
+ WiSARIIII
+ <frame>
+ 	<meta>
+ 		<compression type="uncompressed|jpeg|huffyuv" />
+		<size width="640" height="480">
+		<origin x="0" y="0"> <!-- We can set a region of interest in the frame request -->
+		<channels>3</channels><!-- We do support IR... in the future -->
+	</meta>
+	<device>0</device><!-- essentially the video port -->
+	<!-- this is retiming info, for playback - especially during seek, where we could return faster than capture does -->
+	<timing>
+		<captureTime>yyyymmddhhmmsszzz</delta>	<!-- year, month, day, hour, minute, second, millseconds of capture time -->
+	</timing>
+	<!-- on second thought, this id can be made into a simple integer representing the frame
+		offset since the server began recording on this channel.  This would allow
+		for unique identification of roughly 30,000 hours of video. We're safe with this.
+		Of course, when you seek, you need to specify the channel and type.
+		Also, since we support this type of definition, we dont need to worry
+		about telling the user how many frames are available.
+		-->
+	<id>32442</id>
+	<!-- Length specified the number of RGB bytes following this packet under normal transmission.
+	     Note that the optional useShared property indicates that the image data
+             is stored in a shared memory segment, rather than following the packet. The
+             sharedSegmentName is the name of the memory segment where the pixel data resides. -->
+	<data length="" [useShared="sharedSegmentName"] >
+	<!-- do we include a list of telemetry?  Or do we only allow the user to receive a single type? -->
+	<telemetrys>
+		<telemetry />
+		<telemetry />
+	</telemetrys>
+ </frame>DATA
+</pre>
+Telemetry packet
+<pre>
+ <telemetry>
+	<source type="UAV" id="1032"> 	<!-- There may be many different telemetry sources, need unique identifier -->
+	<tags>
+		<tag name="" value="">
+	</tags>
+	<time>
+		<year> </year>
+		<month> </month>
+		<day> </day>
+		<hour> </hour>
+		<min> </min>
+		<sec> </sec>
+		<milli> </milli>
+	</time>
+	<location>
+		<lat> </lat>
+		<lon> </lon>
+		<alt> </alt>
+	</location>
+	<pose>
+		<roll></roll>
+		<pitch></pitch>
+		<yaw></yaw>
+	</pose>
+	<cameras>
+		<camera type="video" name="main gimbal">
+			<lat> </lat>
+			<lon> </lon>
+			<alt> </alt>
+			<elevation> </elevation>
+			<azimuth> </azimuth>
+		</camera>
+	</cameras>
+ </telemetry>
+</pre>
+Request a telemetry stream
+<pre>
+<telemetryRequest/>
+</pre>
+Indicate (from a client) that you have frames for the WonderServer to log
+<pre>
+<frameSource/>
+</pre>
+Request info from the db about a particular channel
+<pre>
+<getChannelInfo>
+     <channel>1</channel>
+</getChannelInfo>
+</pre>
+Channel info response to the channel info request above
+<pre>
+<channelInfo>
+     <totalFrames>1233</totalFrames>
+</channelInfo>
+</pre>
+Request a single frame
+<pre>
+<frameRequest>
+      <channel>1</channel>
+      <offset>123</offset>
+      <useShared>nameOfSharedMemorySegment</useShared>
+</frameOffset>
+</pre>
+Configure the request cache
+<pre>
+<cacheConfig>
+      <min></min>
+      <max></max>
+</cacheConfig>
+</pre>

wisar/wonderbox-xml-protocol.txt · Last modified: 2014/08/11 13:24 by tmburdge

Back to top