Step 2: initenv:

New page

=Desctiption=
A walkthrough for microzed, OS = Kubuntu 14.04, gcc 4.8.4

=Steps=
==Step 0: toolchain==
1. Build and install toolchain with poky, instructions [[Yocto_tests#Build_toolchain_.28not_necessary_-_needed_only_for_building_ezynq_targets_outside_poky.29|here]].

==Step 1: get source==
git clone https://github.com/Xilinx/u-boot-xlnx.git
latest commit:
commit 40e8c28b90725f1e23e22c3b3514cf0b531f1bee
Author: Michal Simek <michal.simek@xilinx.com>
Date: Mon Jan 11 11:50:53 2016 +0100

==Step 2: initenv==
1. Create <b>initenv</b> in u-boot-xlnx:

initenv:
#!/bin/sh
export CROSS_COMPILE=arm-poky-linux-gnueabi-
export PATH=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/:$PATH

2. run:
. ./initenv

Note: if forgotten the error would be something like this:
lib/asm-offsets.c:1:0: error: bad value (armv5) for -march= switch
/*
^
make[1]: *** [lib/asm-offsets.s] Error 1
make: *** [prepare0] Error 2

==Step 3: config==
make zynq_microzed_defconfig
output:
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
#
# configuration written to .config
#

==Step 4: make==

make
output:
arm-poky-linux-gnueabi-ld.bfd: cannot find -lgcc
make[2]: *** [examples/standalone/hello_world] Error 1
make[1]: *** [examples/standalone] Error 2
make: *** [examples] Error 2

...
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=678e8798ebe0f4fd1bd347db136f1499b8fe00c9 Oleg

New page

=Desctiption=
A walkthrough for microzed, OS = Kubuntu 14.04, gcc 4.8.4

=Steps=
==Step 0: toolchain==
1. Build and install toolchain with poky, instructions [[Yocto_tests#Build_toolchain_.28not_necessary_-_needed_only_for_building_ezynq_targets_outside_poky.29|here]].

==Step 1: get source==
git clone https://github.com/Xilinx/u-boot-xlnx.git
latest commit:
commit 40e8c28b90725f1e23e22c3b3514cf0b531f1bee
Author: Michal Simek <michal.simek@xilinx.com>
Date: Mon Jan 11 11:50:53 2016 +0100

==Step 2: initenv==
1. Create <b>initenv</b> in u-boot-xlnx:

initenv:
#!/bin/sh
export CROSS_COMPILE=arm-poky-linux-gnueabi-
export PATH=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/:$PATH

2. run:
. ./initenv

==Step 3: config==
make zynq_microzed_defconfig
output:
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
#
# configuration written to .config
#

==Step 4: make==

make
output:
arm-poky-linux-gnueabi-ld.bfd: cannot find -lgcc
make[2]: *** [examples/standalone/hello_world] Error 1
make[1]: *** [examples/standalone] Error 2
make: *** [examples] Error 2

...
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=678e8798ebe0f4fd1bd347db136f1499b8fe00c9 Oleg

Desctiption:

New page

=Desctiption=
A walkthrough for microzed, OS = Kubuntu 14.04

=Steps=
==Step 0: toolchain==
1. Build and install toolchain with poky, instructions [[Yocto_tests#Build_toolchain_.28not_necessary_-_needed_only_for_building_ezynq_targets_outside_poky.29|here]].

==Step 1: get source==
git clone https://github.com/Xilinx/u-boot-xlnx.git
latest commit:
commit 40e8c28b90725f1e23e22c3b3514cf0b531f1bee
Author: Michal Simek <michal.simek@xilinx.com>
Date: Mon Jan 11 11:50:53 2016 +0100

==Step 2: initenv==
1. Create <b>initenv</b> in u-boot-xlnx:

initenv:
#!/bin/sh
export CROSS_COMPILE=arm-poky-linux-gnueabi-
export PATH=/opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/:$PATH

2. run:
. ./initenv

==Step 3: config==
make zynq_microzed_defconfig
output:
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/zconf.lex.c
SHIPPED scripts/kconfig/zconf.hash.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
#
# configuration written to .config
#

==Step 4: make==

make
output:
arm-poky-linux-gnueabi-ld.bfd: cannot find -lgcc
make[2]: *** [examples/standalone/hello_world] Error 1
make[1]: *** [examples/standalone] Error 2
make: *** [examples] Error 2

... Oleg

← Older revision Revision as of 18:51, 14 January 2016 (7 intermediate revisions not shown)Line 3: Line 3: ====="Free" the code part===== ====="Free" the code part=====  +<b>as of 2014/02/23...</b>  + Ezynq addresses the potential legal problems with distribution of a product/software based on Zynq platform: Ezynq addresses the potential legal problems with distribution of a product/software based on Zynq platform: * FSBL is under Xilinx's copyright * FSBL is under Xilinx's copyright * The current (2014/02/23) official SPL implementation in the [https://github.com/Xilinx/u-boot-xlnx/tree/master-next u-boot-xlnx master-next 54fee227ef141214141a226efd17ae0516deaf32] branch is FSBL-less but it requires to use the files (<b>ps7_init.c/h</b>) that come under Xilinx's copyright which makes u-boot noncompliant with its GPL license. * The current (2014/02/23) official SPL implementation in the [https://github.com/Xilinx/u-boot-xlnx/tree/master-next u-boot-xlnx master-next 54fee227ef141214141a226efd17ae0516deaf32] branch is FSBL-less but it requires to use the files (<b>ps7_init.c/h</b>) that come under Xilinx's copyright which makes u-boot noncompliant with its GPL license.  +  +<b>as of 2016/01/13...</b>  +* For a new board you still have to run an extra Xilinx program to generate ps7_init.c/h ==Supported boards== ==Supported boards== Line 45: Line 50: <font size='2'> <font size='2'>   sudo apt-get install texinfo chrpath   sudo apt-get install texinfo chrpath -  git clone -b dora git://git.yoctoproject.org/poky+  git clone -b jethro git://git.yoctoproject.org/poky   cd poky   cd poky   . ./oe-init-build-env   . ./oe-init-build-env Line 51: Line 56: </font> </font> -* Run installation script in ''build/tmp/deploy/''+* Run installation script in ''build/tmp/deploy/sdk'' -==Install Ezynq (Kubuntu 13.04)==+==Install Ezynq (Kubuntu 14.04)== <font size='2'> <font size='2'> -  git clone git://git.code.sf.net/p/elphel/ezynq ezynq+  git clone https://github.com/Elphel/ezynq.git   cd ezynq   cd ezynq   ./install_uboot.sh   ./install_uboot.sh </font> </font> -  ==Build== ==Build== Oleg

Install Ezynq (Kubuntu 13.04):

← Older revision Revision as of 02:54, 14 January 2016 (6 intermediate revisions not shown)Line 3: Line 3: ====="Free" the code part===== ====="Free" the code part=====  +<b>as of 2014/02/23...</b>  + Ezynq addresses the potential legal problems with distribution of a product/software based on Zynq platform: Ezynq addresses the potential legal problems with distribution of a product/software based on Zynq platform: * FSBL is under Xilinx's copyright * FSBL is under Xilinx's copyright * The current (2014/02/23) official SPL implementation in the [https://github.com/Xilinx/u-boot-xlnx/tree/master-next u-boot-xlnx master-next 54fee227ef141214141a226efd17ae0516deaf32] branch is FSBL-less but it requires to use the files (<b>ps7_init.c/h</b>) that come under Xilinx's copyright which makes u-boot noncompliant with its GPL license. * The current (2014/02/23) official SPL implementation in the [https://github.com/Xilinx/u-boot-xlnx/tree/master-next u-boot-xlnx master-next 54fee227ef141214141a226efd17ae0516deaf32] branch is FSBL-less but it requires to use the files (<b>ps7_init.c/h</b>) that come under Xilinx's copyright which makes u-boot noncompliant with its GPL license.  +  +<b>as of 2016/01/13...</b>  +  +under investigation ==Supported boards== ==Supported boards== Line 45: Line 51: <font size='2'> <font size='2'>   sudo apt-get install texinfo chrpath   sudo apt-get install texinfo chrpath -  git clone -b dora git://git.yoctoproject.org/poky+  git clone -b jethro git://git.yoctoproject.org/poky   cd poky   cd poky   . ./oe-init-build-env   . ./oe-init-build-env Line 51: Line 57: </font> </font> -* Run installation script in ''build/tmp/deploy/''+* Run installation script in ''build/tmp/deploy/sdk'' -==Install Ezynq (Kubuntu 13.04)==+==Install Ezynq (Kubuntu 14.04)== <font size='2'> <font size='2'> -  git clone git://git.code.sf.net/p/elphel/ezynq ezynq+  git clone https://github.com/Elphel/ezynq.git   cd ezynq   cd ezynq   ./install_uboot.sh   ./install_uboot.sh </font> </font> -  ==Build== ==Build== Oleg

← Older revision Revision as of 02:20, 14 January 2016 (2 intermediate revisions not shown)Line 3: Line 3: ====="Free" the code part===== ====="Free" the code part=====  +<b>as of 2014/02/23...</b>  + Ezynq addresses the potential legal problems with distribution of a product/software based on Zynq platform: Ezynq addresses the potential legal problems with distribution of a product/software based on Zynq platform: * FSBL is under Xilinx's copyright * FSBL is under Xilinx's copyright * The current (2014/02/23) official SPL implementation in the [https://github.com/Xilinx/u-boot-xlnx/tree/master-next u-boot-xlnx master-next 54fee227ef141214141a226efd17ae0516deaf32] branch is FSBL-less but it requires to use the files (<b>ps7_init.c/h</b>) that come under Xilinx's copyright which makes u-boot noncompliant with its GPL license. * The current (2014/02/23) official SPL implementation in the [https://github.com/Xilinx/u-boot-xlnx/tree/master-next u-boot-xlnx master-next 54fee227ef141214141a226efd17ae0516deaf32] branch is FSBL-less but it requires to use the files (<b>ps7_init.c/h</b>) that come under Xilinx's copyright which makes u-boot noncompliant with its GPL license.  +  +<b>as of 2015/01/13...</b>  +  +under investigation ==Supported boards== ==Supported boards== Oleg

← Older revision Revision as of 02:47, 8 January 2016 Line 1: Line 1: -[[Elphel_camera_parts]]+[[Elphel_camera_parts_0393|Elphel NC393 series camera parts]] == 0393-12 - front ends == == 0393-12 - front ends == === 0393-12-29 - Sensor front end, CS-mount === === 0393-12-29 - Sensor front end, CS-mount === Mikhail

0393-12 - front ends:

← Older revision Revision as of 02:41, 8 January 2016 Line 222: Line 222: ---- ---- ---- ---- -  -===  [[Elphel_camera_parts_0393-12 | 0393-12 - front ends ]] ===  -==== [[Elphel_camera_parts_0393-12#0393-12-29_-_Sensor_front_end.2C_CS-mount | 0393-12-29 - Sensor front end, CS-mount ]] ====  -==== [[Elphel_camera_parts_0393-12#0393-12-30_-_Sensor_adjustment_plate | 0393-12-30 - Sensor adjustment plate ]] ====  -==== [[Elphel_camera_parts_0393-12#0393-12-31_-_Disk_springs_support_pin | 0393-12-31 - Disk springs support pin ]] ====  -==== [[Elphel_camera_parts_0393-12#0393-12-43_-_SFE_M12_body | 0393-12-43 - SFE M12 body ]] ====  -==== [[Elphel_camera_parts_0393-12#0393-12-44_-_SFE_M12_adapter | 0393-12-44 - SFE M12 adapter ]] ====  ==  [[Elphel_camera_parts_0353-17 | 0353-17 - decals/overlays ]] ==   ==  [[Elphel_camera_parts_0353-17 | 0353-17 - decals/overlays ]] ==   Mikhail

0393-18-53 - GPS cap:

← Older revision Revision as of 02:35, 8 January 2016 Line 19: Line 19: === 0393-18-53 - GPS cap === === 0393-18-53 - GPS cap === {{Cad4a|0393-18-53}} {{Cad4a|0393-18-53}}  +----  +=== 0393-18-53 - Fisheye lens shade ===  +{{Cad4a|0393-18-54}} ---- ---- Mikhail

0353-70-52 - Lens, M12, Sunex DSL227A Fisheye 2.0 mm,:

← Older revision Revision as of 02:57, 30 December 2015 Line 129: Line 129: ---- ---- === 0353-70-52 - Lens, M12, Sunex DSL227A Fisheye 2.0 mm, === === 0353-70-52 - Lens, M12, Sunex DSL227A Fisheye 2.0 mm, ===  +{{Cad4a|0353-70-52}}  +---- === 0353-70-54 - Lens, Fisheye 2.3 mm, Vision Dimension BL02320MP12 === === 0353-70-54 - Lens, Fisheye 2.3 mm, Vision Dimension BL02320MP12 === Mikhail

MC393F21 camera:

← Older revision Revision as of 02:52, 30 December 2015 Line 14: Line 14: {{Cad4c_assembly|MC393F21}} {{Cad4c_assembly|MC393F21}} ---- ----  +=== NC393-4PI4 camera ===  +{{Cad4c_assembly|NC393-4PI4}}  +----  +=== NC393-4PI4-IMU-GPS camera with IMU and GPS modules ===  +{{Cad4c_assembly|NC393-4PI4-IMU-GPS}}  +----  + === EYESIS4PI-26 camera === === EYESIS4PI-26 camera === {{Cad4c_assembly|EYESIS4PI-26}} {{Cad4c_assembly|EYESIS4PI-26}} Mikhail

0353-19-91 - IMU Mount, Top:

← Older revision Revision as of 22:39, 29 December 2015 Line 640: Line 640: ---- ----  +=== 0353-19-91A - IMU Mount, Rev. A for fisheye camera  ===  +{{Cad4a|0353-19-91A}}  +----  + === 0353-19-92 - Spacer, IMU Mount === === 0353-19-92 - Spacer, IMU Mount === {{Cad4|0353-19-92}} {{Cad4|0353-19-92}} Mikhail

← Older revision Revision as of 22:35, 29 December 2015 Line 1: Line 1: -[[Elphel_camera_parts]]+[[Elphel_camera_parts_0393|Elphel NC393 series camera parts]] == 0393-18    - parts external other == == 0393-18    - parts external other == ---- ---- Mikhail

0393-19-100 - Antenna plate:

New page

[[Elphel_camera_parts_0393|Elphel NC393 series camera parts]]
=== 0393-19-100 - Antenna plate ===
{{Cad4a|0393-19-100}}
---- Mikhail

0393-18 - parts external other:

← Older revision Revision as of 22:29, 29 December 2015 Line 7: Line 7: === [[Elphel_camera_parts_0393-13 | 0393-13 - Camera back panels]] === === [[Elphel_camera_parts_0393-13 | 0393-13 - Camera back panels]] === === [[Elphel_camera_parts_0393-18 | 0393-18 - parts external other]] === === [[Elphel_camera_parts_0393-18 | 0393-18 - parts external other]] ===  +=== [[Elphel_camera_parts_0393-19 | 0393-19 - parts internal other]] ===  + === [[Elphel_camera_parts_0393-20 | 0393-20 - custom mounting parts]] === === [[Elphel_camera_parts_0393-20 | 0393-20 - custom mounting parts]] === === [[Elphel_camera_parts_0393-30 | 0393-30 - insulator tubing, spacers, tapes, pads]] === === [[Elphel_camera_parts_0393-30 | 0393-30 - insulator tubing, spacers, tapes, pads]] === Mikhail

0353-18-31 - tripod mount plate:

← Older revision Revision as of 22:27, 29 December 2015 Line 7: Line 7: === 0353-18-31 - tripod mount plate === === 0353-18-31 - tripod mount plate === {{Cad4a|0393-18-31}} {{Cad4a|0393-18-31}}  +----  +=== 0393-18-50 - IMU enclosure ===  +{{Cad4a|0393-18-50}}  +----  +=== 0393-18-51 - Camera top with GPS ===  +{{Cad4a|0393-18-51}}  +----  +=== 0393-18-52 - Camera top without GPS ===  +{{Cad4a|0393-18-52}}  +----  +=== 0393-18-53 - GPS cap ===  +{{Cad4a|0393-18-53}} ---- ---- Mikhail

0393-12-44 - SFE M12 adapter:

← Older revision Revision as of 22:24, 29 December 2015 Line 18: Line 18: === 0393-12-44 - SFE M12 adapter === === 0393-12-44 - SFE M12 adapter === {{Cad4a|0393-12-44}} {{Cad4a|0393-12-44}}  +----  +=== 0393-12-50 - Fisheye head adapter ===  +{{Cad4a|0393-12-50}}  +----  +=== 0393-12-51 - SFEs mount ===  +{{Cad4a|0393-12-51}} ---- ---- Mikhail

NC353L-PHG3 camera:

← Older revision Revision as of 20:17, 21 December 2015 Line 31: Line 31: === NC353L-PHG3 camera === === NC353L-PHG3 camera === {{Cad4c_assembly|NC353L-PHG3}} {{Cad4c_assembly|NC353L-PHG3}}  +----  +=== MNC354-2B camera ===  +{{Cad4c_assembly|MNC354-2B}} ---- ---- Mikhail

Converting mechanical assemblies to X3D models from STEP (ISO 10303) files

Like all manufacturing companies we use mechanical CAD program to design our products. We would love to use Free Software programs for that, but so far even FreeCAD has a warning on their download page “FreeCAD is under heavy development and might not be ready for production use”. We have to use proprietary tools, our choice was the program that natively runs on GNU/Linux we use on our computers. This program generates STEP files that we can send to virtually any machine shop (locally or overseas) and expect to receive the manufactured parts that match our design. For the last 6 years we kept the CAD models for all the camera parts on Elphel Wiki hoping they might be needed not only by the machine shops we order parts from, but also by our users to incorporate (or modify) our products in their systems.

All the mechanical CAD programs can export STEP, we can use this format for assemblies

The STEP file export is quite adequate for the production, but it would be convenient for our users (including ourselves) to be able to easily navigate through the complex assemblies. Theoretically STEP can handle assemblies too, but I’ve got an impression that the CAD program owners are not that interested in the interoperability – they want everybody to use their program, and the interoperability scope is limited to a simplified scheme: CAD(their) -> CAM(any) and the assembly structure is often lost when generating output files. When we tried to export Eyesis4π camera as a STEP file it got more than 0.5GB in size and when imported (even by the same program) it resulted in over 1800 solids without any hierarchy or even the part names. Additionally the colors were lost when the STEP file was imported back and it is understandable – CAD programs need to be able to produce STEP files (otherwise they would be completely useless), but importing requirements are more relaxed. Having no control over the proprietary program output we had to find a way to use the CAM files (in STEP format) in the other way than the CAD providers intended and recreate the assembly structure ourselves.

FreeCAD as the environment for model conversion

FreeCAD seemed to us as a best choice for the next step regardless to its “not ready for production” status as it has a great advantage of being FLOSS, and having excellent support for Python access to the functionality (through macros and a nice Python console). First I looked for a possibility to export data as X3D and was impressed that a FreeCAD macro that does that – export_x3d.py has less than 100 lines of code. It did not export colored faces of electronic components on the PCB, but that was something we could definitely fix ourselves.

Having working color output was a first step to a more ambitious project – feed the program with a library of STEP files of components and a flat STEP assembly file. The program should recognize each of the objects in the assembly by comparing it with the known parts, replace them with references to the library parts and provide translation and rotation. There are multiple ways how to deal with this task and I will describe what we did later in the post, in short – it just worked. We fed the program with a library of 800+ part files that we had (some custom, some just standard fasteners from McMaster), and the assembly file and it recognized almost all of the objects and correctly placed them, so Oleg Dzhimiev was able to start working on the viewer to navigate the models using the x3dom technology while I continued working on the converter.

Links to the converted models

Here is a link to Elphel Wiki page Elphel camera assemblies. Tis page opens multiple designs – they include the new NC393 camera models (for which we do not yet received all the mechanical parts) as well as our current products for which we already had the needed CAD files.

We had not tried to convert design data exported by other mechanical CAD software and it is interesting to know if this program can help users of other CAD systems. We tried to make it agnostic to the source of the STEP files, but it does require the possibility to export files with specified color of the faces (AP214 has this possibility while AP203 does not). Color information is anyway needed as a proxy for materials/finish to distinguish between different parts that have exactly the same geometry, we also use it to hint orientation of the parts in the assembly.

There are multiple ways how the program can be improved, but at least for our project it is already usable. And we hope it is not just for us.

Technical details

As soon as we verified that FreeCAD can import our STEP files and it is not that difficult to generate the X3D models we started freecad_x3d project at Github. The x3d_step_assy.py macro runs in FreeCAD and generates X3D files from the STEP input, the rest of the repository is the viewer for the produced models.

Indexing the STEP part files

The first thing the program does is it scans and indexes all the STEP models of the parts, saving the information that is needed for matching to the assembly objects. STEP opening in FreeCAD is a very slow process (especially in the GUI mode that is required to have access to the object color information), so this step is needed to significantly speed-up subsequent assembly files processing. The part invariant information such as center of gravity (center of volume to be precise) location, volume, surface area and gyration radii provided by FreeCAD. If the part has differently colored faces the centers for each color is recorded too. Additionally a list of up to 18 vertex coordinates is calculated and added – these vertices are tested to be inside (or near to) the objects in the assembly. Currently these vertices are selected as having maximal and minimal values for each of the 3 coordinates as well as their sums and differences.

Normally each part model consists of just one solid object, but in practice it is not always the case. The CAD program we use generates extra “tube” object for each thread, sometimes we do it intentionally like making a two-solid photographic UV protection filter as a frame and a glass. This allows us to selectively change solid/wireframe state when working in CAD program. Current implementation saves information about each solid in a part and places the largest (now by volume) solid first (at index 0), the matching uses only the first solid, and that leads to false-positive in reporting of the objects that do not have any matches to parts. “False” – because these unmatched objects will still appear in the X3D model as their are included in the individual part models. Removing such false positive objects from the report is definitely possible, but it was not a big hassle to manually inspect them in the FreeCAD 3D-view.

All this information is recorded in Python pickle format, one file for each STEP file. When program needs to process an assembly, it first verifies that each STEP part file has a corresponding pickle one an (re)calculates the ones that are either missing or outdated (older than the STEP model).

Generation of the X3D files for each part model

Next step after indexing of the STEP models of the parts is to generate individual parts in X3D format. Program uses the color information that exists after import in GUI mode for each object face and uses it in the generation of the X3D XML data. It wraps each object with X3D “Group” node to combine multiple possible objects in a part and to provide a bounding box information, and then adds the outmost “Transform” node with zero translation and rotation – it can be used for the viewer program to move rotate the object. Currently the viewer reads group bound box center and moves the top object in the opposite direction for convenient rotation. The imported STEP files may have large offsets of the models from the (0,0,0) point, if this is not corrected the viewer may try to rotate the object around the point that is far off-screen.

Similarly to the generation of the pickle files, program only generates part X3D models if they do not exist or are older then the input STEP files. We noticed that at this stage FreeCAD often segfaults (regardless of the version) and it seems to be related to the GUI. Luckily you only have to load this many files once, and if the FreeCAD crashes you may just restart it and the macro will continue generation of the new files.

Selection of the parts candidates for the assembly objects

Opening a complex assembly as STEP file in FreeCAD can take a while (one of our models was opening 40 minutes), so please be patient. The part matching take twice less time, so the program offers two options – use the currently active document in FreeCAD or start from the file path and open it.

When all the assembly data is available, the program indexes each object extracting parameters similar to those of the parts – volume, area, inertial properties, centers of each color (if present). Then it uses this data to create a list of parts-candidates for each assembly object, requiring that the orientation-invariant parameters of each object exported as a part of the assembly matches (to the configurable precision) that of the same part exported individually. If colors are available, the total area of each color is compared too, but match is allowed if only the shape is the same as CAD may allow to change the object color in the assembly making it different from that of the library part. If several parts match the assembly object then the better color match disqualifies other shape-only candidates, so it is possible to color-code the same-shape parts.

Matching of the assembly object to the part orientation

Next step of the assembly to parts decomposition is to determine the part position and orientation to match the assembly objects. In most cases there will be no more that one candidate for each object, but if there are several the program will try them all and use the first match. It is very easy to find the translation of the part – just use the vector between the already known centers of volumes, but it is more tricky to find the correct orientation. There are multiple ways how to match orientations, and the program can be definitely improved. We chose rather simple approach that requires modification of some parts, but is rather easy as the parts models are created by us. The number of parts that required modification is rather small, this modification has to be done once per part (not for each assembly) and the modification does not invalidate the model for CAM usage.

This approach uses the offsets of the “centers of gravity” of the faces of each color (even a single-colored object may have the center of all faces offset from the center of volume) and then the principal axes of gyration that are provided by FreeCAD. Color offsets are used first, then supplemented by the gyration axes, each step verifies that the vector is non-zero and the next one is not co-linear to the first. Only two orthogonal vectors are needed, the third one needed for rotational matrix is calculated as a cross product of the first two. Use of gyration axes even if all 3 have different gyration radii ad so are reliably calculated have ambiguity as they do not provide the sign, only the line of direction. The same asymmetrical object can be oriented in 4 different ways (alternating the sign of the two of the 3 axes) and the program tries each of them. Initially I tried to compare the volume of boolean intersection of the two objects that should be the same as the volume of a single object if they match, but for some of our STEP models FreeCAD refused to calculate intersection, so I used isinside() function instead that calculates if a given point is inside the object to the certain precision so can be used to verify that all of the set of vertices saved for the part object with the transformation matrix applied end up “inside” the assembly object (actually on the border). Unfortunately even that had exception – in one of the object one vertex was returning “False” with any tolerance, even larger that the object size. In that rare case the program tries to move the test point around by the same precision-long vector, and that modification worked, FreeCAD return “True” for the isinside() call.

When the color hints are required in the part models

Using just the gyration principal axes fails when the object has some symmetry (point or axis). Consider a regular socket head screw. Unless it is a really short one it will have one small and two equal large gyration radii, and the axis for the small gyration radius can be reliably found (it is just the regular axis of the screw) but the two perpendicular ones are arbitrary and may be different for the part and the assembly object. That will lead that the hex head will have incorrect orientation, but usually this hex hole orientation is unimportant. So here we slightly cheated – the test vertices selected for verification with isinside() are some of the outmost ones of the solid (we selected vertices that have maximal/minimal values of each of the coordinates and sums/differences of their pairs and all three) – the hex hole does not have any of them. Most of the fasteners we use are such socket head ones, this approach would not work for hex bolts and nuts – they need to have one of the hex faces colored.

And there are other objects that require some color hints in the part model, like a square plate having no or symmetrical holes, or a turned (round) part with the symmetrical holes in it – two of the gyration radii are the same and the corresponding axes can not be unambiguously determined. You may color one of the side faces of the square faces or color the inside of a hole to break a symmetry. If the part does not have individually selectable faces in the CAD program you may create a small colored cylinder or box, align it with one of the flat faces and boolean cut it from the object, and then boolean add it to it. The result object has the same shape for CAM, but it will have a colored square or circle on one of the faces – sufficient for unambiguous definition of the orientation.

← Older revision Revision as of 23:54, 19 December 2015 Line 12: Line 12: |- |- | | -<span class="plainlinks" title="View model in the Web X3D Viewer">[http://community.elphel.com/x3d/index.html?animate&model=/x3d/x3d_model_files/x3d/{{{1}}}-ASSY.x3d http://community.elphel.com/pictures/webx3dicon.png]</span>+<span class="plainlinks" title="View model in the Web X3D Viewer">[http://community.elphel.com/x3d2/index.html?animate&model=/x3d/x3d_model_files/x3d/{{{1}}}-ASSY.x3d http://community.elphel.com/pictures/webx3dicon.png]</span> | | |} |} Andrey.filippov