On Tuesday 16 November 2010 13:08:50 steve wrote:
On 11/15/2010 11:05 PM, Shamit Verma wrote:
Yes and that's the reason I added in the initial response:
Where will the main 'engine' for the robot run ? on the robot's
controller ? In
any case, for this use case you needn't touch java at all IMHO. All
client side
stuff can be done using javascript.
This was not about controller, that would in any case be independent of UI. Controller would be running on Robot and UI would be running inside a browser. UI needs to talk to this controller and JS is not the best option for that. JS restricts UI to http request/response based communication.
Over-simplification much ?
The whole problem is wanting on the fly changes anywhere in the chain, the whole system being highily experimental. It is likely to be more than 2 years in getting a fair idea of the actual field requirements. If i use a c/py/whatever core on the robot and a suitable standalone UI I would be maintaing a lot more code than a browser based setup. Besides there is the everpresent problem of bitrot in standalone isolated systems like this.
Further a browser based setup might help in simply plugging in additional frameworks (like VR) without too much problems.
From whatever I have read (and my highily biased everything-under-my-control view), it seems a lot of expermentation is on the cards.