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...
Real people. Real stories. See how Yahoo! Groups impacts members worldwide.

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
Messages 1 - 47 of 48   Newest  |  < Newer  |  Older >  |  Oldest
Messages: Show Message Summaries   (Group by Topic) Sort by Date v  
#46 From: "klfsfgetf" <klfsfgetf@...>
Date: Mon Jan 5, 2009 7:32 pm
Subject: I want to meet you. Give me a chance!
klfsfgetf
Offline Offline
Send Email Send Email
 
I want to meet you. Give me a chance! Click here to chat with me online:
http://bkidgy.zoomshare.com/files/chat.htm

#45 From: "girlbizblog" <girlbizblog@...>
Date: Sat Nov 8, 2008 9:07 am
Subject: I want to meet you. Give me a chance!
girlbizblog
Offline Offline
Send Email Send Email
 
I want to meet you. Give me a chance! Click here to chat with me online:
http://cliffordyhl.zoomshare.com/files/chat.htm

#39 From: "Vipul Patel" <pvr@...>
Date: Sun Apr 13, 2008 11:39 am
Subject: HI need LPC2210 instruction set details with time(CPU Cycle) and energy
vrp_822001
Offline Offline
Send Email Send Email
 
hi
    I need  documentation for LPC2210 ARM7TDMI-s Phillips instruction set
    details format.Which gives me details for cpu cycle and energy
consumption
    for each instruction.

    plz reply me as soon as possible.

#32 From: "benyehohanan" <d.b.jones@...>
Date: Tue Oct 9, 2007 5:04 am
Subject: OOMRM version 5.75 available
benyehohanan
Offline Offline
Send Email Send Email
 
* NEW: oC328 camera -- still has certain "features"...like it seems
to drop connection if you do not take a picture within about 15
seconds (need to reconnect).  Camera does not provide as fast a  frame
rate as I had hoped--about 4 frames a second using 2 bit color 60x80
mode--hoped to use also for line following but frame rate is a bit
low.  The new CMUcam3 is looking attractive ;)
   * Switched to Message Factory architecture for transmitting
messages.  Eliminates problems with non RTOS  transmission of
multi-packet messages.
   * Large rewrite in portions for certain requirements:
     - Only wanted to compile in what is used (reasonably).
     - Able to compile using uCOS/OS-II or choose not to use without
recompiling the library.
     - Able to use either bluetooth or straight serial RS232 for messaging.
     The first requirement stems from the fact that I found with the
previous node_manager, (true for most dynamic typing)
   it compiled in every class referenced.  I haven't tried RTTI, but
from an just glancing, it along  with virtual classes had same
problem.   After several repeated failures, I finally came up with
   a reasonable solution of encapsulating the class functionality in a
callback function now managed via  the Object_List.  This did not
require prior knowledge of classes.
     The second requirement stems from not wanting to be tied to
uC/OS-II in all my programs.  This was a bit trickier as some of the
core classes had embedded OS calls.  Created generic class for the
following:
    - OS (model/os) : represents a generic OS - user includes either
os/rros.h (round robin with interrupts) or os/ucosii.h
       The third requirement solution was to implement a a generic
CommunicationDevice which is similar to the OS subclasses as either
CommunicationDevice_RS232 or CommunicationDevice_Emic.

      The result is that, in theory, any communication device
(bluetooth or SCI) can be used with any (supported) OS any only those
   portions will be compiled into the resulting product for download.

PS: On a JAUS note, I am switching to a simpler message handling
architecture where a single default handler process all messages
rather than have to get the message to the right component.  Only
certain message require they be sent to a specific component.

#30 From: "benyehohanan" <d.b.jones@...>
Date: Sun Sep 16, 2007 4:09 am
Subject: Re: need simulator for FreeRTOS
benyehohanan
Offline Offline
Send Email Send Email
 
Were you looking for a robot simulation or just the FreeRTOS
emulation (simulation)?  If the latter, it looks like there is a x86
port  for x86 that can be used (see FreeRTOS FAQ for complete
instructions).
   To quote the FAQ:
"Will FreeRTOS run under Windows?
Yes! - the x86 port will run in a DOS emulation box [but you will not
get the correct real time response] and the ARM7 Keil port can be
completely simulated under windows. You can even step through the code
with both."

Derek
--- In oomrm@yahoogroups.com, "Vipul Patel" <vrp_822001@...> wrote:
>
> hi
>     I (Patel Vipul) am new member of this group. I hope moderator will
> not have a problem with that. I assure u that I never misuse
> membership and avoid any junk mail from myside.
>
>     I am student of Master Of Engineering (Comp. Eng.), I am working
> on project for SSL for FreeRTOS. I need simulator for FreeRTOS for
> this development.
>
>     If any body have any idea regarding simulator for FreeRTOS or have
> clue how to simulate FreeRTOS plz share it with me.
>

#29 From: "Vipul Patel" <vrp_822001@...>
Date: Fri Sep 14, 2007 5:57 am
Subject: need simulator for FreeRTOS
vrp_822001
Offline Offline
Send Email Send Email
 
hi
     I (Patel Vipul) am new member of this group. I hope moderator will
not have a problem with that. I assure u that I never misuse
membership and avoid any junk mail from myside.

     I am student of Master Of Engineering (Comp. Eng.), I am working
on project for SSL for FreeRTOS. I need simulator for FreeRTOS for
this development.

     If any body have any idea regarding simulator for FreeRTOS or have
clue how to simulate FreeRTOS plz share it with me.

#16 From: "benyehohanan" <d.b.jones@...>
Date: Thu Jul 27, 2006 4:27 am
Subject: OOMRM-II version 1.3 available
benyehohanan
Offline Offline
Send Email Send Email
 
Latest snapshot version 1.3.115 available which includes the following:
   * INWORK : primitive routine for localization; currently orientation
only and HOST only.
              [alpha test] : localizer class
   * FEATURE: Added oTTSemic class to control the Emic #36000 text to
speech unit. (currently no host emulation--just ignored).
   * BUG: Map width/height incorrectly updated.
   * FEATURE: Map width and Height can now be changed dynamically
without compiling (although best to restart simulator/robot after change).
   * BUG: IR indicators in the simulator were not showing.
   * BUG: Platform specs (wheelbase etc.) now stabilize to number
(before it could continuously decrease after restarting).
   * FEATURE: made most messages intranode capable making operation of
simulator idential to target.
              Can now upload/download etc. in simulator (of course only
useful for testing)
   * FEATURE: when in teleoperation robot now reports back its position
via simulant position (red).
   * FEATURE: Added robot diameter to platform parameters.  Robot
Diameter is
              often larger than wheelbase.  Needed for having A* paths
avoid hitting part of robot.
   * BUG: robot images did not display correctly if horizontal ruler in
use.
   * BUG: horizonatal ruler not right if part of map is not visible.
   * Added a special optimzed UART channel interrupt (channel 10) for
high speed (57K baud).
      -- eliminated all the clutter and options.
   * Bluetooth download/upload of map now works with optimzed UART.
   * Gameboy image tranfer now works in both Single snapshot mode and
as a service connection.
   * Added a translation "offset" to the DXF Import option to allow
objects to be added other than 0,0.

Have Fun,
Derek

#15 From: "benyehohanan" <d.b.jones@...>
Date: Fri Apr 28, 2006 5:40 am
Subject: OOMRM-II version 1.2 available
benyehohanan
Offline Offline
Send Email Send Email
 
I've put another snapshot on the web site.  Includes several
navigational bugfixes, and work on a faster more reliable bluetooth
link...

   * FEATURE: Switched to 57K baud Bluetooth communication required
some streamlining of SCI/UART interrupts and routines.  This is really
pushing the limit...with this and below change, am now about 4-5 times
faster than initial implementation which gives teleopoeration much
better control.
   * FEATURE: Chnaged to variable length "JAUS" messages.  Until I get
to real JAUS format and use of the prescence  vector... but for now,
the data_size field is updated on transmit from an internal table of
message sizes.
   * FEATURE: Added ability to define service connections, and changed
architecture to use these JAUS features for establishing heartbeats
rather than non-standard architecture; can also use for teleoperations
(command class; message=Set_Wrench_Effort_Message), and such...
   * FEATURE: Added "connect" button on simulator.  this more logically
divides when the simulator should be running from when the target
results should be displayed; otherwise, they both sometimes would compete.
   * FEATURE: added ability to send intranode messages for testing
component behavior.
   * FEATURE: Display of the A* Path and Path_Area (previous features)
now works again (and there was much rejoicing).
     NOTE: removed the A* toggle  as this will not be possible.
   * BUG: painting scene was broken.  did not reduce coordinates for
call to OGrid::wall etc.
   * BUG task_encodedmotor_driver general dead reckoning equation was
wrong!  I changed it previously incorrectly.
   NOTE: lots of errors were found in navigation--amazing it worked at all!
   * BUG: upgraded to version 1.3 of fixedpoint.c library
   * BUG: primitive_driver did not work without local vector driver.
   * FEATURE: Added teleoperation mode in both simulator and robot
(pretty cool).  See notes in documentation for details.
   * FEATURE: incorporated dialogue and teleoperation into simulator
window rather than seperate window--this fixed the focus problem, and
allows a more mouseless operation (I hate using mice).
   * FEATURE: Changed the transmit function to allow for intranode
communication without hopefully interfering with internode
communication.  This allows for the simulator to pass the psuedo JAUS
message between components which better tests the final
(inter)component  behavior in the simulator.

Derek

#13 From: "benyehohanan" <d.b.jones@...>
Date: Thu Feb 16, 2006 12:53 am
Subject: OOMRM-II version 1.1 available
benyehohanan
Offline Offline
Send Email Send Email
 
Here's the latest snapshot.  This revision mostly fixed inaccuracies
in navigational model to hopefully lead up to RSSC hall contest...
      [Simulator now is usually within a few millimeters of
waypoint--33% 0-2 millimeters.
       previously simulator could show up to a foot or so off for long
distances; i.e., it actually
       knew it was a foot away, but made no attempt to fix it (hmm).]
   * FEATURE: Changed wheelbase and wheel diameter to micrometers
internally.  This
       essentially allows for three decimal places of accuracy to fine
tune dead reckoning.   Only marginally
       useful now because of difficulty recalculating dead-reckoning
formulas with different wheel-base
       only approximates ratio for left; i.e., uses right wheel for
basic encoder unit.
   * NEW: Revamped the GUI coordinate system so that it now has a
"global" grid overlay.  part of new
         methodology to internally use millimeter destination in final
A* path.  This eliminates
         the A* path rounding error when going to the map tile center
rather than actual destination.
         - Can overlay global, local, or user grid in GUI for
coordinate referencing.
         - changed GUI rulers to display millimeters.
         - Changed mission_profile to store millimeters instead of map
units.
         - Dynamically calculated last angle in mission profile rather
than using stored angle
           this eliminates error associated with not being where your
supposed to be. (motion_driver.cpp [get_dest]).
   * FEATURE: Changed algorithm for when to stop in
local_vector_driver--much more accurate also.
   * BUG: traffic.cpp (test program) fixed.  WCInit moved up.
   * BUG: playback fixed and revamped.  Of course, only useful if using
bluetooth module though :)
   * BUG: froze/crashed if using local vector driver without motion
driver.
   * BUG: Import of DXF file where dimensions==GRIDX/GRIDY cause
message Exceeded, but still core dumps.
   * BUG: Import DXF, then save as.. scene file does not work.
   * BUG: Position of robot gets corrupted if obstacle.
   * NEW FEATURE: Quick Turn mechanism (F1) via use of local vector
driver without motion driver.
              Allows quickly just turning to a heading (angle) or just
traveling some distance forward from current position
              without knowing position on map (but still restricted to
staying within map (legal coordinates).
   * FEATURE: Added download of whether obstacles are present to
platform spec. download/upload.

Derek

#12 From: "benyehohanan" <d.b.jones@...>
Date: Wed Dec 21, 2005 12:59 am
Subject: OOMRM-II version 1.0 available
benyehohanan
Offline Offline
Send Email Send Email
 
Here's the latest mostly stable snapshot.  Still need to update  all
the documentation though:

OOMRM II Version 1.0 Changes (12/18/2005)
   RTOS code seems fairly stable with eb500 module communication.
Probably many
   Things I have forgotten, but among them are:
   * NEW: Added playback of communication log.  Haven't used in a
while, still needs a little work.
   * NEW: Added CPU Utilization host/target (host RTOS has bug (I
believe overflow); I believe
          this is a uC/OS-II problem; thus host always shows 100%
          unless on a very slow machine.
   * NEW: Added range sensor stimulation - allows simulation of waving
your hand in front
          of sensor.  triggers a sensor regardless of map content.
   * Major rewrite of navigational core to eliminate most (all?) floats.
     Probably not as accurate yet.  System needs to be fine tuned still.
   * BUGFIX: position gets corrupted if obstacle.
   * BUGFIX: Import DXF display is incorrect.
   * BUGFIX: The invariant systematic errors are not in shared memory!
   * FEATURE: The invariant systematic errors are not stored in the
configuration file and reloaded on start.
   * FEATURE: Position of invariant and simulant syncronize if you
restart from keypad.
   * BUGFIX: download grid image is looks misaligned to occupancy grid.
   * BUGFIX: Update of waypoint angle doesn't work.
   * BUGFIX: Map download not working.
   * BUGFIX: If the starting point = end point in A*, then it generates
a NO_PATH_FOUND error. (path < 2 I think).
   * BUGFIX: After one full cycle of square, robot swings 180 degrees.
  May have to be related to start==finish.
   * FEATURE: After chaning a waypoint, the waypoint is deselected.

Derek

#11 From: "benyehohanan" <d.b.jones@...>
Date: Sat Sep 24, 2005 1:33 am
Subject: Re: Neural Network Controller with a FPGA for Mobile Robot
benyehohanan
Offline Offline
Send Email Send Email
 
Sorry, not much experience here in either neural nets or FPGAs, but
I'm curious, is your focus on the robot controller side or on
implementing the FPGA neural network?  A mobile robot controller using
an FPGA seems intriquing--I assume you'd be using a behavior mobile
robot control architecture rather than a 3 layer approach or a
traditional sense-plan-act (SPA) architecture.

Derek

--- In oomrm@yahoogroups.com, "Gustavo Alejo Marteletti"
<gmartel@f...> wrote:
> Hi! I'm an Electronic Ingeneer student from the Universidad de
Buenos
> Aires, Argentina. I'm starting my thesis designing a Neural Network
> Controller with a FPGA for Mobile Robot. I want to know if anyone of
U 've
> experience with it so we can exchange info and papers.
> Keep working! "Hasta pronto"!!!
>
> Gustavo A. Marteletti

#10 From: "Gustavo Alejo Marteletti" <gmartel@...>
Date: Tue Sep 13, 2005 9:36 pm
Subject: Neural Network Controller with a FPGA for Mobile Robot
gmarteletti
Offline Offline
Send Email Send Email
 
Hi! I'm an Electronic Ingeneer student from the Universidad de Buenos
Aires, Argentina. I'm starting my thesis designing a Neural Network
Controller with a FPGA for Mobile Robot. I want to know if anyone of U 've
experience with it so we can exchange info and papers.
Keep working! "Hasta pronto"!!!

Gustavo A. Marteletti

#8 From: "benyehohanan" <d.b.jones@...>
Date: Fri Aug 19, 2005 1:32 am
Subject: OOMRM-II version 0.3.15 available
benyehohanan
Offline Offline
Send Email Send Email
 
I added another snapshot of the latest version
(http://mysite.verizon.net/resowiky/).  The RTOS portion
should be a lot more stable now.  Again look at sample program in test
directory for examples.  Other changes include:
   * main.cpp [added grid upload/download; old non RTOS routines don't
work.]
   * forgot constructor from oomrm.cpp
   * changed TCR1/PSK from 2us to 250ns for better performance on TPU
port.
   * changed oomrm.cpp constrctor to 25Mhz clock.
   * Added clock-like structure to simulator and added
hour/minute/second/millisecond display.
   * Bug fix in sci.cpp: RTOS signal length erroneously used the
rxbuff.in rather than rx_config.length.
   * adapting keypad/LCD to RTOS (available via PF3; see main.cpp
TaskDialogue for sample use)

Derek

Any problems, just let me know

#7 From: "benyehohanan" <d.b.jones@...>
Date: Wed May 4, 2005 5:26 am
Subject: OOMRM-II version 0.1 available
benyehohanan
Offline Offline
Send Email Send Email
 
This is sort of an alpha release of OOMRM-II. I took the library a
step back to incorporate a preemptive RTOS (uC/OS-II) into it's
desgin. As such, the model and simulator were heavily redesigned
leaving much of the old code untested.
   With that said, it is never the less interesting simply being able
to run uC/OS-II in a parallel simulator/embedded environment, and it
goes to demonstrate the advantages and disadvantages of using an RTOS
simulator along side an embedded environment.

Derek

PS: you need to already own uC/OS-II to use it though as its not
included in the download.

#6 From: "benyehohanan" <d.b.jones@...>
Date: Sat Mar 19, 2005 2:28 am
Subject: OOMRM and uC/OS-II
benyehohanan
Offline Offline
Send Email Send Email
 
As usual, there is good news and bad news.  The good news is OOMRM
is being redesigned to allow mobile robots based around a preemptive
OS--specifically, uC/OS-II.  The bad news includes:

  - It won't be completed for another month or so (time permitting)
  - Because of licensing issues, I can not include the source code to
the RTOS, but you can purchase it for $70 dollars along with Jean
Lebrosse's book MicroC/OS-II: The Real-Time Kernel.
  - It only has a Windows port at present.
   The new simulator is  almost completely being redesigned.  There
were two major restrictions driving the rewrite:
	 - The uC/OS-II simulator uses shared memory.
	 - In retrospect, since I'm allowing a preemptive OS, I added more
safeguards around global variables.  I found increasingly more use of
the Persistent class to store global values, and basically sliced out
a chuck of memory and created an API to allow ease of accesss to the
underlining global memory.  In critical tasks this has led to
functions sometimes grabbing the values when entering and storing them
when exiting rather than calling an API function for every global
access.



   My intention is to eventually refactor the oSchedule back into the
simulator for two purposes:
 	 - most importantly, educationally, it allows inspection of system
performance with and without a preemptive OS
	 - secondly, it allows the library to be used by those who do not have
uC/OS-II.

   Needless to say, I'm a bit disappointed over the licensing model of
requiring people to buy a $70 dollar book (that they don't want), just
to get the source code for educational, non commercial use when the
software indicates its free for educational use once you get it?  But
I guess its free in the sense of no yearly license fees as most major
RTOS have.


   I'm curious to hear feedback whether using uC/OS-II RTOS would be an
advantage or a disadvantage.

Derek

#5 From: "benyehohanan" <d.b.jones@...>
Date: Thu Nov 25, 2004 5:56 pm
Subject: OOMRM version 4.1 available
benyehohanan
Offline Offline
Send Email Send Email
 
This is mostly a bug fix release and completes a lot of the
communications functions in the workshop.  The persistent memory can
now be downloaded via the GUI; thus a keypad is no longer absolutely
necessary.  The major changes are:
   * If no Scene file is created and Autoload is set, then program
abends. [4.17]
   * Allowed map unit < 1 which will cause many problems. [4.17]
   * Finished communications download to workhop. Still needs cleanup
[4.16]
   * Finished communications upload from workshop [4.12-4.15]
   * Added subcommander to M4.
   * Fixed acknowledgements to Set methods caused a bogus set on
Querying host. [4.14]
   * when change units (inch) and save, it does not load correct
mm/division [4.12]
   * DASI: confused call to ntoh on message receive (jaus_message.cpp).
  needed two methods ntoh/hton. [4.11]
     Removed call to ntoh in each component [case where you put a bug
in to fix another bug!]
   * DASI: Believe I found bug in some message transmissions.  The
struct's in the jaus_message.h must be aligned on a 32 bit boundary or
they will be internally padded messing up the record structure.
[4.7-10]
   * removed patch for relative_object_position read (diagnostics.cpp)
struct as it is now fixed [4.7.10]
   * DASI: Added cb_upload_waypoint to upload all information on map
screen. [4.04-06]
   * converted most internal methods to use radians rather than degrees
(related to below). [4.02-06]
   * Testing over 200 feet course revealed the following problems:
(this will increase interrupt latency, but payback is high).
     1. changed _distance to float (was fixed) in Local_Pose_Sensor.
Fixed limited robot to max. travel of 32767 millimeters (just over 100
feet).
     2. changed _current_distance to float in Local_Vector_Driver.
Same limit as above (4.01)
     3. changed accumulated distance in oEncodedMotor from FIXED_TO_INT
to FIXED_TO_DOUBLE. after 100 feet of travel lost 2 feet. (4.02)
   * Added round funtion and rounded MAP_UNIT *10.0 in persistent.
Sometimes floats 152.4*10= 1523 because of trunc int and float
round-off error. (4.02)

#4 From: "benyehohanan" <d.b.jones@...>
Date: Sat Oct 16, 2004 12:54 am
Subject: OOMRM version 4.0 available
benyehohanan
Offline Offline
Send Email Send Email
 
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)

#3 From: "benyehohanan" <d.b.jones@...>
Date: Mon Jul 5, 2004 5:06 am
Subject: OOMRM version 3.8 available
benyehohanan
Offline Offline
Send Email Send Email
 
Below are the changes in this release:
   * added top level makeinclude.dos (Windows oly) to simplify
changing versions of FLTK (3.7.20)
   * added sonar_base supporting the oSonarDV in the simulator:
     for now, uses same methodology as an IR to detect obstacles will
refine later (3.7.20)
   * updated the oomrm_test to reflect the new environment. (3.7.19)
   * For some reason the scene editor is not recompiling.  Did I miss
this sometime?  To fix it, I rearranged the host
     directory and separated stuff into 2 libraries:
     - liboomrm
     - liboomrm_sim
     Still need to update the makefiles in the 'makefile' directory
and Linux makefiles. (3.7.19)
   * local_map_spec.cpp : intialized invariant whenever local map is
initialized. (3.7.18)
   * BUGFIX: ir_chain - reserve did not check for 0 next value
(3.7.17)
   * documentation fixes (3.7.14-3.7.16)
   * put error terms for simulator into the invariant class rather
than as defines (3.7.13)
   * BUGFIX: corrected seed for randomizer in invariant.cpp to get
new sequence each time (3.7.13)
   * Simulator "Next" shortcut now F8 (was 'n').
   * BUGFIX: fl_open - same problem with DXF import prevented from
opening a scene file. (3.7.12)
   * BUGFIX: fl_open - input box did not function (same problem as
DXF import). (3.7.12)
   * Moved Obstacle log to checkpoint upload function until I found a
better place.
   * BUGFIX: dxf_import - import->world/scene checkboxes were not
initialized to true correctly (3.7.11)
   * BUGFIX: dxf_import - input of filename was incorrect and caused
an abend. (3.7.11)
   * Converted documentation to HTMLDOC (3.7.10)
   * FLTK version must now be exported as environmental variable--
simplifies individual make files when changing (3.7.9)
   * added ability to hide simulator grid lines (3.7.8)
   * checkpoint, sim_map, ir_chain, m4: added ability take checkpoint
every n interrupts via frequency method (3.7.7)
     PS: turns out every n checkpoints because of interrupt internal
restrictions.
   * fl_ins.fl: moved Div from fl_simulator and renamed "Div."
to "Tile Size" (3.7.6)
   * BUGFIX: [sim_map.cpp] vertical scrollbar incorrect when changing
divisions (3.7.6)
   * sim_map.cpp: added real_time and step_through (3.7.5-3.7.7)
   * fl_simulator.fl: added group for time.  (3.7.5-3.7.6)
   * fl_simulator.fl: Renamed Error submenu to Model and added
Playback submenu. (3.7.4)
   * main.cpp: Vertical scrollback cleanup. (3.7.4)
   * output obstacle log following checkpoint log via oConsole.
(3.7.3)
   * added obstacle_chain to maintain static obstacle list (3.7.2)
   * changed pose_list to pose_chain for consistency (3.7.1)
   * added point_chain to main a list of obstacle coordinates. (3.7.1)

Derek

#2 From: "benyehohanan" <d.b.jones@...>
Date: Sat Jun 5, 2004 6:19 am
Subject: OOMRM version 3.7 available
benyehohanan
Offline Offline
Send Email Send Email
 
If you have any questions or suggestions for improvements, of
course, feel free to aks.  The biggest changes are as follows,

   * Added dxflib (http://dxflib.sourceforge.net/) for importing
autocad dxf files into the world grid.
   * eliminated Global_Map_Spec.
   * added extra byte to the OGrid (occupancy grid) structure (layer)-
-the semantics are still in work.
   * eliminated one level of the grid and setup the grid as a static
structure in the Mapping class--this
     should enable further streamlining as the grids are all
preallocated by the library now.
   * streamlined the opening of the scene grid into the robot or
world (simulator) grid and also the
     import of DXF into the robot or world grid.
   * added ability to store an occupancy grid into persistent memory
(battery backed RAM).  This requires setting
     aside of 41K of RAM unfortunately--possibly can be smaller, but
I do not want to change size every time
     grid size changes (and I haven't needed all that memory yet
believe it or not).
   * IR averages 32 readings instead of taking least value of 32
readings...has less dramatic swings
   * added log and checkpoint class/structure to enable dynamic
recording of obstacle discovery to
     allow the recreation of how a map was generated.

Derek

#1 From: "benyehohanan" <d.b.jones@...>
Date: Thu Apr 22, 2004 4:40 am
Subject: OOMRM version 3.6 available
benyehohanan
Offline Offline
Send Email Send Email
 
New 3.6.0 is now relased.    As usual, I probably changed too much
without thorough testing, but M3 (my robot) was able to sucessfully
run the A* course, so much seems to be still working.  The
dynamic mapping is still very BETA until I can get some localization
added.   See the draft OOMRM Library Users's Guide (OOMRM_UG.doc) in
the doc directory for more details.

Biggest changes include:
   * Added new OOMRM library User's guide.
   * Added mission_profile class : purpose is to contain information
on a particular mission (speed, waypoints, etc.)
   * WARNING: occupancy_grid.h size (GRIDX/GRIDY) is 35x440.
              This is for the RSSC contest which will run through a
7'x110' hall.
              change to whatever you wish, but just don't send the
robot off the world if doing A* navigation!
   * simulator refresh now automatic.  Seems to solve some problems
and creates other features.  Also
     Changed "speed" to "MS" on simulator and added "INC" combination
of milliseconds each callback and number of iterations
     done per callback allows a little more fine control of speed.
   * fixed vertical scrollbar bug in simulator. (4/15/04)
   * switched around some fixed/floats testing invariant accuracy.
interrupts back up to 25 ms.  (need more optimization).
   * Added color to simulator to display invariant (real) position of
robot in black;
     internal (normal) robot in red. (4/15/04)
   * Added another top layer (world) for doing error modeling--
invariant layer (See user guide).
   * added Windows Makefile part of portaudio to drive speaker.  Will
need to incorporate to Linux when I get there again.
       For simplicity all needed code is included in this library.  I
hate having to download a bunch of libraries! (4/8/04)
   * changed atomic_rotation to DEGREE (pose.h) and DEGREE to short
(was int).
   * made Geometry_Driver subclass Primitive_Driver; I did not add
all the constructors for all
     motor configurations.  You will have to copy constructors from
Primitive_Driver if you use other motor configurations!
     I'm not sure if this is the best way, but the hiearchy chart
sure looks prettier ;)
   * removed speed() methods from vector_driver and created set_speed
() method to set speed.
       This will probably be reworked in the future with some sort
of "mission_spec" class, but
       for now I only wanted one place where you set the speed (at
lowest level).
   * Somehow the symbolic links are no longer needed with all the
reorganization (finally).
   * changed Primitive_Driver to Geometry_Driver (Vector_Driver) as
this is more of the JAUS equivalent.
   * changed oMobileRobot to Primitive_Driver as this is more of the
JAUS equivalent.
   * major rewrite of oStatus: eliminated and replaced with "C"
functions--this allows use by interrupt handlers.
   * emulation oSCI and scihandler: above status+ this helped debug a
nasty trasmission problem.
   * sensor_base/IR_base: addition of a servo creates a scanner type
sensor mount.


Enjoy,
Derek

Messages 1 - 47 of 48   Newest  |  < Newer  |  Older >  |  Oldest
Advanced
Add to My Yahoo!      XML What's This?

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