Re: [Orca-robotics-devel] image/camera stuff

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi Alex,
Thanks for clearing that up, much more robust (and obvious why things don't
compile) now. However, my issues from yesterday still stand: a lot of the
orcaiface libraries that seem like they are supposed to be compiled don't
exist in my checkout, and hence compilation fails. I've narrowed it down to
these:

lib/orcaifaceimpl
lib/orcaifacelogplay
lib/orcaifacelogrec
lib/orcaifacemngr
lib/orcaifacemngrutil
lib/orcaifaceprox

Which, because they don't exist, appear to manifest as failures when trying
to compile in the interfaces directories:

make[2]: *** No rule to make target
`/home/uav/source/orca_new/src/interfaces/cpp/orcaifaceimpl/slice2ifaceimpl',
needed by `src/interfaces/cpp/orcaifaceimpl/abstracttest.h'.  Stop.

Can you explain what's going on here? Have you implemented these yet or are
they not properly checked in? I cannot test what I have developed in
orcaimagelogfactory because it is dependent on some of these libraries.

Cheers,
Michael

On 15 September 2010 13:55, Alex Brooks <a.b...@ma...>wrote:

> Hi Michael,
>
> > 1. There appear to be dependencies on the header <Ice/Dispatcher.h>. This
> > appears to be a new facility in Ice 3.4, but I am stuck on 3.3 for my
> > version of Ubuntu (9.04). Is it possible to selectively build these
> > specific libraries dependent on Ice 3.4 being present, or is this now a
> > critical component of Orca requiring Ice 3.4 in order to build properly?
> > Given that the OrcaIce library depends on it, I'm guessing it's now a
> > critical dependency.
>
> Yes, it's now a critical dependency.  I've added a CMake check to enforce
> it.
>
> > 2. My version of cmake (2.6.4) complains about "FindFLEX.cmake" and
> > "FindBISON.cmake" being missing when trying to find them in the
> sliceparser
> > library so I will make finding them dependent on having a cmake version
> > greater than 2.6. Maybe the required minimum cmake version should be
> > increased to 2.8, which has these files?
>
> Yes, Orca now relies on v2.8.0 or greater.  I've added a CMake check to
> enforce this.
>
> > 3. I'm also attempting to fix some hardwired Boost typedef dependencies
> in
> > libs/orcasliceparser/definitions.h since my platforms don't use it:
> >
> > *typedef boost::shared_ptr<Definition> DefinitionPtr;*
> > *typedef std::vector<DefinitionPtr> DefinitionSeq;*
> > *
> > *
> > *A number of libraries use this header and hence are dependant on boost.
> > Compiling fails as a result without it.*
> >
> > Is it worth adding a few #defines based on the BOOST_FOUND variable to
> > remove the dependency on Boost in this header? Or should I bite the
> bullet
> > and accept that Orca from now on will require Boost? However, this
> doesn't
> > seem to fit with the high modularity that I would normally expect from
> > Orca.
>
> #defines won't help: the slice-parser doens't make these typedefs for fun,
> it
> uses boost smart pointers a lot.
>
> I think the best thing is to add Boost as a required dependency (I've
> committed this change).
>
>
> Alex
>
> > Cheers,
> > Michael
> >
> > On 8 September 2010 20:43, Alex Brooks <a.brooks@marathon-
> robotics.com>wrote:
> > > OK, patch comitted.
> > >
> > > For whoever can get the image stuff going again:
> > >  - The old library is still there: src/libs/orcalogfactory.  This
> > >  contains
> > >
> > > all the auto-generated logging/replaying stuff.
> > >
> > >  - There are a set of base-classes in src/libs/orcalog.
> > >  - The auto-generated implementations of certain of these base-classes
> > >  live
> > >
> > > in src/interfaces/cpp/orcaiface{log|rec}.
> > >
> > >  - There's a new library: src/libs/orcaimagelogfactory.  It contains
> two
> > >
> > > 'factory' classes: AutoLoggerFactory & ReplayerFactory.  These
> 'factory'
> > > classes each contain a vector of Interface{AutoLogger/Replayer}s --
> each
> > > of which knows how to produce a Logger/Replayer for a specific
> interface
> > > type.
> > >
> > >  - I also wrote a skeleton camera.h/cpp.  These need to be implemented
> > >
> > > properly as implementations of Interface{AutoLogger/Replayer} for the
> > > Camerra
> > > interface (and similarly for Image/MultiCamera).  My skeleton will work
> > > if the
> > > log-file contains links to image-files, but it might need to be
> modified
> > > more
> > > heavily if the format is substantially different (e.g. a .avi file).
> > >
> > > Does this make any sense?
> > >
> > >
> > > Alex
> > >
> > > On Wednesday 08 September 2010 20:04:00 Michael Warren wrote:
> > > > Hi Alex,
> > > > Given what you have explained I am happy for the patch to be
> submitted
> > > > to the trunk.
> > > >
> > > > Regards,
> > > > Michael
> > > >
> > > > On 7 September 2010 16:56, Alex Brooks <a.brooks@marathon-
> > >
> > > robotics.com>wrote:
> > > > > Hi Michael/David,
> > > > >
> > > > > OK, thanks.
> > > > >
> > > > > I've fixed up pretty much everything I want to now, so I'm ready to
> > > > > commit my
> > > > > patch and give instructions for what needs to be done.  It should
> be
> > > > > fairly simple I hope.
> > > > >
> > > > > I won't bother tagging it, if you want the version prior to my
> commit
> > >
> > > you
> > >
> > > > > should get revision 5759.
> > > > > (You can check it out with: svn co -r 5759 <other stuff>)
> > > > >
> > > > > Michael, are you happy for me to commit my patch now (since you can
> > > > > always get
> > > > > the version prior if you want) or is there some reason you'd prefer
> > >
> > > that
> > >
> > > > > I wait till after the 15th?
> > > > >
> > > > >
> > > > > Alex
> > > > >
> > > > > On Monday 06 September 2010 20:47:54 Michael Warren wrote:
> > > > > > Hi Alex,
> > > > > > We (Ben Upcroft, I and some masters students) are currently very
> > >
> > > active
> > >
> > > > > > users of the Orca image logging and playback abilities so would
> be
> > > > > > at
> > >
> > > a
> > >
> > > > > > disadvantage if you broke image logging/playing at the current
> > > > > > time.
> > > > > >
> > > > > > I am well tuned to the imaging parts of the logrecorder and
> > > > > > logplayer libraries (having written a lot of that capability for
> > > > > > the
> > >
> > > multicamera
> > >
> > > > > > interface) so should be able to help upgrade things once the
> > > > > > patches are applied. However, we are under the pump at the moment
> > > > > > to get results for ICRA, so would it be possible to delay this
> > > > > > until after the 15th of September? After this time I am more than
> > > > > > willing to help re-write these libraries. It might also be worth
> > > > > > making a tag of the current trunk
> > > > >
> > > > > before
> > > > >
> > > > > > any more changes?
> > > > > >
> > > > > > Regards,
> > > > > > Michael
> > > > > >
> > > > > > On 6 September 2010 20:33, David Lobato <dav...@gm...>
> > >
> > > wrote:
> > > > > > > Hi Alex,
> > > > > > >
> > > > > > > Right now, I'm sort of close to that "image side of things" so
> > >
> > > maybe
> > >
> > > > > > > I could help.
> > > > > > >
> > > > > > > Just to be sure, what you want is a library that can read/write
> a
> > > > >
> > > > > stream
> > > > >
> > > > > > > of images to/from a file, don't you?
> > > > > > >
> > > > > > > I guess you tell images should be logged as .pngs/.jpgs rather
> > > > > > > than inline because of the size. Maybe it's possible to use
> some
> > > > > > > kind of lossless compressor, so you could get rid of big data
> > > > > > > streams. This way it could be generic.
> > > > > > >
> > > > > > > If you can, send me more details about the task so I can figure
> > > > > > > out if I'm able to help.
> > > > > > >
> > > > > > > Have a nice day,
> > > > > > > David.
> > > > > > >
> > > > > > > -------------------------------------
> > > > > > > David Lobato Bravo
> > > > > > >
> > > > > > > Universidad Rey Juan Carlos
> > > > > > > c/Tulipan s/n
> > > > > > > 28933 Móstoles
> > > > > > > Madrid, Spain
> > > > > > > http://jderobot.org
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Sun, Sep 5, 2010 at 1:46 PM, Alex Brooks <
> > > > > > >
> > > > > > > a.b...@ma...> wrote:
> > > > > > >> Hey guys,
> > > > > > >>
> > > > > > >> I just checked in a big patch, there are a lot of changes.
> > > > > > >>
> > > > > > >> One of the bigger changes is a parser for slice files, which
> > >
> > > allows
> > >
> > > > > > >> replacement
> > > > > > >> of a lot of the hand-generated once-per-interface code with
> > > > > > >> auto-generated code -- much easier to maintain and to achieve
> > > > > > >> consistency between interfaces.
> > > > > > >>
> > > > > > >> I'm currently in the process of applying auto-generation to
> > > > >
> > > > > logging/log-
> > > > >
> > > > > > >> playing (I'm only up to log-playing at the moment).  It's a
> huge
> > > > > > >> improvement,
> > > > > > >> previously the amount of cut-and-paste was minimised by an
> ugly
> > >
> > > mess
> > >
> > > > > of
> > > > >
> > > > > > >> templates and inheritance, making the code nigh-unreadable.
> > > > > > >>
> > > > > > >> Unfortunately not everything can be auto-generated, there are
> > > > > > >> exceptions: specifically the image/camera gear, which needs
> > > > > > >> images logged as .pngs/.jpgs
> > > > > > >> rather than inline.
> > > > > > >>
> > > > > > >> Since I don't really understand this stuff or have cameras
> (not
> > > > > > >> to mention time) to test thoroughly, I'm gonna struggle to
> > > > > > >> maintain this.
> > > > > > >>
> > > > > > >> I have a bunch of code ready to check in which will break the
> > > > > > >> existing log-
> > > > > > >> playing stuff.
> > > > > > >> I think the cleanest way of handling things would be for
> > > > > > >> 'orcalogfactory' to
> > > > > > >> be an autogeneration-only library, and for custom stuff (i.e.
> > > > > > >> images)
> > > > >
> > > > > to
> > > > >
> > > > > > >> live
> > > > > > >> in its own separate library (orcaimagelogfactory?).
> > > > > > >>
> > > > > > >> Would someone be willing to help out, by writing this library
> > >
> > > after
> > >
> > > > > > >> I break
> > > > > > >> everything?  (Or if no-one is using this anyway, will anyone
> be
> > > > > > >> upset
> > > > >
> > > > > if
> > > > >
> > > > > > >> I break it?)  It should be pretty straightforward for someone
> > > > > > >> who
> > > > >
> > > > > knows
> > > > >
> > > > > > >> the image side of things.
> > > > > > >>
> > > > > > >>
> > > > > > >> Cheers,
> > > > > > >>
> > > > > > >> Alex
> > > > > > >>
> > > > > > >> --
> > > > > > >> ------------------------------
> > > > > > >> Dr Alex Brooks
> > > > > > >>
> > > > > > >> Marathon Robotics Pty Ltd
> > > > > > >> National Innovation Centre
> > > > > > >> 4 Cornwallis Street
> > > > > > >> Eveleigh, NSW 2015
> > > > > > >> Sydney, Australia
> > > > > > >> Ph: +61 2 9209 4021
> > > > > > >> Web: www.marathon-robotics.com
> > > > > > >> ------------------------------
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > > > > >> ------ This SF.net Dev2Dev email is sponsored by:
> > > > > > >>
> > > > > > >> Show off your parallel programming skills.
> > > > > > >> Enter the Intel(R) Threading Challenge 2010.
> > > > > > >> http://p.sf.net/sfu/intel-thread-sfd
> > > > > > >> _______________________________________________
> > > > > > >> Orca-robotics-devel mailing list
> > > > > > >> Orc...@li...
> > > > > > >>
> https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel
> > >
> > >
> -------------------------------------------------------------------------
> > >
> > > > > > > ----- This SF.net Dev2Dev email is sponsored by:
> > > > > > >
> > > > > > > Show off your parallel programming skills.
> > > > > > > Enter the Intel(R) Threading Challenge 2010.
> > > > > > > http://p.sf.net/sfu/intel-thread-sfd
> > > > > > > _______________________________________________
> > > > > > > Orca-robotics-devel mailing list
> > > > > > > Orc...@li...
> > > > > > >
> https://lists.sourceforge.net/lists/listinfo/orca-robotics-devel
> > > > >
>

-- 
Michael Warren
PhD Candidate
Axon Building 47 - Room 311
Department of Mechanical Engineering
University of Queensland
St Lucia, QLD, 4072