Search the web
Sign In
New User? Sign Up
oomrm · Object Oriented Mobile Robot Model (OOMRM)
? Already a member? Sign in to Yahoo!

Yahoo! Groups Tips

Did you know...
Message search is now enhanced, find messages faster. Take it for a spin.

Best of Y! Groups

   Check them out and nominate your group.
Having problems with message search? Fill out this form to ensure your group is one of the first to be migrated to the new message search system.

Messages

  Messages Help
Advanced
OOMRM version 4.0 available   Message List  
Reply | Forward Message #4 of 48 |

These are the major changes:
* major refactor...too much to specify. May break some old code
here or there.
The biggest addition, besides the Workshop (see below) which has
saved me lots of time is in using a configuration file in the
simulator. Most settings in the simulator are restored to the previous
setting when restarting. Also added a ruler to the map so you can
easily locate the precise location of the robot on a large map.
NOTE: not all the documentation has been updated yet.
WARNING: (known bug) If you don't have any configuration files
(oomrm.ini/RAM.ini) in the working directory, then the
simulator/workshop is likely to abend. Both the workshop and M4 come
with configuration files--these can be used as default.
* The newly added DASI library is a utility library for robot
communication and other algorithms. At this time, it is packaged
together with the OOMRM library but is licensed differently (Ref.
OOMRM License and DASI License).
* Created the "Mobile Robot Workshop" which now integrates the
simulator and scene editor into one app.
- the diagnostics tab is primarily for host<->robot communication
and is for easily inspecting onboard objects and returning sensor
values.
- the platform tab is designed to facilitate inspecting and
setting the persistent values both in Simulator and in Robot (via
communication library).
- the Map tab now has two major modes:
1) Scene editor: setting up map, initial robot location, and
waypoint values. This information can be used in the simulator or
downloaded into the robot.
2) Simulator: as before, for running the simulation.
All the communication modules are experimental and not fully
developed at this point.
* all makefiles are a bit more streamlined between Linux and
Windows.
NOTE: DXF stuff didn't compile when I last compiled on Linux about
9/20/2004
but I was using egcs GCC (read old) compiler and I think
lack of sstream support was the problem.
* bizarre workaround 1:
linking the simulator code into a seperate library liboomrm_sim.a
caused a segmentation fault when defining the window, but when linking
straight from the source directory it works fine--go figure!
* bizarre workaround 2:
- in persistent.cpp I declared a global "string configname;".
Also the use of string in ImportType for some bizarre reason caused
the application to crash when compiled into M4. I can find no
explanation and I checked it linking in electric fence to check
pointer problems and it reported none!?
* BUGFIX: platform specification battery overwriting array bounds.
(3.8.22)
* changed cEncoder to cSwitch for single channel encoders. the
oDI1_TPU is a typedef for oEncoder rendering it indistinguishable
typewise.
* Refactored command_driver, m4, mission_profile etc. for simpler
interface (3.8.14)
* Redid the DOS portions of oConsole and oSCI. oSCI now uses the
host serial port as does the oConsole. Thus many messages that
usually went to standard output will now go to the serial port--a
little bit of a pain, but more realistic for debugging JAUS
messaging. (3.8.12)
- Use DOS_DEBUG macro or printf etc. for host debugging now as
console messages will just go out PC serial port!
* added JAUS message tests in MOS. (3.8.11)
* added invariant stall and maximum_velocity parameters.
- I supposed could just manually adjust the other motor stall's
parameter, but this doesn't assume it will be correct and allows
simulation of the effect of one motor being closer to power source.
[getting a perfect battery for each motor would require you
adjust for power distribution etc.]. This allows you to deal with it
in your code, like you will need to in the real robot as the exact
factor may vary depending upon how charged the battery is etc. (3.8.9)
* makeinclude.dos now needs -lsupc++ (maybe -ljpeg) libraries for
(GCC > version 3.0 I believe).
* removed _P undef in oPID and changed internal variables as the new
gcc defined _P somewhere. (3.8.9d)
* converting from gcc 2.95.3 to GCC 3.3.1; requiring some clean up
of code.
Unfortunately, this sometimes requires changes to external
libraries--which is why I opt to include borrowed code rather than
externally because sometimes this code requires (although I suppose
they should be fed back to author). (3.8.9)
* added endian macros (htons,htonl, etc.) to account for little/big
endian-ness to switch to network order before transerring from PC
(3.8.8d)
CAUTION: the header jaus_message.h uses bit-fields that have been
tailored to either little or big endian--at least the way most
compilers handle it.
* removed Range_Sensor and just subclassed IR_base and sonar_base to
sensor_base directly.
* Refactored and expanded Configuration file code and consolidated
many booleans--I find
repeated testing of the same map, division setup tedious! this
hopefully helps (3.8.3)
* mapper.cpp, ir_chain, etc.: problem with emulation of multiple IRs
with mapper. Changed
IR emulation to serve rather than reserve. This restricts calls
to the value function to one per IR. Need better way of associating
IR under emulation with IR base. (3.8.2)






Sat Oct 16, 2004 12:54 am

benyehohanan
Offline Offline
Send Email Send Email

Forward
Message #4 of 48 |
Expand Messages Author Sort by Date

These are the major changes: * major refactor...too much to specify. May break some old code here or there. The biggest addition, besides the Workshop (see...
benyehohanan
Offline Send Email
Oct 16, 2004
12:54 am
Advanced

Copyright © 2009 Yahoo! Inc. All rights reserved.
Privacy Policy - Terms of Service - Guidelines - Help