[SPAM] [omniORB] Advice needed.. (I'm a newbie)

renny.koshy at rubixinfotech.com renny.koshy at rubixinfotech.com
Thu Jan 27 09:28:49 GMT 2005


Aaron

Couple of suggestions, but before that just an overview of why I would 
suggest them:

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...

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...

My suggestions from my experiences with omniORB, omniEvents, UDP, 
multicasts, etc:

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.

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)

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.

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.

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.

If you like these suggestions and need further advice or help, please 
email and I can see what we can offer,

Good luck,

Renny Koshy
President & CEO

--------------------------------------------
RUBIX Information Technologies, Inc.
www.rubixinfotech.com




agbernardino at up.edu.ph
Sent by: omniorb-list-bounces at omniorb-support.com
01/26/2005 11:57 PM

 
        To:     omniORB-list at omniorb-support.com
        cc: 
        Subject:        [SPAM] [omniORB] Advice needed.. (I'm a newbie)



Greetings.. I'm a student from the Philippines. I'm new to corba and 
omniorb. 
I'll be starting an undergrad project in the next few months.  My project 
is
LAN-Based teleoperation of a mobile robot.  I plan to have an wireless lan
omniorb communication between the robot and a server. I also plan to have 
a
Jacorb applet communicating with an omniorb server.  The camera-equipped 
robot
will be sending   still images, and some data to the applet through the 
server.
The applet should receive the images at a rate that would look like real 
time
video feed.  Also, other data would be passed between applet and the 
robot.  My
server would be an intel celeron 1.5ghz running Mandrake 10.1.  The robot 
runs
with a 500mhz pentium running Redhat 7.2.  All of the communication will 
only
take place on a LAN.  The robot will be communicating with the server via
wireless LAN.

My questions are :
1.  I'm starting by April. I have 5 months to do the project.  Can I 
understand
and program the CORBA apps in such time?  Are the CORBA apps that hard or 
easy
to engineer?
2.  Will I have to deal with threads to achieve fast communication? (I 
hope I
don't)
3.  Do I have to have 2 separate omniorb servers (robot-server and
server-applet), or can I have a 2-in-1 server?
4. Any other advice ? =)

Thank you very much,
Aaron Bernardino




_______________________________________________
omniORB-list mailing list
omniORB-list at omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omniorb-list



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20050127/4637ff41/attachment.htm


More information about the omniORB-list mailing list