From: ahoward <ah...@us...> - 2003-06-12 22:01:59
|
Hi Peter: Ok, a couple of things on the InertiaCube. First, you should take the values reported by Player with a grain of salt, since I never really had the opportunity to test this properly. If I were you, I would instrument the driver with some print statements and check the raw values coming off the device, before they are packaged up and sent off by Player. Second, and more importantly, you will probably find that the IMU doesnt work nearly as well as you thought it would. This was certainly my experience: I had expected a magical black (blue) box that would solve all my localization problems once and for all. Sadly, this does not appear to be the case. Here are my observations in this unit, based on my (brief) testing: - The unit works best if you give it plenty of time to settle. This means: (1) turn it on and let it warm up (thermal stabilize) before use (a few minutes, at lease), and (2) once you have connected to the device, *dont* move it for the first minute or so. - The unit relies on a set of magnetometers to correct for drift in the yaw axis. These magnetometers are very sensitive to interference, so mount the unit on a long pole away from your robot (motors, computers, etc). This will, however, not help all that much, as the unit will still go haywire when you drive it past the (machine room | substation | desk leg | structural column | belt buckle). You can also try it with the compass turned off (set "compass 0" in the configuration file); the yaw will now drift quite rapidly, but it will no longer jump around mysteriously. - The build in accels are useless for anything except correcting the roll/pitch/yaw computations. This is an orientation sensor, not a full pose IMU. FWIW, we ended up getting the MicroStrain IMU. It has pretty similar properties, but gives us better software access to the internals of the device. I'm still playing with this one to see how useful the data really is. Let me know how you go on the InertiaCube. A. On 12 Jun 2003, Peter C. Lee wrote: > Hi Andrew, > > Thanks for your help. I got the IMU to work under Player, but the output > data from IMU doesn't seem to be encouraging. I did a randomwalk run on > robot and collected the orientation data. I observed that the robot had > made more than one 360 degree rotation, but the plot of IMU data never > showed that. The difference between anything 2 data points is no more > than 250 degree. > > I also ran a sample program from the manufacturer. I did not record the > data this time. However one thing that I observed is that it takes > sometime (more than 5 seconds) for the reading to be stabilized after > the robot comes to a full stop. Also the difference is quite large (20 > degrees). > > I tested the unit before, which I moved it around on my desk, I did not > see this big delay. > > I hope that you can give some opinions on the performance of this device > (even though you only have it for two weeks). Also what is the reason > that the unit was returned to the manufacturer? > > If you think this email is useful to other users, please forward to the > mailing list. > > > > Peter > > > Andrew Howard email: ah...@po... Department of Computer Science http: www-robotics.usc.edu/~ahoward University of Southern California phone: 1 (213) 740 6416 Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 << Insert pithy saying here >>> |
From: Alex M. <al...@ca...> - 2003-06-20 06:57:44
|
Hi Andrew, I'm having the same problem as John with compiling Player/Stage 1.3.2. both can't find RTK. Rtk itself compiles fine. I tried 3 suggested ways: 1. specifying installation paths, e.g. rtk $./configure --prefix=/usr/local/share/rtk-2.2.0 $make install Player $./configure --prefix=/usr/local/share/player-1.3.2 --with-rtk=/usr/local/share/rtk-2.2.0 2. putting everything into one place in user space (like you suggested) 3. finally, not specifying anything and letting it install into /usr/local I can see the library exactly where I tell it to put it but .configure can't find it. Also tried to put a symbolic link to librtk.a into /usr/lib, and running ldconfig Any suggestions? Alex Hi John: Do you have the latest version of RTK2, Player and Stage? If so, you can do a "user space" install like this: rtk2 > ./configure --prefix=/home/ahoward/local > make install player > ./configure --prefix=/home/ahoward/local > make install stage > ./configure --prefix=/home/ahoward/local > make install You should change the prefix to point to wherever you want it installed, of course. This is now the recommended method, and will produce the "new style" layout, with everything under ~/local/bin, ~/local/include, ~/local/lib, and so on. You can also specify the rtk path using the --with-rtk=<path> option on the configure line, but this is slightly more involved and should be avoided in preference for the method described above. A. P.S. I've cc'ed this to the user list, since you're probably not the only person seeing this. On Fri, 30 May 2003, John Sweeney wrote: > Hello -- > > I was hoping you could shed some light on a problem I was having trying > to compile stage, because it couldn't find RTK. I may be totally > missing something, but what I think the problem is that in the > configure.in script, when it calls AC_CHECK_LIB(rtk, rtk_init ...), the > test file that it tries to compile (with -lrtk) only includes -L/usr/lib > and -L/usr/X11R6/lib. Neither of which contain librtk on my system. (I > just have it in a personal directory.) Do you know how to get autoconf > to add -L$RTK_DIR/include to that list? Or could you tell me something > I'm doing wrong.... > > Thanks! > john > Andrew Howard email: ahoward@po... Department of Computer Science http: www-robotics.usc.edu/~ahoward University of Southern California phone: 1 (213) 740 6416 Los Angeles, CA, U.S.A. 90089-0781 fax: 1 (213) 821 5696 << Insert pithy saying here >>> |
From: Reed H. <he...@st...> - 2003-06-20 14:01:07
|
Quoting Alex Makarenko <al...@ca...>: > Player > $./configure --prefix=/usr/local/share/player-1.3.2 > --with-rtk=/usr/local/share/rtk-2.2.0 This is more or less what I do, and it works fine. (though I use a prefix of /usr/local for both). Take a look at your config.log for player, see if there are any useful errors in there when it tries to detect rtk. reed |
From: Mathew B. <mb...@ro...> - 2003-06-20 14:20:54
|
try deleting the config.cache, and then running the command's you listed. it will check the config.cache for rtk when you run the configure script to save time, if you just delete the config.cache file - it will force the configure script to actually go looking for rtk again. On Fri, 20 Jun 2003, Reed Hedges wrote: > Quoting Alex Makarenko <al...@ca...>: > > Player > > $./configure --prefix=/usr/local/share/player-1.3.2 > > --with-rtk=/usr/local/share/rtk-2.2.0 > > This is more or less what I do, and it works fine. (though I use a prefix of > /usr/local for both). > > Take a look at your config.log for player, see if there are any useful errors in > there when it tries to detect rtk. > > > reed > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > |
From: brian g. <bg...@us...> - 2003-06-20 18:52:36
|
On Fri, 20 Jun 2003, Mathew Brewer wrote: > try deleting the config.cache, and then running the command's you listed. > > it will check the config.cache for rtk when you run the configure script > to save time, if you just delete the config.cache file - it will force the > configure script to actually go looking for rtk again. > hi, I think that Matt's nailed it. In general, the results of configure's tests are cached in config.cache, to save time on subsequent runs. This is usually a good thing, but can easily trip you up. Unless you have an understanding of what is cached and what isn't, it's a good idea to delete your config.cache every time before re-running configure. Note that when configure runs, it tells you what results were read from the cache, by saying '(cached)' on the console. brian. |