98 replies to this topic

[stac]

Vassilis, on 22 January 2011 - 09:45 PM, said:

Builds fine on Ubuntu.

Are you done with the UAVObjectGenerator changes? I need to add code generation for PyMite and flight plan scripting.

I have no further pending changes.  oswnt will likely have more build changes to get this working properly on windows but I doubt there will be any significant changes needed in the uavobjgenerator itself.

[Vassilis]

peabody124, on 23 January 2011 - 01:04 AM, said:

There are two ways of using uavobjects from the plugin manager: 1) dynamically through calls to getField and such through the plugin manager 2) statically the way it's done on flight using ObjectNameSet(&object).  If we restrict ourselves to the former then we can actually allow updates to the uavobjects by distributing a new library.  This will also more cleanly separate the build process so they don't have a dependency.  If the uavobjectgenerator for gcs code also generates the .pro file then all will be hunky-dory.

We need to think about this a bit more. The reason of the dynamic calls is to be able to request field data without knowing the object in advance. Although this is not used now, I was envisioning a graphing plug-in that would simply enumerate through all the objects and list their fields the user could then select the field and plot it. If the object changes the plug-in does not need to know because it dynamically loads the objects and fields.

I really do not see any benefit moving the objects to a library.

[peabody124]

Vassilis, on 23 January 2011 - 03:07 AM, said:

We need to think about this a bit more. The reason of the dynamic calls is to be able to request field data without knowing the object in advance. Although this is not used now, I was envisioning a graphing plug-in that would simply enumerate through all the objects and list their fields the user could then select the field and plot it. If the object changes the plug-in does not need to know because it dynamically loads the objects and fields.

Actually they are used in a large fraction of the GCS code, even when the object type is known.  That's exactly how it's used, for example, in the scope plugin too.

Quote

I really do not see any benefit moving the objects to a library.

Well my main thought was the ease of writing a standalone program that can understand uavobjects without having to support the entire plugin architecture.  To me there is a clear dividing line between the uavobjects/talk api and the plugin that exposes them to the GCS - but currently that division is blurred in the code.

[cwabbott]

I just checked in an implemetation of the changes I described here. ground.pro should now be ok. Not optimal, but good enough to work. Feel free to change the SPEC variable I crudely made into the actual qmake variable telling you what mkspec it's currently using, if there is one.

BTW, I guess I'm part of this "Windows club"?

[Vassilis]

stac, on 23 January 2011 - 01:44 AM, said:

I have no further pending changes.  oswnt will likely have more build changes to get this working properly on windows but I doubt there will be any significant changes needed in the uavobjgenerator itself.

Great, I will get started on this tomorrow.

[osnwt]

I see two minor problems yet:

cwabbott, on 23 January 2011 - 04:06 AM, said:

I just checked in an implemetation of the changes I described here. ground.pro should now be ok. Not optimal, but good enough to work. Feel free to change the SPEC variable I crudely made into the actual qmake variable telling you what mkspec it's currently using, if there is one.

I don't like this way and prefer to use qmake variables. There is one named QMAKESPEC (variable reference), which should be defined in .pro files but in Qt-Creator 4.7.0 it is not defined. Maybe it is defined in 4.7.1 - can anybody check it? Just put the following command in uavobjects.pro and run qmake for it:

message($QMAKESPEC) 

(should be two ' signs here in a sequence)

If it is there for 4.7.1, then I guess we can use it in .pro and set it directly only if not defined.

Another problem is with those dir copy command which you use in openpilotgcs.pri:

win32:QMAKE_COPY_DIR = cp -r -f

It doesn't work for me (and I see at irc that for others as well).

This is not a windows shell command, it is from a third-party unix-like utilities like mingw etc. I do not have it in path, so clean build doesn't work. Or I have another one (from different unix-like tools) which gives me the following error (because my cp does not have required options):

Quote

Usage: cp [-hipnv] file1 file2
   cp [-hiprnv] file ... directory

So I guess that it's better to find exact cause of win-x64 xcopy failure and repair it using the solution found.

Quote

BTW, I guess I'm part of this "Windows club"?

We both are on Windows, but no, we are not. We weren't on board meeting at irc yesterday

[cwabbott]

osnwt, on 23 January 2011 - 07:29 AM, said:

I see two minor problems yet:



I don't like this way and prefer to use qmake variables. There is one named QMAKESPEC (variable reference), which should be defined in .pro files but in Qt-Creator 4.7.0 it is not defined. Maybe it is defined in 4.7.1 - can anybody check it? Just put the following command in uavobjects.pro and run qmake for it:

message($QMAKESPEC) 

(should be two ' signs here in a sequence)

If it is there for 4.7.1, then I guess we can use it in .pro and set it directly only if not defined.\

Thanks! How about checking if it exists, and if not using the old code?

osnwt, on 23 January 2011 - 07:29 AM, said:

Another problem is with those dir copy command which you use in openpilotgcs.pri:

win32:QMAKE_COPY_DIR = cp -r -f

It doesn't work for me (and I see at irc that for others as well).

This is not a windows shell command, it is from a third-party unix-like utilities like mingw etc. I do not have it in path, so clean build doesn't work. Or I have another one (from different unix-like tools) which gives me the following error (because my cp does not have required options):



So I guess that it's better to find exact cause of win-x64 xcopy failure and repair it using the solution found.


We both are on Windows, but no, we are not. We weren't on board meeting at irc yesterday

According to you here, the problem is with make's shell interpreter. When I run it within Microsoft's cmd.exe command line, it works fine. However, if I run it within a simple Makefile or within the msys command line, I get an error:

xcopy /s /q /y /i "C:/Users/Connor/Documents/OpenPilot/trunk/ground/openpilotgcs
/share/openpilotgcs/dials" "C:/Users/Connor/Documents/OpenPilot/trunk/build/grou
nd/openpilotgcs/share/openpilotgcs/dials"
Invalid number of parameters
make: *** [all] Error 4

I've tried getting rid of the quotes, changing the foward slashes to backslashes, and putting "/s /q /y /i" at the end, but nothing helps it.

[cwabbott]

osnwt, on 23 January 2011 - 07:29 AM, said:

I see two minor problems yet:



I don't like this way and prefer to use qmake variables. There is one named QMAKESPEC (variable reference), which should be defined in .pro files but in Qt-Creator 4.7.0 it is not defined. Maybe it is defined in 4.7.1 - can anybody check it? Just put the following command in uavobjects.pro and run qmake for it:

message($QMAKESPEC) 

(should be two ' signs here in a sequence)

If it is there for 4.7.1, then I guess we can use it in .pro and set it directly only if not defined.\

Thanks! How about checking if it exists, and if not using the old code?

osnwt, on 23 January 2011 - 07:29 AM, said:

Another problem is with those dir copy command which you use in openpilotgcs.pri:

win32:QMAKE_COPY_DIR = cp -r -f

It doesn't work for me (and I see at irc that for others as well).

This is not a windows shell command, it is from a third-party unix-like utilities like mingw etc. I do not have it in path, so clean build doesn't work. Or I have another one (from different unix-like tools) which gives me the following error (because my cp does not have required options):



So I guess that it's better to find exact cause of win-x64 xcopy failure and repair it using the solution found.


We both are on Windows, but no, we are not. We weren't on board meeting at irc yesterday

According to you here, the problem is with make's shell interpreter. When I run it within Microsoft's cmd.exe command line, it works fine. However, if I run it within a simple Makefile or within the msys command line, I get an error:

xcopy /s /q /y /i "C:/Users/Connor/Documents/OpenPilot/trunk/ground/openpilotgcs
/share/openpilotgcs/dials" "C:/Users/Connor/Documents/OpenPilot/trunk/build/grou
nd/openpilotgcs/share/openpilotgcs/dials"
Invalid number of parameters
make: *** [all] Error 4

I've tried getting rid of the quotes, changing the foward slashes to backslashes, and putting "/s /q /y /i" at the end, but nothing helps it.

[osnwt]

cwabbott, on 23 January 2011 - 03:36 PM, said:

Thanks! How about checking if it exists, and if not using the old code?

It is acceptable but on my system this qmake variable always is empty...
Can you put message in your .pro file and run qmake on it to see if it is defined? Which qt and qmake version do you have?

Quote

According to you here, the problem is with make's shell interpreter. When I run it within Microsoft's cmd.exe command line, it works fine. However, if I run it within a simple Makefile or within the msys command line, I get an error:

Honestly say, I don't remember which problem I had in September....

Let's continue with this problem in other topic...

[cwabbott]

osnwt, on 23 January 2011 - 03:58 PM, said:

Let's continue with this problem in other topic...

All right, I made a new discussion here.

[osnwt]

Please people let's agree about where to build flight targets, pleeeeaaase!

As orignally relocated by stac, it was in <top>/build/OpenPilot (as set in Makefiles).
People changed it to (more logical) <top>/build/flight/OpenPilot (to build from Eclipse).
Now (2557) it is changed back to <top>/build/OpenPilot (as top Makefile wants).

But please let us agree about it once and forever! Or every change will break build systems (as it is now).

My voice is for <top>/flight/OpenPilot, <top>/flight/AHRS, <top>/flight/Bootloaders/OpenPilot>, etc.

[peabody124]

I think (hope) you meant <top>/build/flight/

I liked the standard of no uppercase letters in the build paths myself.

Also if all things were equal I prefer not having the extra flight level - it's just less typing when I'm checking binary sizes.  Whatevs though *afraid of change*

[osnwt]

peabody124, on 24 January 2011 - 07:27 AM, said:

I think (hope) you meant <top>/build/flight/

Of course...

Quote

I liked the standard of no uppercase letters in the build paths myself.

And I like generic approach
That is, if we want all names in lower case - we should start it from source tree (where targets and directories are AHRS and OpenPilot now).
When I build all flight targets with a single Makefile.cmd (freebie for Windows users), I just run loop on targets (and varibale is used for directory, target and built binary). I can translate it to lower case on Windows, of course, using windows-only options, but I don't like the idea that the same target uses different names in different parts of tree. Do you?

Quote

Also if all things were equal I prefer not having the extra flight level - it's just less typing when I'm checking binary sizes.  Whatevs though *afraid of change*

The same is here: I am for generic approach and against of big mess where ground is on the same level as ahrs code. We have a lot of flight targets already, and moving them into flight subdir sounds reasonable for me and some Windows people (as soon as I realise since it was done not by me). Using Makefile, I see no difference as to check binary size in a level deeper, or better use 'size' target and tool from Makefile to print it after build automatically.

Said all above, I want to repeat that I agree for ANY result as soon as it is discussed, agreed and fixed once and for all.

[osnwt]

This generic approach also needs to be defined since there was a dicussion about names for firmware files and HITL/SITL firmware as well as for GCS names. The problem was that now we have OpenPilot for MB firmware AND for the SiTL simulation firmware. Makeing a Windows installer, I decided to separate things and call them as:

- OpenPilot - the installation folder for ALL OpenPilot projects software on PC (say about Windows now) - currently for GCS, but eventually for something else,
- OpenPilotGCS.exe - the name of GCS executable,
- OpenPilot_SiTL.exe (formwer OpenPilot_x86) - the name of SiTL firmware.

After some discussion with authors of parts we (more or less) agreed that we need uniform approach for all names. But that was all, and noting was finally fixed and documented.

This is a bit related to target names, paths, naming conventions with CAPITAL/small/MiXeDsTyLe/Un_der_sco_red names for paths and targets and for names like OpenPilotGCS/openpilotgcs/OpenPilot_GCS/etc.

[PT_Dreamer]

This last days have been difficult, it seems that we are laking a common goal. According to http://newwiki.openp...ct+Organisation the architecture design is James and Vassilis "responsibility", the only problem I see is that AFAIK neither one of them is using Windows. I would like to propose a virtual meeting on IRC (or Skype) between them two and me or/and Osnwt (both on Windows). where we can discuss changes and test them on the different systems as we go.

I'm available between 18H00 and 24H00 GMT

[peabody124]

I'm pretty much always on skype/irc so free to talk.  And this is more build architecture that actually software architecture, so I've redone the org chart to reflect the situation.

 Org Chart-updated.png   500.14K   47 downloads

What I would say is that ecclipse and the qt environment should try and follow the make files, not the other way around.  Stac's earliest point about the Makefiles, which I completely agree with, is that they create an easily reproduce result.  "make gcs; make openpilot" is pretty unambiguous.  IDE's tend to have lots of click options that can change things in different ways (i.e. release environment, target etc).  I believe it should be possible to make windows do this too using cs-make.

I also support the attempts to pull the bootloaders into that build environment.

[osnwt]

peabody124, on 24 January 2011 - 06:06 PM, said:

I'm pretty much always on skype/irc so free to talk.  And this is more build architecture that actually software architecture

Do we have anybody who is responsible for the build system? It is more to the question of target naming and locating.

Quote

What I would say is that ecclipse and the qt environment should try and follow the make files, not the other way around.

Just a note that Makefile can do everything, but IDEs - not always (the same as you just wrote). I was suprised how many team members are on Windows (I was sure that it is just me and 1-2 others). The stac agreed that having common ground will help Qt-Creator users (so we did that and I am happy with it - BTW, we just unable to get rid of this structure in Qt-Creator, so Makefile should be adapted for it first). But now the question is not about "how to make Eclipse users happy", but more about "how to name and locate build targets using unified approach". Someone likes common flight, and someone wants flight targets on the same level as ground. What we want is to agree upon this.

Quote

I believe it should be possible to make windows do this too using cs-make.

If you have a look at the top level Makefile.cmd (freebie for Windows users), it does almost exactly the same: builds all flight targets and bootloaders using few cs-make calls. And I am going to change the top Makefile adding there Windows targets to get rid of .cmd (and also add more targets as we discussed recently). But regardless of this we need:

1) to find (or assign ) a person in charge regarding target naming (AHRS - ahrs - AhRS, OPenPilot or openpilot_sitl/openpilotgcs);
2) to agree on build target locations (ground/* or *, flight/* or */, flight/bootloaders/* or *);
3) to document this;
4) and follow the document.

At the moment we can do everything (on the Makefile level), not so everything (within IDEs), but still no compromise.

PS. Not always Makefile can easily reproduce the results, as yesterday's irc talk showed. A lot of time was wasted just to understand that sometimes simple "cd and do" Makefile sequence on Windows remembers the directory after cd (invoking do), and sometimes - not (my and Pip's systems are on the same Windows XP 32bit, but we have different results). So it depends... And do we like Windows or not, but we have to take it into account too.

[cwabbott]

Nice chart peabody!

[glikar]

Beagle won't share his bone.    Having a problem compiling pyuavtalk on the BeagleBone.
Installed all required libraries, I think, and followed the Python Ground Tools wiki instructions.  Setup.py works, but at
"make uavobjects_pythonground"  I get this error:


root@beaglebone:~/OpenPilotPython# make uavobjects_pythonground
Could not find mkspecs for your QMAKESPEC(linux-g++) after trying:  
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/qt4/mkspecs
Error processing project file: /home/root/OpenPilotPython/ground/uavobjgenerator/uavobjgenerator.pro  

Installed "opkg install qt4-mkspecs", but still get the same error.  Googled all the relevant groups and found the same error:

"/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/qt4/mkspecs "  but no solution.

Reason I ask is that I read some where on this forum that there is interest  in using the BeagleBone.