<br><font size=2 face="sans-serif">Aaron</font>
<br>
<br><font size=2 face="sans-serif">Couple of suggestions, but before that just an overview of why I would suggest them:</font>
<br>
<br><font size=2 face="sans-serif">1. As my engineering project during college, I designed a video/voice ethernet device, and did extensive research into available protocols and junk (early 90's). Times have changed...</font>
<br>
<br><font size=2 face="sans-serif">2. We use omniORB and omniEvents to control a realtime device for telephony. We end up processing many hundreds of messages per second. I have tried many different attempts at real-time data for this stuff...</font>
<br>
<br><font size=2 face="sans-serif">My suggestions from my experiences with omniORB, omniEvents, UDP, multicasts, etc:</font>
<br>
<br><font size=2 face="sans-serif">A. Use a UDP multicast or unicast to deliver your video -- There are many protocols available for this nowadays, or make your own. This has the least impact and will not bog down your processes. Since it's real-time video, if you lose data it's not that criticial, vs. not being able to keep up with the feed. Most protocols used to do this would do something like a single FULL FRAME update followed by delta packets... I did this for a 200x160 image, which was rather small. Should work for larger images, and this is also the theory behind MPG encoding and such.</font>
<br>
<br><font size=2 face="sans-serif">Again, using multi-casts allows you to have one or more "subscribers" to that broadcast address getting this info with no additional load on the actual network (wire level)</font>
<br>
<br><font size=2 face="sans-serif">B. Status information that the robot sends can also be done via UDP multicasts. Again, if someone is watching it, they can see the info, if no-one is watching, no worries.</font>
<br>
<br><font size=2 face="sans-serif">C. Use omniORB for *control* and other info that must be passed reliably. This information shouldn't be trusted to an unreliable protocol. Additionally, since most things you tell the robot will be implemented as "functions"... you can simply extend that function to the outside world by using an ORB. This way, when the control program call "ArmMovement(LEFT_ARM, DIRECTION_UP, 30)" -- just as an example -- it would execute the corresponding function in the robot, causing the arm to move. This would be very intuitive to program with, and you can pass back status information or pass/fail data using an OUT parameter.</font>
<br>
<br><font size=2 face="sans-serif">D. omniORB does its own threading, so you don't have to worry about it. The only problem is that you should be careful to follow normal thread-synchronization guidelines -- i.e. you don't want your robot trying to move it's arm UP and DOWN at the same time because you somehow sent two requests. A simple mutex or semaphore should prevent these.</font>
<br>
<br><font size=2 face="sans-serif">If you like these suggestions and need further advice or help, please email and I can see what we can offer,</font>
<br>
<br><font size=2 face="sans-serif">Good luck,</font>
<br>
<br><font size=2 face="sans-serif">Renny Koshy<br>
President & CEO<br>
<br>
--------------------------------------------<br>
RUBIX Information Technologies, Inc.<br>
www.rubixinfotech.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>agbernardino@up.edu.ph</b></font>
<br><font size=1 face="sans-serif">Sent by: omniorb-list-bounces@omniorb-support.com</font>
<p><font size=1 face="sans-serif">01/26/2005 11:57 PM</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: omniORB-list@omniorb-support.com</font>
<br><font size=1 face="sans-serif"> cc: </font>
<br><font size=1 face="sans-serif"> Subject: [SPAM] [omniORB] Advice needed.. (I'm a newbie)</font></table>
<br>
<br>
<br><font size=2 face="Courier New"><br>
Greetings.. I'm a student from the Philippines. I'm new to corba and omniorb. <br>
I'll be starting an undergrad project in the next few months. My project is<br>
LAN-Based teleoperation of a mobile robot. I plan to have an wireless lan<br>
omniorb communication between the robot and a server. I also plan to have a<br>
Jacorb applet communicating with an omniorb server. The camera-equipped robot<br>
will be sending still images, and some data to the applet through the server.<br>
The applet should receive the images at a rate that would look like real time<br>
video feed. Also, other data would be passed between applet and the robot. My<br>
server would be an intel celeron 1.5ghz running Mandrake 10.1. The robot runs<br>
with a 500mhz pentium running Redhat 7.2. All of the communication will only<br>
take place on a LAN. The robot will be communicating with the server via<br>
wireless LAN.<br>
<br>
My questions are :<br>
1. I'm starting by April. I have 5 months to do the project. Can I understand<br>
and program the CORBA apps in such time? Are the CORBA apps that hard or easy<br>
to engineer?<br>
2. Will I have to deal with threads to achieve fast communication? (I hope I<br>
don't)<br>
3. Do I have to have 2 separate omniorb servers (robot-server and<br>
server-applet), or can I have a 2-in-1 server?<br>
4. Any other advice ? =)<br>
<br>
Thank you very much,<br>
Aaron Bernardino<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
omniORB-list mailing list<br>
omniORB-list@omniorb-support.com<br>
http://www.omniorb-support.com/mailman/listinfo/omniorb-list<br>
<br>
</font>
<br>
<br>