From: Jayesh A. <jay...@ii...> - 2002-10-09 03:15:40
Attachments:
learn3.world
learn3.cc
|
Hi Brian, thanks for your help. Let me explain the results, and hope that you can spend a little of your time, and give me your suggestion. 1. I had given you a c++ program, and world file. I implemented your idea, and it worked. 2. But, if you remember from my first email, I need to simulate 4 robots, 6 moving targets. So I wrote a program, which does exactly the same thing as before now for each robot (10 in all), each robot working with a separate "thread". 3. But, I again had the problem of junk numbers for some sensor readings, so I tried to increase PLAYER_MAX_MESSAGE_SIZE to as high as 64 kb, 128 kb. 4. But, the best result was as follows: 3 or 4 robots work properly, with 16384 (16kb). If I add another robot in the program, I got junk numbers for say the position device, or there is no data for one of the vision device etc. Surprisingly, I did not get the message about packet size, unlike before: (**warning data available > space in Player packet ; ignoring data). /********************************************************************/ I have attached this program, with the world file. Program is very simple. there are 10 threads, each for 1 robot. The robot thread (4 in all), do the same thing as before, but for their own robots. The remaining 6 thread as for targets, and print position, and sonar data. That is it. As you can see in main(), 4 threads are used, others are "commented" out. The output should be similar as before (previous small program), only 4 times as many. With 16kb, everything is ok. But, if you uncomment even one more thread, then you would get some junk numbers for position device, or no data for say, vision device. (even if you increase that variable from 16kb). /********************************************************************/ I know you have already solved this problem. Am I having a different problem altogether? or should I wait for next release.(Can I get the patch to this problem earlier?). I need to implement it and publish results by 21st Oct. Thanks a lot for your help, Jayesh |
From: brian g. <bg...@po...> - 2002-10-10 00:38:49
|
On Tue, 8 Oct 2002, Jayesh Ametha wrote: > > Surprisingly, I did not get the message about packet size, unlike before: > (**warning data available > space in Player packet ; ignoring data). > right. that means that your client is in fact being sent *all* sensor data, which is good. > I have attached this program, with the world file. Program is very simple. > there are 10 threads, each for 1 robot. The robot thread (4 in all), do the > same thing as before, but for their own robots. The remaining 6 thread as > for targets, and print position, and sonar data. That is it. > > As you can see in main(), 4 threads are used, others are "commented" out. > The output should be similar as before (previous small program), only 4 > times as many. With 16kb, everything is ok. > > But, if you uncomment even one more thread, then you would get some junk > numbers for position device, or no data for say, vision device. (even if you > increase that variable from 16kb). > ok, i've experimented with your code and i think that i have figured out your problem: when you Read() in your clients, Stage has not yet generated simulated sensor data for all of your devices. Stage and Player run asynchronously and communicate through a shared memory buffer. Player doesn't know whether Stage has yet generated data for a device; Player will just read out the current data and send it to clients. this means that, in the case that Stage is very busy, it is possible for Player to read and send data for a device before Stage has actually generated any data for that device. in your case, when Stage is simultaneously starting up 30 or 40 devices, some of your clients are Read()ing before vision data has been generated, and so they receive null vision data. the more devices that you start, the busier Stage will be and the more likely this is to happen (i've found it to be a bit random, depending on subtle timing issues). fortunately, this problem is transient and the solution is very simple: Read() more that once. in your example program, you only Read() once for each client. if you, for example, Read() 5 times, then you'll get good data for all devices. i should note that this problem also exists with real devices. for example, the ACTS vision system can take a *long* time to start generating data, so a client may receive many rounds of nothing before getting good data. when data buffers have not yet been filled with actual data, they should always be initialized to something reasonable for that device, usually all zeros. if you get "junk" data for the simulated position device (i was not able to replicate that), then that probably means that it's not being initialized properly, which is bad (we'll look into it). however, if you Read() a few times, you'll get good data. we originally had a locking mechanism such that no data would be sent for a device until the device signalled that it had actually generated data. but that was not a very general solution, given the wide variety of ways in which devices can behave, and it caused many more problems than it solved. brian. |