An Octave port
Peter
Octave, and this is something I'm increasingly interested in.
With some structure general approach agreed I think the work could be
divided up across individuals: robotics, vision, mex, graphics etc.
If you have an interest in this please respond to this message in the
first instance and perhaps kick off a discussion about the feasibility
and issues.
peter.
JuanPi
> You received this message because you are subscribed to the Google Groups "Robotics & Machine Vision Toolboxes" group.
> To post to this group, send an email to robotics...@googlegroups.com.
> To unsubscribe from this group, send email to robotics-tool-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/robotics-tool-box?hl=en-GB.
>
>
Hi All,
I am interesting in porting the toolbox. I will be working on this
from mid January 2012.
Currently I am assessing what parts of the toolbox really need to be
ported. Quaternions seems to be quite well covered by Octave's
quaternoins_oo package
http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/extra/quaternion_oo/inst/,
we need to work on a wrapper to avoid editing the toolbox too much.
--
JuanPi Carbajal
-----
"Complex problems have simple, easy-to-understand wrong answers."
Murphy’s Law Book Two
-----
http://ailab.ifi.uzh.ch/carbajal/
Serge Stinckwich
be more octave-friendly and add the suitable abstract interface to
isolate some specific libraries access: graphics, quaternion, etc ...
> --
> You received this message because you are subscribed to the Google Groups "Robotics & Machine Vision Toolboxes" group.
> To post to this group, send an email to robotics...@googlegroups.com.
> To unsubscribe from this group, send email to robotics-tool-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/robotics-tool-box?hl=en-GB.
>
>
--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/
JuanPi
Well, Octave doesn't have classdef and the official APi only supports
> method(object, args)
However one can fake the API
> object.method(args)
using subsref as done here (with some minor drawbacks)
http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/main/geometry/inst/io/%40svg/subsref.m?revision=8974&view=markup
I propose the following way of proceeding.
1. A sort of backport version of V9 with the old API working... that
is method(obj,args) work for all functions needed.
2. Build subsref to make sure V9 in Octave behaves as V9 in Matlab, so
code is not broken.
There is a previous task
0. Split the package to use what already exists in Octave and generate
appropriated wrappers.
What do you think?
Note: there has been some activity in relation to developing classref
for Octave, but we are low of C++ devs and there is no estimated ETA.
For sure goes after 3.6, which will be ready at the end of December.
--
Serge Stinckwich
> Hi Serge,
>
> Well, Octave doesn't have classdef and the official APi only supports
>> method(object, args)
>
> However one can fake the API
>> object.method(args)
> using subsref as done here (with some minor drawbacks)
> http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/main/geometry/inst/io/%40svg/subsref.m?revision=8974&view=markup
>
> I propose the following way of proceeding.
> 1. A sort of backport version of V9 with the old API working... that
> is method(obj,args) work for all functions needed.
> 2. Build subsref to make sure V9 in Octave behaves as V9 in Matlab, so
> code is not broken.
>
> There is a previous task
> 0. Split the package to use what already exists in Octave and generate
> appropriated wrappers.
>
> What do you think?
>
> Note: there has been some activity in relation to developing classref
> for Octave, but we are low of C++ devs and there is no estimated ETA.
> For sure goes after 3.6, which will be ready at the end of December.
My knowledge of Octave or Matlab is quite limited, so i could not help
too much in that direction.
What is really important when you are doing such refactorings in large
base code is to have unit tests
(http://en.wikipedia.org/wiki/Unit_testing ) that cover the important
part of you code. Unit tests allow you to verify that the behavior of
your program is the same during the refactorings.
An other option for having support for multiple languages is to be
able to generate code from a high-level description of your problem,
written in a domain-specific language.
I have organized recently a workshop at last IROS about using
"domain-specific languages" for robotics:
http://doesnotunderstand.org/wikka.php?wakka=DSLRob11
But this is a more challenging task than just having a compatibility
layer between Matlab and Octave :-)
Best regards,
JuanPi
Ok, we will be in touch when we start the work.
I am developing a plugin for Octave for a package that is pretty much
oriented in that direction
https://code.cor-lab.org/projects/rsb
With this, for example, python and Octave can communicate without any barrier.
Anyway, that is definitely off topic.
Cheers,
JuanPi
The process for porting quaternion is set up.
If anybody is interested, the current Octave package under development is here
http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/extra/quaternion_oo/
(it is an update of the current quaternion package of Octave, which is
function oriented).
I explain the methodology for the port in this file
http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/extra/quaternion_oo/devel/RV9_Quaternions.txt?revision=8980&view=markup
Since there is time until I start working on it, feel free to comment.
Also notice that you can checkout the repository at any time.
JPi
Peter
over (my) summer, extending it to all functions in both toolboxes.
Peter
On Nov 4, 12:10 pm, Serge Stinckwich <serge.stinckw...@gmail.com>
wrote:
> > Hi Serge,
>
> > Well, Octave doesn't have classdef and the official APi only supports
> >> method(object, args)
>
> > However one can fake the API
> >> object.method(args)
> > using subsref as done here (with some minor drawbacks)
> > I propose the following way of proceeding.
> > 1. A sort of backport version of V9 with the old API working... that
> > is method(obj,args) work for all functions needed.
> > 2. Build subsref to make sure V9 in Octave behaves as V9 in Matlab, so
> > code is not broken.
>
> > There is a previous task
> > 0. Split the package to use what already exists in Octave and generate
> > appropriated wrappers.
>
> > What do you think?
>
> > Note: there has been some activity in relation to developing classref
> > for Octave, but we are low of C++ devs and there is no estimated ETA.
> > For sure goes after 3.6, which will be ready at the end of December.
>
> My knowledge of Octave or Matlab is quite limited, so i could not help
> too much in that direction.
> What is really important when you are doing such refactorings in large
> base code is to have unit tests
JuanPi
Octave includes the test for a function and the demos in the body of
the function
http://www.gnu.org/software/octave/doc/interpreter/Test-Functions.html#Test-Functions
http://www.gnu.org/software/octave/doc/interpreter/Demonstration-Functions.html#Demonstration-Functions
Is much less overhead than the Matlab style...IMHO
JPi
JuanPi
It will be pretty straight forward. At the beginning we may loose some
efficiency, but once we get it running we can improve it.
You can see the development of the wrapper here
http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/extra/robotics/inst/%40Quaternion/
@Peter: please let me know if you find any inadequacy in the copyright.
@Peter: ETA for classdef December 2012, development not start yet, though.
Peter
make the port really easy.
I'm still learning about Octave, but I think the best way to go is to
make each of the classdef files (Link, Quaternion, Vehicle etc) into
@class directories. Each file needs to be split up, each method in a
separate file, and a subsref file (I hate the whole idea of subsref
but will tolerate it for this purpose) created to allow class.method()
semantics. There will probably need to be some minor changes around
superclass constructor access.
In this way we could distribute the Octave version as a patch on the
main RTB. A script to remove the classdef files, and then unzip the
new @class directories.
We should aim to prove the principle with the classic RTB (Link,
SerialLink and Quaternion) then move on to the mobile robot
functions. JuanPi is doing Quaternion, any volunteers for Link or
SerialLink? I'm happy to serve as advisor so you're not completely on
your own.
peter
On Nov 8, 7:22 am, JuanPi <ajua...@gmail.com> wrote:
> I have started the port of Quaternions.
>
> It will be pretty straight forward. At the beginning we may loose some
> efficiency, but once we get it running we can improve it.
>
> @Peter: please let me know if you find any inadequacy in the copyright.
> @Peter: ETA for classdef December 2012, development not start yet, though.
>
>
>
>
>
>
>
>
>
> On Sat, Nov 5, 2011 at 10:54 AM, JuanPi <ajua...@gmail.com> wrote:
> > Hi Peter,
>
> > Octave includes the test for a function and the demos in the body of
> > the function
> >http://www.gnu.org/software/octave/doc/interpreter/Demonstration-Func...
> > Is much less overhead than the Matlab style...IMHO
>
> > JPi
>
JuanPi
Definitely the subsref solution (an official hack I must say, nobody
likes it) is something that allows us to port the Toolbox as it is.
Once we get a full package working we can see how to improve it.
I understand having classdef would be great, but you know how is the
community work... we live out of volunteers, we can't (and we
shouldn't) push anybody. I think December 2012 is a great ETA. :D
The @Quaternion class is a really easy job, just a wrapper. All
functions are implemented in the quaternion package of Octave (the
object oriented one, to be released soon. At the moment available only
through svn). Once again, the idea is to make things work first and
then improve what is needed. Benchmarking functions from the two
packages is something we can do to decide which one stays.
I fully support Peter's idea about the separation. Each class has to
get its own folder and the subsref hack.
I also like the idea that RTB can patch itself to be Octave
compatible, to make it self-contained. However, once the toolbox is in
the Octave-forge server, any octave user (with internet access) can
get it doing
> pkg -forge install robotics
If any dependency is missing the user will get an informative message
saying how to get the dependencies.
I do not know if its a good idea to have people packaging RTB to be
Octave compatible right from the start, basically I am concern about
manpower. I guess we could first get it to run as a Octave-forge
package and then expanding the current package to be able to transform
itself. However if there is enough manpower, we could go in parallel,
I am not against it.
As soon as the @Quaternion class is finished I will move to @Link
(unless there is another class required by @Link, Peter?).
Concerning Licencing. Any file that I create anew is under GLPv3, any
function that comes from the RTB will have Peters copyright under LGPL
and a line saying who port it to octave. Check how it was done with
matGeom (Octave package geometry
http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/main/geometry/).
Please let discuss this before we start working 100% on the port, if
there is something you are not happy about, please let me know.
JPi
> For more options, visit this group at http://groups.google.com/group/robotics-tool-box?hl=en-GB.
JuanPi
Function unitize unitize this quaternion
* function doesn't exists
Thanks
Peter Corke
On 13/11/2011, at 9:20 PM, JuanPi wrote:
> Correct help of Quaternion in RT v9
>
> Function unitize unitize this quaternion
>
> * function doesn't exists
the method is called unit(), error in the class help file noted.
Random question, does Octave support the creation of arrays/vectors of objects?
JuanPi
It doesn't seem to be the case. I will find out what can be done.
Peter Corke
On 13/11/2011, at 10:49 PM, JuanPi wrote:
> Good question!
>
> It doesn't seem to be the case. I will find out what can be done.
I use vectors of objects a lot in the vision toolbox.
In RTB the SerialLink object contains a vector of Link objects. We could use cell arrays, which is was the case for RTB < v9
peter
JuanPi
a(1) = Link(...
a(2) = Link(...
works in Octave, of course. Let me ask around for a while if there is
another solution.
JuanPi
Quaternions is being ported successfully. Some few more methods to go.
http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/extra/robotics/inst/%40Quaternion/
I noticed that there are some methods of Quaternion that are not in
the help of the class. If anyone can complete the list of methods in
that file I will be very grateful.
I noticed that raising a quaternion to a power is very slow in RTB and
works only for integers. Maybe somebody wants to implement the power
function from quaternions_oo in RTB. This implementation works for any
real exponent and gives the same result as the current implementation.
http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/extra/quaternion_oo/inst/%40quaternion/power.m?revision=9095&view=markup
Cheers
KaKiLa
this event cming
http://www.octave.org/wiki/index.php?title=OctConf_2012
It would be great to see of Robotics Toolbox developers there.
Cheers,
On Nov 14, 6:09 pm, JuanPi <ajua...@gmail.com> wrote:
> Hi all,
>
> Quaternions is being ported successfully. Some few more methods to go.http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/extra/robot...
>
> Details herehttp://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/extra/quate...
>
> I noticed that there are some methods of Quaternion that are not in
> the help of the class. If anyone can complete the list of methods in
> that file I will be very grateful.
>
> I noticed that raising a quaternion to a power is very slow in RTB and
> works only for integers. Maybe somebody wants to implement the power
> function from quaternions_oo in RTB. This implementation works for any
> real exponent and gives the same result as the current implementation.http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/extra/quate...
>
> Cheers
>
>
>
>
>
>
>
> On Mon, Nov 14, 2011 at 8:42 AM, JuanPi <ajua...@gmail.com> wrote:
> > a = cell();
>
> > a(1) = Link(...
> > a(2) = Link(...
>
> > works inOctave, of course. Let me ask around for a while if there is
> > another solution.
>
> > On Sun, Nov 13, 2011 at 10:21 PM, Peter Corke <peter.i.co...@gmail.com> wrote:
>
> >> On 13/11/2011, at 10:49 PM, JuanPi wrote:
>
> >>> Good question!
>
> >>> It doesn't seem to be the case. I will find out what can be done.
>
> >> I use vectors of objects a lot in the vision toolbox.
>
> >> In RTB the SerialLink object contains a vector of Link objects. We could use cell arrays, which is was the case for RTB < v9
>
> >> peter
>
> >>> On Sun, Nov 13, 2011 at 12:48 PM, Peter Corke <peter.i.co...@gmail.com> wrote:
>
> >>>> On 13/11/2011, at 9:20 PM, JuanPi wrote:
>
> >>>>> Correct help of Quaternion in RT v9
>
> >>>>> Function unitize unitize this quaternion
>
> >>>>> * function doesn't exists
>
> >>>> the method is called unit(), error in the class help file noted.
>
> >>>> Random question, doesOctavesupport the creation of arrays/vectors of objects?
>
> >>>>> Thanks
>
> >>>>> On Sat, Nov 12, 2011 at 5:08 PM, JuanPi <ajua...@gmail.com> wrote:
> >>>>>> Hi,
>
> >>>>>> Definitely the subsref solution (an official hack I must say, nobody
> >>>>>> likes it) is something that allows us to port the Toolbox as it is.
> >>>>>> Once we get a full package working we can see how to improve it.
>
> >>>>>> I understand having classdef would be great, but you know how is the
> >>>>>> community work... we live out of volunteers, we can't (and we
> >>>>>> shouldn't) push anybody. I think December 2012 is a great ETA. :D
>
> >>>>>> The @Quaternion class is a really easy job, just a wrapper. All
> >>>>>> functions are implemented in the quaternion package ofOctave(the
> >>>>>> object oriented one, to be released soon. At the moment available only
> >>>>>> through svn). Once again, the idea is to make things work first and
> >>>>>> then improve what is needed. Benchmarking functions from the two
> >>>>>> packages is something we can do to decide which one stays.
>
> >>>>>> I fully support Peter's idea about the separation. Each class has to
> >>>>>> get its own folder and the subsref hack.
>
> >>>>>> I also like the idea that RTB can patch itself to beOctave
> >>>>>> compatible, to make it self-contained. However, once the toolbox is in
> >>>>>> theOctave-forge server, anyoctaveuser (with internet access) can
> >>>>>> get it doing
>
> >>>>>>> pkg -forge install robotics
>
> >>>>>> If any dependency is missing the user will get an informative message
> >>>>>> saying how to get the dependencies.
>
> >>>>>> I do not know if its a good idea to have people packaging RTB to be
> >>>>>>Octavecompatible right from the start, basically I am concern about
> >>>>>> manpower. I guess we could first get it to run as aOctave-forge
> >>>>>> package and then expanding the current package to be able to transform
> >>>>>> itself. However if there is enough manpower, we could go in parallel,
> >>>>>> I am not against it.
>
> >>>>>> As soon as the @Quaternion class is finished I will move to @Link
> >>>>>> (unless there is another class required by @Link, Peter?).
>
> >>>>>> Concerning Licencing. Any file that I create anew is under GLPv3, any
> >>>>>> function that comes from the RTB will have Peters copyright under LGPL
> >>>>>> and a line saying who port it tooctave. Check how it was done with
> >>>>>> matGeom (Octavepackage geometry
> >>>>>>http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/main/geometry/).
> >>>>>> Please let discuss this before we start working 100% on the port, if
> >>>>>> there is something you are not happy about, please let me know.
>
> >>>>>> JPi
>
> >>>>>> On Fri, Nov 11, 2011 at 10:55 PM, Peter <peter.i.co...@gmail.com> wrote:
> >>>>>>> Hmm, Dec 2012 is a very long way away. And a pity, because it would
> >>>>>>> make the port really easy.
>
> >>>>>>> I'm still learning aboutOctave, but I think the best way to go is to
> >>>>>>> make each of the classdef files (Link, Quaternion, Vehicle etc) into
> >>>>>>> @class directories. Each file needs to be split up, each method in a
> >>>>>>> separate file, and a subsref file (I hate the whole idea of subsref
> >>>>>>> but will tolerate it for this purpose) created to allow class.method()
> >>>>>>> semantics. There will probably need to be some minor changes around
> >>>>>>> superclass constructor access.
>
> >>>>>>> In this way we could distribute theOctaveversion as a patch on the
> >>>>>>> main RTB. A script to remove the classdef files, and then unzip the
> >>>>>>> new @class directories.
>
> >>>>>>> We should aim to prove the principle with the classic RTB (Link,
> >>>>>>> SerialLink and Quaternion) then move on to the mobile robot
> >>>>>>> functions. JuanPi is doing Quaternion, any volunteers for Link or
> >>>>>>> SerialLink? I'm happy to serve as advisor so you're not completely on
> >>>>>>> your own.
>
> >>>>>>> peter
>
> >>>>>>> On Nov 8, 7:22 am, JuanPi <ajua...@gmail.com> wrote:
> >>>>>>>> I have started the port of Quaternions.
>
> >>>>>>>> It will be pretty straight forward. At the beginning we may loose some
> >>>>>>>> efficiency, but once we get it running we can improve it.
>
> >>>>>>>> You can see the development of the wrapper herehttp://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/extra/robot...
>
> >>>>>>>> @Peter: please let me know if you find any inadequacy in the copyright.
> >>>>>>>> @Peter: ETA for classdef December 2012, development not start yet, though.
>
> >>>>>>>> On Sat, Nov 5, 2011 at 10:54 AM, JuanPi <ajua...@gmail.com> wrote:
> >>>>>>>>> Hi Peter,
>
> >>>>>>>>>Octaveincludes the test for a function and the demos in the body of
> >>>>>>>>> the function
> >>>>>>>>>http://www.gnu.org/software/octave/doc/interpreter/Test-Functions.htm...
> >>>>>>>>>http://www.gnu.org/software/octave/doc/interpreter/Demonstration-Func...
>
> >>>>>>>>> Is much less overhead than the Matlab style...IMHO
>
> >>>>>>>>> JPi
>
> >>>>>>>>> On Sat, Nov 5, 2011 at 12:40 AM, Peter <peter.i.co...@gmail.com> wrote:
> >>>>>>>>>> I have a framework now for unit tests and a student to work on that
> >>>>>>>>>> over (my) summer, extending it to all functions in both toolboxes.
>
> >>>>>>>>>> Peter
>
> >>>>>>>>>> On Nov 4, 12:10 pm, Serge Stinckwich <serge.stinckw...@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>> On Fri, Nov 4, 2011 at 10:55 AM, JuanPi <ajua...@gmail.com> wrote:
> >>>>>>>>>>>> Hi Serge,
>
> >>>>>>>>>>>> Well,Octavedoesn't have classdef and the official APi only supports
> >>>>>>>>>>>>> method(object, args)
>
> >>>>>>>>>>>> However one can fake the API
> >>>>>>>>>>>>> object.method(args)
> >>>>>>>>>>>> using subsref as done here (with some minor drawbacks)
> >>>>>>>>>>>>http://octave.svn.sf.net/viewvc/octave/trunk/octave-forge/main/geomet...
>
> >>>>>>>>>>>> I propose the following way of proceeding.
> >>>>>>>>>>>> 1. A sort of backport version of V9 with the old API working... that
> >>>>>>>>>>>> is method(obj,args) work for all functions needed.
> >>>>>>>>>>>> 2. Build subsref to make sure V9 inOctavebehaves as V9 in Matlab, so
> >>>>>>>>>>>> code is not broken.
>
> >>>>>>>>>>>> There is a previous task
> >>>>>>>>>>>> 0. Split the package to use what already exists inOctaveand generate
> >>>>>>>>>>>> appropriated wrappers.
>
> >>>>>>>>>>>> What do you think?
>
> >>>>>>>>>>>> Note: there has been some activity in relation to developing classref
> >>>>>>>>>>>> forOctave, but we are low of C++ devs and there is no estimated ETA.
> >>>>>>>>>>>> For sure goes after 3.6, which will be ready at the end of December.
>
> >>>>>>>>>>> My knowledge ofOctaveor Matlab is quite limited, so i could not help
> >>>>>>>>>>> too much in that direction.
> >>>>>>>>>>> What is really important when you are doing such refactorings in large
> >>>>>>>>>>> base code is to have unit tests
> >>>>>>>>>>> (http://en.wikipedia.org/wiki/Unit_testing) that cover the important
> >>>>>>>>>>> part of you code. Unit tests allow you to verify that the behavior of
> >>>>>>>>>>> your program is the same during the refactorings.
>
> >>>>>>>>>>> An other option for having support for multiple languages is to be
> >>>>>>>>>>> able to generate code from a high-level description of your problem,
> >>>>>>>>>>> written in a domain-specific language.
> >>>>>>>>>>> I have organized recently a workshop at last IROS about using
> >>>>>>>>>>> "domain-specific languages" for robotics:http://doesnotunderstand.org/wikka.php?wakka=DSLRob11
> >>>>>>>>>>> But this is a more challenging task than just having a compatibility
> >>>>>>>>>>> layer between Matlab andOctave:-)
>
> >>>>>>>>>>> Best regards,
> >>>>>>>>>>> --
> >>>>>>>>>>> Serge Stinckwich
> >>>>>>>>>>> UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
> >>>>>>>>>>> Every DSL ends up being Smalltalkhttp://doesnotunderstand.org/
>
> >>>>>>>>>> --
> >>>>>>>>>> You received this message
>
> ...
>
> read more »
Peter
We are making progress here on the Octave port.
- Quaternion works, based on a fairly straightforward port of the RTB
Quaternion class to Octave format
- Link most works
which just leaves SerialLink, the plot method is likely to be the most
complex, but that's in our work plan for the next few weeks.
peter
> ...
>
> read more »
JuanPi
Those are great news!
It would be great o be kept updated, so we do not double the work.
Is that possible?
Thx
> --
> You received this message because you are subscribed to the Google Groups "Robotics & Machine Vision Toolboxes" group.
> To post to this group, send an email to robotics...@googlegroups.com.
> To unsubscribe from this group, send email to robotics-tool-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/robotics-tool-box?hl=en-GB.
>
--
JuanPi Carbajal
-----
For every complex problem there is an answer that is clear, simple, and
wrong.
-----
http://ailab.ifi.uzh.ch/carbajal/
JuanPi
if you check the svn that I sent you you will see that Quaternion
class is almost finished, also!
Are we collaborating? If so, then lets coordinate.
JuanPi
By decision of Peter the collaboration has been brought to stand-by.
It may happen that Peter decides to restart a collaboration with a
more polite and understanding position. That would be great, and I
will be available if that happens.
Nevertheless I will continue with the wrapper as planned and the
eventual port to Octave-Forge.
If you want to collaborate please do not hesitate to contact me.
PS: Do have in mind that Octave-Forge packages must be eligible as a
GNU project (i.e. Octave) therefore there are some standards that have
to be fulfilled.