Version 1.7.0 April 23, 2009 ------------------------- IMPORTANT NOTE: This release includes a major change in the architecture of ARNL. Instead of a single library (either libArnl or libSonArnl) being provided, ARNL has been split into a base library that includes common utilities and the path planning features, plus separate libraries each containing a localization method. There are currently three localization libraries available to customers: Arnl (laser localization), SonArnl (sonar localization) and MOGS (GPS positioning/localization). Some changes to the existing laser and sonar localization classes include: * Parameters for all localization methods, and path planning, are now stored in the arnl.p file. sonarnl.p is no longer used. Each localization library has its own section within arnl.p. * Instead only one laser or sonar localization object allowed, multiple localization task objects with different sensors can now optionally be handled and merged into one pose. This is done using weighted averages of the estimates from the different localizations. The weights are related to the uncertainity of the estimates. * The actual merging of the localization information is done by ArLocalizationManager. This is where the robot is "moveTo" after the merge. This is a new thread looping through at 10 times a second. * If you only want to use one localization method, you can only create a localization task object, as before, ArLocalizationManager is not needed in this case. * The reflector localization has been reworked to correctly incorporate the last localized encoder pose. * The MCL localization is merged with the reflector localization if the reflectors and enabled. The resulting estimate is held in memory and the moveTo is eliminated. * The reflector data from the ArRobotAndLaser contains the number of actual dots seen per reflector in addition to its centers. This allows us to eliminate reflectors with one dot which gets caught at the average on corners. This used to cause wild jumps in the kalman pose from reflectors. * The localization manager queries the different localizations on their estimate using their common findLocalizationMeanVar() function. * Redid the forward kinematics for all the motion in all the kalmans involved. * Added drawing functions to see the mean and variance of any localization. * Made ArLocalizationTask and ArSonarLocalization task inherit from a parent class ArBaseLocalizationTask * Made ArSonarLocalizationTask::getState return LocalizationState instead of SonarLocalizationState (to go with above change) Other changes: * Java wrapper libraries are now in packages with the following names: com.mobilerobots.BaseArnl for Base, com.mobilerobots.Arnl for ARNL and com.mobilerobots.SonArnl for SONARNL, and com.mobilerobots.MOGS for MOGS. Similarly, ARIA and ArNetworking are now in com.mobilerobots.Aria and com.mobilerobots.ArNetworking packages. Programs using the Java wrapper library must now use "import" statements to access the ARNL, ARIA and ArNetworking package namespaces, e.g.: import com.mobilerobots.Aria.*; import com.mobilerobots.ArNetworking.*; import com.mobilerobots.BaseArnl.*; import com.mobilerobots.Arnl.*; * MultiRobot now has an option for robots to still send their paths when they are stopped, so that with many robots the lower priority ones can sort things out among themselves better * Bug fixed in ArPathPlanningTask::getPathFromTo() (double unlock of map) * The PlanEveryTime option has been removed from configuration. * Final goal approach movement does more checking to determine whether any obstacles may violate the front and side clearance and padding parameters. * Changes to make ArPathPlanningTask and ArLocalizationTask work with any range device and any laser respectively, not just SICK lasers. * A new parameter has been added, CheckInsideRobotRadius. If true (default), ARNL will now not move the robot if any obstacles are detected within the radius of the robot body, i.e. if the robot could hit the obstacle by rotating. ARNL 1.5.1 February 19, 2007 ------------------------ Version built with ARIA 2.5.1 ARNL 1.5.0 December 1, 2006 ------------------------- ************** Important Note ************** It is _VERY_ important to note that this version of ARNL drives and path plans very differently (and much better!) than older versions, but that you may need to adjust some parameters to get this to happen. If you use old parameters the path planning may actually be worse but will at least be much much slower. The new version follows the path much more closely than older versions. This version uses all of the movement parameters to determine how fast it needs to go at each point in the path. This means it uses the rotVelMax, rotAccel, rotDecel, transAccel, and transDecel to see how fast it can go around a corner, and when it has to start decelerating to make the turn. You can adjust the 'Driving*' parameters in the 'Path Planning settings' section, that will change the parameters in such a way that they will only apply when ARNL is path planning (so it won't affect teleop, or other driving you do with the robot). This involves sending those commands down to the robot whenever the path planning takes over, so if you aren't connected directly from the computer this might cause some problems. You can set these same parameters in the new 'Robot config' parameter section and they will only be sent down once, but they will apply to all driving the robot does. If you leave those parameters at their defaults of 0 the value used comes from the firmware. If you want to adjust those or see what that is you can use the configuration program for the microcontroller (ARCOScf, AROScf, p2oscf, etc). Some values we've used are a rotVelMax of 250, rotAccel of 300, rotDecel of 300, transAccel of 600, transDecel of 600. This isn't appropriate for all robots or situations, but should give you an idea of the range of values, and that the higher you set them the better and faster ARNL will drive. You should obviously find values appropriate to your robot, your robot's payload, your robot's environment, your robot's environment, and your robot's task. Note that for some of these you may need to change the *Top value with the configuration program for the microcontroller (some old robots shipped with low Top values). Also note that you that the gyros that we use will only give accurate readings until 300 degrees/sec, so your rotVelMax should never go over that value, and probably shouldn't come close. It is okay if the rotAccel or rotDecel is higher. If you are using ARCOS you should get the latest version (1.9), since there was a bug in previous versions where rotDecel and rotAccel (or transAccel and transDecel) sent in the same 5 millisecond period would cause the first one to be overwritten which causes problems (especially since the software's idea of how the robot was driving didn't match the robot's idea). * Changes and fixes to the DWA code makes the robot weigh an objective based on Match, Velocity and Distance (to collision), instead of Heading, Velocity and Distance. The match function finds the (vel, rotvel) combination that best matches the path segment computed by the local path planning. This has dramatically improved the tracking of the desired path by the robot and almost eliminated the oscillations about the path that used to happen when the robot path changed direction at high speed. It now also checks to see if the curvature of the path causes the required rotational accels and decels to exceed the robot limits, in which case it reduces the velocity. Earlier check only check the rotational velocity limits for the curved paths. NOTE, this change may require changes to robot motion parameters to achieve good performance (see above) * Changed the default linear velocity increments being searched from 1 to 3. Also made the path match distance small enough so that the robot behaved well in crowded and open spaces. * Fixed the problem with premature goal "end move" triggering based on distance instead of making sure a straight collision free path existed before switching to straight line encoder based "end move". * Reduced flipping of the local path because the bounding box skirted obstacles and would expand and contract between cycles. Now the bounding box also envelopes the closest obstacle on its edges. Also marked the old path in the map to cost less during the find path in the current plan. * Replaced parameter FreeSpacing with PlanFreeSpace which will measure the distance from the side of the robot instead of the center. * The lookahead and the related local planning area is not dependant on the maximum velocity anymore. It is still dependent on the current linear velocity. * Added mutex locks to avoid deadlocks. This also fixed the problem with the getState() functions returning the right state of the path planning. * Added functionality to include ResistanceAreas and Lines in the map. These areas cause the path planning to cost more when traversing them. This allows the user to nudge the robot around areas without making the area forbidden. * The functionality that enables the robot to stop at a distance of goalOccupiedFailDistance from the goal if the goal is occupied works now correctly. * The global replanning path works better when the local path is blocked. * Fixed the problem with the local path spliced into the main path causing spikes in the path. Known Bugs: * The Python and Java wrappers can use an incorrect directory when loading parameters and map files: if it tries to use the ARIA installation directory (/usr/local/Aria on Linux, for example), as a work-around, you can set the ARIA environment variable to ARNL's installation directory (e.g. /usr/local/Arnl on Linux). Enhancements: * New networking features allow multiple robots to share position and path information: ArServerHandlerMultiRobot to communicate through a central server, or ArServerHandlerMultiRobotPeer for when a central server isn't being used... these allows multiple robots to avoid each other * Changed "ArServerHandleLocalization" to "ArServerHandlerLocalization" but made a typedef from the old name to the new (old name was a typo) * Made ArServerHandlerLocalization so that it would tell MobileSim to relocate the robot to the point of localization, you can turn this off with arguments in the constructor * Made new class ArSimMapSwitcher that will switch the map in the simulator to the map ARNL is using, this is in guiServer but commented out. * ARNL's guiServer is now using new ArSonarAutoDisabler from Aria so that when the robot's stopped it won't ping * Made Patrolbot's dock better (carried change over to Simulated docking too, it shouldn't affect pioneers or powerbots) * Made it so that if a robot was undocked and the charging bit went on it called the checkDock function on that dock to see if we're docked * From Aria - Modified ArConfig so that it can save unknown sections and parameters so that information isn't lost if nothing knows about it this run (To Arnl this means if you save Arnl.p from different programs you won't lose the settings in the sections you aren't using right now) * Modifed the ArServerHandlerLocalization so that it can take spread parameters so that people can have better control over localization ARNL 1.4.3 December 7, 2005 ------------------------ * Built shared libraries with -fPIC flag for greater compatability. ARNL 1.4.2 September 15, 2005 ------------------------ * Built with new ARIA library with minor fixes * Fixed theoretical deadlock in SONARNL ARNL 1.4.1 September 13, 2005 ------------------------- (SONARNL release only) * Fixed a crash that would sometimes happen in Windows ARNL 1.4.0 August 31, 2005 ------------------------- Fixes: * When there were both lines and points in the map, the occupancy grid was filled using either points or lines. The map memory was allocated and deleted with each set. Fixed this to allocate memory once and fill the occupancy grid with both points and lines. * When robot was completely blocked as when it is in a tight space, the fire() from ArPathPlanningTask was using the uninitialized searchFactor which sometimes was zero. This caused the local search rectangle to skirt too close to the robot. Fixed this by bounding the lower limit to 1.0; * Changed the path planning from and to positions to the work with the closest legal point on the grid. This helps in cases where the robot is too close to an obstacle and the actual pose is in an occupied cell. Now the to and from points are legalized to within a robot width. Important Changes: * Changed MinutesToChargeFor parameter in docking, 0 is now "don't finish based on time", -1 is now "undock as soon as docked" (this is so that the parameter matches VoltageToChargeTo) Enhancements: * Forbidden areas in maps may have a rotation (requires recent Mapper3 to generate, note that rotated forbidden areas will not be properly interpreted by older versions of ARNL) * Charging on robots that support it can now finish when its done and it drops into float mode, you'll need the most recent robot operating system for this to work * Lots of changes to docking to make it work more smoothly with regards to interrupted modes and modes that tried to activate * Changes to ArServerInfoLocalization so that MobileEyes can tell when the robot is lost (it will tell you the score and let you localize the robot) * SonARNL will now work correctly on a robot that could have two sonar rings but only has one (this is the change to ignore sonar readings in Aria) * SWIG wrappers for Python and Java are now included ARNL 1.3.3 May 31, 2005 ------------------------- Fixes: * Fixes STL crash on Windows in sonar localization * Fixes bug in path planning that produced erroneous movement in a rare condition * Uses either RotAcc and RotDec to determine change in velocity rather than both (path planning) * Fixes path planning code that was problematic for Powerbot, and similar. ARNL 1.3.2 May 23, 2005 -------------------------- Fixes: * Fixes annoying warning messages on Windows, and a potential mutex violation * guiServerSonar does not try to provide MobileEyes points with the map, just lines. ARNL 1.3.1 May 19, 2005 --------------------------- Enhancements: * SONARNL prevents ArServerModeStop from turning off the sonar * New ARIA library with bug fix. ARNL 1.3.0 May 16, 2005 --------------------------- Enhancements: * Sonar localization has been added. "ARNL" includes both localization methods. "SONARNL" is just sonar localization. * New path planning parameters added: GoalOccupiedFailDistance (Note: Previously reported for 1.2-0 accidentally) CurvatureSpeedFactor ARNL 1.2.0 March 29, 2005 --------------------------- Fixes and Critical Changes: * localizeRobotAtHome functions use ArConfig values as defaults rather than supplied parameters or constant defaults. Enhancements: * New localization parameters added: LaserIncrement, TriggerTimeFlag (and related parameters for periodic trigger), OccThreshold (replaces ObsThreshold) * New path planning parameters added: SlowSpeed, SideClearanceAtSlowSpeed, FastSpeed, SideClearanceAtFastSpeed, PlanEveryTime, RecoverOnFail, GoalSwitchTime, GoalTransAccel, GoalRotAccel, etc., HeadingRotSpeed, etc., UseEncoderFlag, * Can E-Stop when path planning, if a collision may happen sooner than the robot can slow normally. * Various other bug fixes, optimization, and dead code removal. Will especially drive smoother with larger robots (e.g. Powerbot) and at faster speeds, and approach goals with greater accuracy. * Path planner's state can be read by calling getState(), or get a text description from getStatusString(), or you can register a callback with addStateChangedCB(). * Net server supports Powerbot dock * Some shape drawing by net server fixed or changed * New data fields, "pathPlannerStatus" and "goalName" are published by ArServerModeGoto with a string identifying the current status and the name of the current or last goal ("Navigation" group). "getGoals" has a list of all goals ("Navigation Info" group). Important enhancements from Aria: * New classes in ArNetworking in ArServerFileUtils and ArClientFileUtils for transfering files over the ArNetworking connection, really only works in Linux (and is mostly for the new feature in Mapper3) * User and password information can now be required to connect with ArNetworking, see the ArNetworking overview in the documentation for more details (and examples/guiServer.userInfo); ARNL 1.1 August, 2004 --------------------------- ??? ARNL 1.0 February, 204 --------------------------- First public release!