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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi Guys,
After using a more up to date machine where I can install Ice 3.4 and Boost
I've come across more compile problems:

1. hydrolaserscanner2dhokuyoaist seems broken or is at least compiling when
it shouldn't:

*/home/uav/source/orca_new/src/hydrodrivers/hydrolaserscanner2dhokuyoaist/driver.cpp:34:
error: invalid use of incomplete type ‘struct hokuyo_aist::HokuyoLaser’
/home/uav/source/orca_new/src/hydrodrivers/hydrolaserscanner2dhokuyoaist/driver.h:18:
error: forward declaration of ‘struct hokuyo_aist::HokuyoLaser’*
...

and so on. I don't know much about the hokuyo software, can someone look
into this? I can turn it off this driver with ccmake without too much issue,
but orca won't compile normally if I don't.

2.
*make[2]: *** No rule to make target
`/home/uav/source/orca_new/src/interfaces/cpp/orcaifacemngr/slice2ifacemngr',
needed by `src/interfaces/cpp/orcaifacemngr/test.h'.  Stop.
make[1]: ***
[src/interfaces/cpp/orcaifacemngr/CMakeFiles/OrcaIfaceMngr.dir/all] Error 2*

This is happening with most of the orcaifaceXXX stuff in src/interfaces/cpp.
None of the .h files that are referenced exist in the named source
directories either, like something hasn't been checked in. Is that the
cause?

Michael

On 14 September 2010 18:53, Michael Warren <mic...@gm...> wrote:

> Hi Alex,
> Just started looking at the updated code to fix the imaging and running
> into a few compile problems.
>
> 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.
>
> 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?
>
> 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.
>
> Cheers,
> Michael
>
> On 8 September 2010 20:43, Alex Brooks <a.b...@ma...>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
>> > >
>> > > --
>> > > ------------------------------
>> > > 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
>> > > ------------------------------
>>
>> --
>> ------------------------------
>> 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
>> ------------------------------
>>
>
>
>
> --
> Michael Warren
> PhD Candidate
> Axon Building 47 - Room 311
> Department of Mechanical Engineering
> University of Queensland
> St Lucia, QLD, 4072
>

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