From chrisdzrobot at gmail.com Tue Aug 16 17:42:51 2011 From: chrisdzrobot at gmail.com (xu zhong) Date: Tue, 16 Aug 2011 17:42:51 -0400 Subject: [Aria-users] laser 2(vertical) of patrolbot doesn't work Message-ID: Hi All, I am working on the 3D mapping based on the laser of patrolbot. There are two lasers came with the patrolbot, where laser 1 is horizontal, and laser 2 is vertical. The OS of patrolbot is Windows XP. Laser 1 (horizontal) work normally by the method in ARNL manual: c:\Program Files\MobileRobots\ARNL\bin arnlserver.exe -rp COM2. But the robot cannot connect to laser 2 (vertical). I tried c:\Program Files\MobileRobots\ARNL\bin arnlserver.exe -rp COM2 -lpt serial -lp COM4. The CMD display: ' lms2**_1:waiting for laser to power on'. After red and yellow light is on, the green light of laser 2 is on. Then display: ' lms2**_1: Failed to connect to laser, no poweron received. ArLaserConnecter::connectLaser:Could not connect lms2**_1,stopping Could not connect to all lasers.... exiting '. Can you tell me how to connect to laser 2(vertical) of patrolbot by ARNL? And is it possible to connect two laser at the same time and show in mobile eyes? Thanks ! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mobilerobots.com/pipermail/aria-users/attachments/20110816/d1d54a5b/attachment.html From Zeb.Dahl at Adept.com Wed Aug 17 14:52:25 2011 From: Zeb.Dahl at Adept.com (Zeb Dahl) Date: Wed, 17 Aug 2011 11:52:25 -0700 Subject: [Aria-users] laser 2(vertical) of patrolbot doesn't work In-Reply-To: References: Message-ID: <38B0EB303E4E804F8A93B5CFA8FFF15F02ED8FF765@SRV-APP-6.adept.local> Hello, You are doing more or less the right thing to connect to the second laser. Try testing using Aria demo with just the -lp command to define the serial port used for the laser. If the laser still will not connect, check the connection to the laser to make sure nothing is damaged or disconnected. I am a bit confused as to why you are using COM2 for the microcontroller serial port. Our common default configuration is to use COM1 for the microcontroller and COM3 for the primary laser. The secondary laser will use COM2 or COM4. Since ARNL and MobileEyes only use 2D maps, it will not be possible to display the data from the second laser in a sensible way in MobileEyes. You can set up a second laser in the params file (found in the Arnl/params/ directory), but it assumes that the laser scans will be in the same plane as (or parallel to) the other laser. If you need further help getting the laser to connect, please contact support at mobilerobots.com and include the serial number of the robot. Best, Zeb Dahl Research Robot Support Adept MobileRobots support at mobilerobots.com From: aria-users-bounces at lists.mobilerobots.com [mailto:aria-users-bounces at lists.mobilerobots.com] On Behalf Of xu zhong Sent: Tuesday, August 16, 2011 5:43 PM To: ariausers Subject: [Aria-users] laser 2(vertical) of patrolbot doesn't work Hi All, I am working on the 3D mapping based on the laser of patrolbot. There are two lasers came with the patrolbot, where laser 1 is horizontal, and laser 2 is vertical. The OS of patrolbot is Windows XP. Laser 1 (horizontal) work normally by the method in ARNL manual: c:\Program Files\MobileRobots\ARNL\bin arnlserver.exe -rp COM2. But the robot cannot connect to laser 2 (vertical). I tried c:\Program Files\MobileRobots\ARNL\bin arnlserver.exe -rp COM2 -lpt serial -lp COM4. The CMD display: ' lms2**_1:waiting for laser to power on'. After red and yellow light is on, the green light of laser 2 is on. Then display: ' lms2**_1: Failed to connect to laser, no poweron received. ArLaserConnecter::connectLaser:Could not connect lms2**_1,stopping Could not connect to all lasers.... exiting '. Can you tell me how to connect to laser 2(vertical) of patrolbot by ARNL? And is it possible to connect two laser at the same time and show in mobile eyes? Thanks ! -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 10237 bytes Desc: not available Url : http://lists.mobilerobots.com/pipermail/aria-users/attachments/20110817/0ef8aeb0/attachment-0001.bin From tgaaly at gmail.com Mon Aug 22 03:16:22 2011 From: tgaaly at gmail.com (Tarek El-Gaaly) Date: Mon, 22 Aug 2011 03:16:22 -0400 Subject: [Aria-users] mobilesim odometry bug! Message-ID: I have a problem with the odometry when using mobilesim. If I rotate the robot more than 90 degrees and tell it to move forward by 100 mm it always over does the forward motion (i.e. moves much more) - the odometry shows a much larger distance moved than the 100mm. When I move the robot in the positive x direction (set according to the initial position) it works correctly but when I rotate back and move in the negative direction of x it gives me much larger values. Does anybody know why? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.mobilerobots.com/pipermail/aria-users/attachments/20110822/d732dd5e/attachment.html From Reed.Hedges at Adept.com Mon Aug 22 09:54:55 2011 From: Reed.Hedges at Adept.com (Reed Hedges) Date: Mon, 22 Aug 2011 06:54:55 -0700 Subject: [Aria-users] mobilesim odometry bug! In-Reply-To: References: Message-ID: <38B0EB303E4E804F8A93B5CFA8FFF15F02ED733C9C@SRV-APP-6.adept.local> Hello, how big is the error? For example, if you move 1000 mm (one meter) forward, how big is the error then? MobileSim does a simple simulation of odometry error -- i.e. it just adds a little bit of random error while moving. You can set the range of this error to 0 to disable it by editing PioneerRobotModels.inc Reed -- Reed Hedges Research Support and Software Adept Technology Inc. - Mobile Robots reed.hedges at adept.com http://www.mobilerobots.com - http://www.adept.com For documentation and support, visit http://robots.mobilerobots.com ________________________________________ From: aria-users-bounces at lists.mobilerobots.com [aria-users-bounces at lists.mobilerobots.com] On Behalf Of Tarek El-Gaaly [tgaaly at gmail.com] Sent: Monday, August 22, 2011 3:16 AM To: ariausers Subject: [Aria-users] mobilesim odometry bug! I have a problem with the odometry when using mobilesim. If I rotate the robot more than 90 degrees and tell it to move forward by 100 mm it always over does the forward motion (i.e. moves much more) - the odometry shows a much larger distance moved than the 100mm. When I move the robot in the positive x direction (set according to the initial position) it works correctly but when I rotate back and move in the negative direction of x it gives me much larger values. Does anybody know why? -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3701 bytes Desc: not available Url : http://lists.mobilerobots.com/pipermail/aria-users/attachments/20110822/b268cb63/attachment.bin From Reed.Hedges at Adept.com Mon Aug 22 09:57:03 2011 From: Reed.Hedges at Adept.com (Reed Hedges) Date: Mon, 22 Aug 2011 06:57:03 -0700 Subject: [Aria-users] P3DX Encoder and Gyro calibration In-Reply-To: References: <38B0EB303E4E804F8A93B5CFA8FFF15F02DF4868CB@SRV-APP-6.adept.local> <38B0EB303E4E804F8A93B5CFA8FFF15F02ED6571D6@SRV-APP-6.adept.local> , Message-ID: <38B0EB303E4E804F8A93B5CFA8FFF15F02ED733C9D@SRV-APP-6.adept.local> MobileSim (and the robots) provide a position estimate as coordinates within a global coordinate system (which happens to be located according to the robot's startup location). It is not local to the robot. We call it "odometry" because that is the source from which this position is derived, but it is actually a position on a global coordinate system. Does this help? Reed -- Reed Hedges Research Support and Software Adept Technology Inc. - Mobile Robots reed.hedges at adept.com http://www.mobilerobots.com - http://www.adept.com For documentation and support, visit http://robots.mobilerobots.com ________________________________________ From: Tarek El-Gaaly [tgaaly at gmail.com] Sent: Monday, August 22, 2011 3:01 AM To: Reed Hedges Subject: Re: [Aria-users] P3DX Encoder and Gyro calibration Just want to add, this happens when i rotate more than 90 degrees. So if i turn say 10 degrees and then move 300 mm....and repeat...i get all correct odometry values until i start going in the other direction (i.e. the angle of full rotation from the initial orientation exceeds 90 degrees). Sorry for sending so many emails. Im in a bit of a pickle On Mon, Aug 22, 2011 at 12:38 AM, Tarek El-Gaaly > wrote: sorry i got the last bit wrong - [x,y,theta] odometry correpsonds to the distance moved in the x axis (which is the axis of forward motion at the starting position) and the y-axis which is orthogonal to the x-axis at the starting point. Am I correct? have u seen a problem like this before? Do my odometry readings make sense? I MUST be missing something trivial here. Thanks a million for ur help! On Mon, Aug 22, 2011 at 12:35 AM, Tarek El-Gaaly > wrote: Hi Reed, Im sorry to bother you again. I have a serious problem regarding the odometry of mobilesim. If I tell the robot to turn 90 degrees and then move 300mm it sometimes give me odometry of 3 times that much (e.g. 993.765 as shown below). This happens usually when Im moving the robot in a diagonal direction and not parallel to any axis. Below is each motion command and the incremental encoder odometry measured after it [x,y,theta]. This is confusing the bots out of me right now. How does this odometry work? What I understand is that x is the distance moved, y is the orthogonal motion (drift), theta is the angle turned. But I seem to get wrong values many of the times. turning robot...90 counter-clockwise *** encoder odo: [0 , 0 , 89.9132] moving robot...300 in mm *** encoder odo: [0 , 993.765 , 89.9132] moving robot...300 in mm *** encoder odo: [0 , 1660.64 , 89.9132] moving robot...300 in mm *** encoder odo: [0 , 2394.93 , 89.9132] Another example is: turning robot...180 counter-clockwise *** encoder odo: [0 , 0 , 179.914] moving robot...300 in mm *** encoder odo: [-662.995 , 0.97 , 179.914] moving robot...300 in mm *** encoder odo: [-1325.99 , 0.97 , 179.914] On Wed, Jul 13, 2011 at 3:12 PM, Reed Hedges > wrote: Have you compared the results on carpet to a hard floor? I?m told that you?ll see more position drift on carpet in fact because the carpet itself may be pushing the tires sideways ? this kind of motion or any other small slide to the side cannot be corrected by the gyro, which only senses rotation. And yes, you will not get 100% accuracy out of the robot and encoder system, and this error will accumulate over time, so this is why we do offer SONARNL and ARNL to deal with that. From: Tarek El-Gaaly [mailto:tgaaly at gmail.com] Sent: Wednesday, July 13, 2011 1:45 PM To: Reed Hedges Cc: Mrityunjay Subject: Re: [Aria-users] P3DX Encoder and Gyro calibration Hi Reed, We calibrated the driftFactor, gyroCW (clockwise) and gyroCCW (counter-clockwise) of our pioneer p3dx robot. The robot moves straighter than before in our indoor carpeted environment but still after a long path it drifts (leftwards). When I calibrated the driftFactor the robot seemed to correct for drift for some time but then started drifting like before again. Is this there anyway we can get close to 100% straight line motion through encoder/gyro calibration ALONE or do we have to use more information about the environment through the use of sonars for example? Thank you very much for your help? On Fri, Jun 24, 2011 at 10:42 AM, Mrityunjay > wrote: Specifications of the corridor - Width = 1.75m Wooden walls, with mostly open areas. Thin commercial carpet. We start the robot at the center of the hallway (almost 0.85m from one side) and with a command to move forward (10m) the robot touches the left wall at the distance of 5-6m. I checked with the spirit leveler and it seems the floor of the hallway is pretty flat. Can you please explain encoder calibration parameters and how do they effect the robot's motion, driftFactor, revCount, ticksMM ? Also explain the HasGyro mode 1 and how is it different from mode 2. Thanks, Mrityunjay On Fri, Jun 24, 2011 at 9:45 AM, Reed Hedges > wrote: The Gyro is an optional component, so you should check whether you have it (look at the robot's documentation, check for the small gyro board in the robot, or send its serial number and I'll look it up.) Normally the gyro doesn't need much calibration but we check it when assembling it and set if it needed. gyrCW and gyroCCW are the parameters for gyro calibration. The process is sort of similar to the encoders - rotate the robot without turning the wheels (e.g. put it on a turntable or hold it up off the ground) and check reported rotation vs. externally measured. I recommend using HasGyro 2 if you want to use the gyro, it's simpler. If your robot doesn't have the gyro, you must use HasGyro 0, otherwise the robot has meaningless input from the nonexistent gyro :) Also is a good idea to take a quick look at the condition of the tires and wheels every once in a while and make sure they're even and straight, if the robot is an older one or has been shipped or moved around a lot. What error do you get in your corridor for straight translation? You are right that sonar is very sensitive to interactions with the environment. We had pretty good results in rooms of our offices that had synthetic tile or low/thin/dense commercial carpet and plain painted walls (not sound absorbing cloth) if the walls and other furniture with simple flat surfaces were generally close enough for the robot to see a few features (such as doors and corners) - within 10 m. So if your hallway is similar and has some large features such as open doors or cabinets then it might work OK, especially to keep the robot in the center of the hall and not drift to the side-there may be a bit more error along the axis of the hall (though large features on the sides will help correct that as it passes them). Reed From: aria-users-bounces at lists.mobilerobots.com [mailto:aria-users-bounces at lists.mobilerobots.com] On Behalf Of Mrityunjay Sent: Thursday, June 23, 2011 3:41 PM To: ariausers Cc: tgaaly at gmail.com Subject: [Aria-users] P3DX Encoder and Gyro calibration Hello, We are trying to calibrate our Pioneer P3DX for a simple task (?) of navigating the robot in a straight line on carpeted corridor by giving set of (x,y, th) poses.Sonar readings are quite unreliable (may be because of Carpets, wooden walls, etc) and can not be used for sonar based localization, though they are being used for simple obstacle detection. So to calibrate the encoders we followed the instructions given in the manual and after changing the params (as given below) found robot is quite accurate (1001/1000 mm, 89.9/90 deg) in terms of transnational motion and rotational motion - DriftFactor = 5 RevCount = 19000 HasGyro = 0 Although the robot was not moving in straight line even after changing the above params, may be because the HasGyro was set to 0. So then we changed the HasGyro to 1 and robot messes up the rotational motion and over does the rotation (137 for 90 degree), similar things happen when the HasGyro is set to 2. So regarding this I have following questions - 1. Can you shortly explain the function of following calibration parameters (how does increasing and decreasing these params affects robot's motion) - driftFactor, revCount, ticksMM, gyroCW and gyroCCW. 2. What does the different values of HasGyro mean, which mode is recommended to use for our application scenario. 3. Difference between th (ArRobot::getTh( )), robot_th and gyro_th. 4. Is there any recommended method to use while navigating the robot in long (30-40m) corridors (1.75m wide). Thanks, Mrityunjay _______________________________________________ Aria-users mailing list Aria-users at lists.mobilerobots.com http://lists.mobilerobots.com/mailman/listinfo/aria-users To unsubscribe visit the above webpage or send an e-mail to: aria-users-leave at lists.mobilerobots.com Visit http://robots.mobilerobots.com for information including documentation, FAQ, tips, manuals, and software, firmware and driver downloads. Mailing list archives are at http://lists.mobilerobots.com/ -- Best Regards, Tarek El-Gaaly, M.S. PhD Student, Rutgers University :):):):):):)::):):):):):)::):):):):):)::):):):):):) http://www.cs.rutgers.edu/~tgaaly :):):):):):)::):):):):):)::):):):):):)::):):):):):) Personal Blog: http://www.tgaaly.blogspot.com :):):):):):)::):):):):):)::):):):):):)::):):):):):) -- Best Regards, Tarek El-Gaaly, M.S. PhD Student, Rutgers University :):):):):):)::):):):):):)::):):):):):)::):):):):):) http://www.cs.rutgers.edu/~tgaaly :):):):):):)::):):):):):)::):):):):):)::):):):):):) Personal Blog: http://www.tgaaly.blogspot.com :):):):):):)::):):):):):)::):):):):):)::):):):):):) -- Best Regards, Tarek El-Gaaly, M.S. PhD Student, Rutgers University :):):):):):)::):):):):):)::):):):):):)::):):):):):) http://www.cs.rutgers.edu/~tgaaly :):):):):):)::):):):):):)::):):):):):)::):):):):):) Personal Blog: http://www.tgaaly.blogspot.com :):):):):):)::):):):):):)::):):):):):)::):):):):):) -- Best Regards, Tarek El-Gaaly, M.S. PhD Student, Rutgers University :):):):):):)::):):):):):)::):):):):):)::):):):):):) http://www.cs.rutgers.edu/~tgaaly :):):):):):)::):):):):):)::):):):):):)::):):):):):) Personal Blog: http://www.tgaaly.blogspot.com :):):):):):)::):):):):):)::):):):):):)::):):):):):) From dowlr at essex.ac.uk Mon Aug 22 12:51:27 2011 From: dowlr at essex.ac.uk (Dowling, Robin) Date: Mon, 22 Aug 2011 16:51:27 +0000 Subject: [Aria-users] mobilesim odometry bug! In-Reply-To: <38B0EB303E4E804F8A93B5CFA8FFF15F02ED733C9C@SRV-APP-6.adept.local> References: <38B0EB303E4E804F8A93B5CFA8FFF15F02ED733C9C@SRV-APP-6.adept.local> Message-ID: Could this be down to the bug that some have been experiencing with MobileSim and the move command? Tarek, are you using move in your code or SetVel? Regards Robin -----Original Message----- From: aria-users-bounces at lists.mobilerobots.com [mailto:aria-users-bounces at lists.mobilerobots.com] On Behalf Of Reed Hedges Sent: 22 August 2011 14:55 To: ariausers Subject: Re: [Aria-users] mobilesim odometry bug! Hello, how big is the error? For example, if you move 1000 mm (one meter) forward, how big is the error then? MobileSim does a simple simulation of odometry error -- i.e. it just adds a little bit of random error while moving. You can set the range of this error to 0 to disable it by editing PioneerRobotModels.inc Reed -- Reed Hedges Research Support and Software Adept Technology Inc. - Mobile Robots reed.hedges at adept.com http://www.mobilerobots.com - http://www.adept.com For documentation and support, visit http://robots.mobilerobots.com ________________________________________ From: aria-users-bounces at lists.mobilerobots.com [aria-users-bounces at lists.mobilerobots.com] On Behalf Of Tarek El-Gaaly [tgaaly at gmail.com] Sent: Monday, August 22, 2011 3:16 AM To: ariausers Subject: [Aria-users] mobilesim odometry bug! I have a problem with the odometry when using mobilesim. If I rotate the robot more than 90 degrees and tell it to move forward by 100 mm it always over does the forward motion (i.e. moves much more) - the odometry shows a much larger distance moved than the 100mm. When I move the robot in the positive x direction (set according to the initial position) it works correctly but when I rotate back and move in the negative direction of x it gives me much larger values. Does anybody know why?