98 replies to this topic

[ligi]

As I am writing a java UAVTalk implementation so that my project DUBwise ( http://www.mikrokopt...wiki/en/DUBwise ) supports OP alongside the existing MK support - I am reviewing the  existing UAVTalk implementation.
The part which generates the gcs/flight/matlab/python code - and where I am adding java as output language - now got a restructuring with R2392 There where several problems I wanted to address:

- all languages to generate where processed everytime. In most runs only flight and/or gcs is needed but also matlab and python code was generated - now uavobjectgenerator has command line arguments to specify which languages to build and there are also new targets in the makefile.
- generation code for all languages was in the parser section - was bit of a mess in general - i untied it as best as i could
- its now more easy for new devs to add a new language or find relevant code for the language he is interested in

But there are other issues I want to discuss here first:

generated files to svn
Issue: should files that are auto-generated really be in the svn? This has some disadvantages like making it harder to see what really changed in diffs; possible unneeded merge work ; making it harder to find code to work on ; using up more space/bandwith than needed ( I'm living on umts only on the road atm. ,-)
Fix: remove them from svn and perhaps move them to build dir ( java gen is allready doing this ) - also it is more easy to clean them away that way

python working / maintaining
Issue: the part of generating python code looks like started but not finished and never used
Fix: move away for the moment until someone uses it

position in svn
Issue: the uavobjects generator is in ground/src/libs/uavobjgenerator/, but generates flight code too and is not really a lib
Fix:  create shared folder in root and place it there shared/src/uavobjgenerator

non working tests
Issue: the tests in ground/src/plugins/uavobjects/tests are broken
Fix: rewrite or move away for the moment

Issue: ground/src/plugins/uavobjects/ is a mess - containing templates / generated python/cpp/matlab code
Fix: cleanup / introduce new folders

unit "na" v.s. ""
Issue: there are different styles for marking a field as not used
./ahrsstatus.xml:     <field name="SerialNumber" units="n/a" type="uint8" elements="8"/>
./firmwareiap.xml:    <field name="crc" units="na" type="uint32" elements="1"/>
./gpstime.xml:        <field name="Day" units="" type="int8" elements="1"/>
Fix:
we should make one a default - I vote for "" - UI can translate it to n/a if wanted

[peabody124]

I don't see a downside to not keeping the autogen code outside svn - I agree it simplifies things

I'm pretty sure vasillis is using the python for pymite though so don't break that.

Also second the "" standard.

[osnwt]

peabody124, on 13 January 2011 - 03:18 AM, said:

I don't see a downside to not keeping the autogen code outside svn

Shouldn't trunk\ground\src\plugins\uavobjects\* be also removed except templates?

[peabody124]

I would think so - that's not what I meant about leaving the python generation alone earlier.

[ligi]

osnwt, on 15 January 2011 - 05:34 PM, said:

Shouldn't trunk\ground\src\plugins\uavobjects\* be also removed except templates?

I'm not sure with all files - especially the python stuff - e.g. there is a file uavobject.py which is not generated and not a template file ..

peabody124, on 15 January 2011 - 11:07 PM, said:

I would think so - that's not what I meant about leaving the python generation alone earlier.

i have not removed generation stuff - just generated files

[osnwt]

ligi, on 15 January 2011 - 11:31 PM, said:

I'm not sure with all files - especially the python stuff - e.g. there is a file uavobject.py which is not generated and not a template file ..

I am about most of .cpp files - they are also autogenerated, but still versioned. Maybe someone who knows for sure can remove them as well.

[ligi]

osnwt, on 15 January 2011 - 11:52 PM, said:

I am about most of .cpp files - they are also autogenerated, but still versioned. Maybe someone who knows for sure can remove them as well.

there was imho only one autogenerated cpp file left there which is now also gone - the rest there is not autogenerated

[Edouard]

One thing: if we remove all the autogenerated files, then someone compiling from SVN and wanting to slightly change one little bit of code will end up with random object IDs which will be totally different from everyone else's. Basically, this will tightly bind compiled versions of the GCS and flight code to each other and will make every GCS instance incompatible with flight code not compiled at the same time, we have to pay attention to this...

Once our UAVObjects become more stable, we should definitely keep this autogenerated code, if you ask me... After v1.0, the decision should probably be taken to freeze the uavobjects and only introduce new objects at each further official release, right ?

[Edouard]

OOps, looks like I caught this one a bit too late...

Unless I am mistaken, this now means that we cannot share compiled firmwares anymore, unless I am mistaken? This is quite a bit of a problem, if you ask me !

[ligi]

The object ids are hashed from xml content so this shouldn't be a issue

[Edouard]

ligi, on 16 January 2011 - 06:42 AM, said:

The object ids are hashed from xml content so this shouldn't be a issue

  Good point. Sorry for the early morning stress Should the .cpp files be kept (or rather deleted) too, then ?

[ligi]

It was no early morning stress, was late here in NZ ,-)
What cpp files do you mean?

[Vassilis]

Any idea why the modifications I made on Rev 2276 are missing (i.e. the number of bytes per object is no longer reported). Is there anything else missing? Have not looked at it in detail but I just want to make sure that we did not loose functionality in the recent changes.

[ligi]

I had to merge the numBytes stuff with my changes and imho we have not lost functionality, but I can double check this when I am back in the van where my notebook ist. I only have my phone with me today and cannot check with that.

[stac]

ligi, are you interested in a patch set that moves all (flight + gcs) uavobject files outside of the source tree into a common build directory?

I've implemented and tested this for a command-line build on a Linux system (invoking the top-level Makefile).  I can build OP and AHRS firmware as well as the gcs.

I've asked Sambas to test the flight-related part of the patch for me on his eclipse setup but I would need someone to test out a build of the GCS in QT Creator and adapt the patch as necessary.

Moving the uavobject .py files is next on my list.

[ligi]

@stac: great, but I also only use make on a linux cli, so I cannot really test the QT Creator stuff

[stac]

Patch set (against r2463) to move all synthetic/generated UAVObject out of the source tree and into the "build" directory.

I've tested building the OP and AHRS firmware, GCS, and all uavobject output using the top-level Makefile on Linux.

The UAVObject synthetic files are placed in <top>/build/uavobject-synthetics/{flight,gcs,python,matlab}/*.

I haven't moved the java objects over yet since I don't have any way of testing that I haven't broken your application.

Feedback welcome.  If any of you want to integrate this into the QT Creator and Eclipse IDE environments, that would be great.

My git tree has an extra 'trunk' directory at the top so you'll probably have to use:

  patch -p2 < thepatchfile.patch

to apply the patches properly against your svn tree.

NOTE: There are a number of delete operations in this patch set so make sure you don't have any local pending changes in your tree before applying it.

Attached Files

•  uavobj-move-patches.tar   90K   26 downloads

[peabody124]

Vassilis, on 16 January 2011 - 11:05 PM, said:

Any idea why the modifications I made on Rev 2276 are missing (i.e. the number of bytes per object is no longer reported). Is there anything else missing? Have not looked at it in detail but I just want to make sure that we did not loose functionality in the recent changes.

Second wanting this back and displayed when generating objects - it's useful for ram limited devices to know how much each object costs.

[ligi]

Reporting is back. Default only with sum of all objects and with verbose flag ( or make uavobjects_test respectively) for each object.

[ligi]

@stac: just tested your patchset and they work fine here too ( but we have a simmilar setup including usage of git). Only the output of "make uavobjects" looks a bit weird now because the generator is restarted for all languages.