Question related to Drake-ros's #142 - I am unable to pull in the rviz_2d_overlay_plugins in drake_ros_viz via the bazel WORKSPACE mech. I have tried both focal and jammy rolling/humble distributions. I see the following error -
ERROR: no such package '#ros2//': Failed to setup #ros2 repository: './run.bash /home/arrowhead/.cache/bazel/_bazel_arrowhead/90cc0dfb7c9efd65bbcc1ee9dd934f8e/external/bazel_ros2_rules/ros2/scrape_distribution.py -i geometry_msgs -i rclcpp -i rclpy -i tf2_ros -i tf2_ros_py -i visualization_msgs -i rviz_2d_overlay_plugins -o distro_metadata.json' exited with 1
--- captured stderr ---
Traceback (most recent call last):
File "/home/arrowhead/.cache/bazel/_bazel_arrowhead/90cc0dfb7c9efd65bbcc1ee9dd934f8e/external/bazel_ros2_rules/ros2/scrape_distribution.py", line 54, in <module>
main()
File "/home/arrowhead/.cache/bazel/_bazel_arrowhead/90cc0dfb7c9efd65bbcc1ee9dd934f8e/external/bazel_ros2_rules/ros2/scrape_distribution.py", line 46, in main
distro = scrape_distribution(
File "/home/arrowhead/.cache/bazel/_bazel_arrowhead/90cc0dfb7c9efd65bbcc1ee9dd934f8e/external/ros2/resources/ros2bzl/scraping/__init__.py", line 90, in scrape_distribution
packages, dependency_graph = build_dependency_graph(
File "/home/arrowhead/.cache/bazel/_bazel_arrowhead/90cc0dfb7c9efd65bbcc1ee9dd934f8e/external/ros2/resources/ros2bzl/scraping/__init__.py", line 50, in build_dependency_graph
raise RuntimeError(msg)
RuntimeError: Cannont find package 'rviz_2d_overlay_plugins'
I see the package on ROS Index here and my relevant WORKSPACE Bazel bit is given below.
ros2_archive(
name = "ros2",
include_packages = [
"geometry_msgs",
"rclcpp",
"rclpy",
"tf2_ros",
"tf2_ros_py",
"visualization_msgs",
"rviz_2d_overlay_plugins"
],
sha256_url = "https://build.ros2.org/view/Hci/job/Hci__nightly-cyclonedds_ubuntu_jammy_amd64/lastSuccessfulBuild/artifact/ros2-humble-linux-jammy-amd64-ci-CHECKSUM", # noqa
strip_prefix = "ros2-linux",
url = "https://build.ros2.org/view/Hci/job/Hci__nightly-cyclonedds_ubuntu_jammy_amd64/lastSuccessfulBuild/artifact/ros2-humble-linux-jammy-amd64-ci.tar.bz2", # noqa
)
Primary Suggestion: You may want to consider installing ROS Humble directly onto your Jammy OS, and then use ros2_local_repository rather than ros2_archive:
https://github.com/RobotLocomotion/drake-ros/blob/06dc6aa7d0237f4edb74130bcce8e9e78689d50c/bazel_ros2_rules/ros2/defs.bzl#L221-L239
Then you should be able to use a locally installed ROS 2 version, and install the package you want, either to /opt/ros or in a workspace that you're chaining.
FTR, in Anzu at TRI, we use ros2_archive presently for the following reasons (some of which are my opinions):
We wanted to use ROS 2 Humble on Focal, possibly mixing multiple different versions along different checkouts.
I want things to update only when I (we) precisely want. (For high confidence reproducibility, also to denoise apt upgrade)
For reproduciblity, I want us to maintain the ability to have decent reproducibility without aggressive containerization.
This means you should consolidate your development solely onto Jammy.
If you are already containerizing, then that should hopefully not be too large of a jump.
Alternative: If you really want to maintain archives, is to build your own extension archive including the packages you want. Here's an example kinda-hack that I had shimmed into Anzu:
https://github.com/EricCousineau-TRI/repro/tree/4079be209bfbc282d4580b5b2979faa148e1f394/ros/drake_ros_example_layered_archive
Related
I am new to EDK2.
For porting ekd2 firmware to a new ARM64 platform, it would be good to first get a minimum edk2 port which can run UEFI Shell at least, improvements can be added gradually based on that.
It seems that the first step is rather steep, e.g., how to determine a minimal set of "items" in .dsc and .fdf file for a platform? In my case, I would like to build the .fd for my platform and treat it as BL33 of TF-A, effectively I would like to build an edk2 firmware to replace u-boot.
It seems that such a guide is hard to find on the web. I found a old version of edk2 which contains some instructions, but apparently they are obsolete (not exist in latest master branch, while can be found in UDK branches such as UDK2014), and I am not sure why those documents are removed from master branch.
Currently I can build .fd for FVP (edk2-platforms/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc), and it seems that the build output FVP_AARCH64_EFI.fd is supposed to be treated as BL33. Theoretically this could be a prototype for my new ARM64 platform, but to me it's too complex to start with: the firmware is about 2.5MiB in size (as compare to 500K of u-boot), so I guess it's far from a "minimum" version. but it's hard to figure out what features to be removed (and how).
I am wondering if there is a detailed guide on such topic...
After 1 month of trial and error, today I managed to bring my ARM64 platform into a UEFI Shell environment. I treat it as my 1st milestone on the EDK2 journey. Below I will try to summarize the steps I took so far, as a tentative answer to my question above. Guidance/corrections/comments are welcomed.
Get familiar with UEFI/PI spec and EDK2 implementation by reading books/specs/articles. Well, UEFI/PI specs are thousands of pages long...how to start? My main reading list is:
"Beyond Bios--Developing with the Unified Extensible Firmware Interface", 3rd ed, by Vincent Zimmer, et al. As the authors explained, the book is a kind of high level summary of the thousands-paged specs. And I find that the book is well organized for a new comer to get familiar with various UEFI related concepts. The main purpose of the 1st read (before playing with edk2 code base) is to get familiar with concepts and architectural ideas, not the details yet. Related sections need to be consulted later when reading EDK2 implementations.
EDK2 specs, including:
EDKII User Manual
EDKII Build Specification
EDKII DSC/FDF/DEC/INF File Specification
Various articles on the web...
Get a reference platform which can correctly boot a FD image built from latest EDK2 source, and play with the boot manager and Shell environment a bit. In my case, I chose RPi4B. For me, this is very important, as the reference platform serves as a handrail during the whole process, that whenever I encounter bugs or have doubts, I check the source/log of the reference platform. This solves most of the problems I encountered. Btw, always generating "build log" and "build report" for both reference platform and the target platform, as the two files contains very detailed information for comparison and check. Consult the EDK2 build spec on how to generate these two files during build.
I use the following script to build for RPi4B platform:
#!/bin/bash
# https://github.com/tianocore/edk2-platforms#how-to-build-linux-environment
export WORKSPACE=/home/bruin/work/tianocore
export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
pushd $WORKSPACE
rm -rf ./Build/RPi4
source edk2/edksetup.sh
echo "Building BaseTools..."
make -C edk2/BaseTools all
#sudo apt install acpica-tools # iasl
# pip install antlr4-python3-runtime # -Y EXECUTION_ORDER
echo "Building firmware for Pi4B..."
GCC5_AARCH64_PREFIX=aarch64-none-linux-gnu- build \
-n 4 \
-a AARCH64 \
-p Platform/RaspberryPi/RPi4/RPi4.dsc \
-t GCC5 \
-b NOOPT \
-v -d 9 -j RPi4-build.log \
-y RPi4-build-report.txt \
-Y PCD \
-Y LIBRARY \
-Y DEPEX \
-Y HASH \
-Y BUILD_FLAGS \
-Y FLASH \
-Y FIXED_ADDRESS \
-Y EXECUTION_ORDER \
all
How to use the build result RPI_EFI.fd on RPi4B, consult the following:
edk2-platforms/Platform/RaspberryPi/RPi4/Readme.md
readme.md inside https://github.com/pftf/RPi4/releases/download/v1.17/RPi4_UEFI_Firmware_v1.32.zip. btw, I need to replace the original start4.elf and fixup4.dat with the ones in the zip file, otherwise, the boot of RPi4 will fail, complaining something like below:
RpiFirmwareGetClockRate: Get Clock Rate return: ClockRate=0 ClockId=C
ASSERT [ArasanMMCHost] /home/bruin/work/tianocore/edk2-platforms/Platform/RaspberryPi/
Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c(263): BaseFrequency != 0
It's worth to analysis the RPI_EFI.fd content to some extend, by using some UEFI utilities. I mainly use the GUI version UEFITool of sudo apt install uefitool uefitool-cli. Other tools are also available. The anotomy of RPI_EFI.fd is of help when reading EDK2 build specs for checking understanding of the concepts.
One special aspect of RPI_EFI.fd is that the 1st 128K is bl31.bin binary from ATF. I guess this is due to the special booting connfiguration methods for RPi. For my platform, I don't need such kind of packaging, I only need to build the UEFI image MY.fd, which is treated as BL33 image and packaged into fip.bin togehter with BL2 and BL31 images by ATF build script.
Another aspect to notice is the "reset vector" in the begining of the .fd file. This related to the entry point of UEFI image (and entry point of each EDK2 modules), as well as interpreting the BL instruction for AArch64. Basically, it can be summarized as below:
The first [Components] in RPI_EFI.fd is ArmPlatformPkg/PrePi/PeiUniCore.inf, which is of MODULE_TYPE = SEC.
What's this component: this is the first (and only) SEC (Security) module in RPi4. What the name PrePi and Pei implies?
... the PI spec is not tied to edk2 PEIMs, and I don't see where EDKII PEI modules are currently the only "acknowledged" silicon init environment. The edk2 tree itself seems to contain platforms that don't use the edk2 PEI module set at all, but (IIRC) jump from SEC to DXE. I believe "ArmPlatformPkg/PrePi" and "ArmVirtPkg/PrePi" are related to this.
--- https://listman.redhat.com/archives/edk2-devel-archive/2020-November/msg00021.html
Its entry point: all UEFI components have the same entry point (_ModuleEntryPoint).
By "component", it means either a UEFI driver and UEFI app, both are PE32 executables, usually with suffix .efi.
The .efis are converted from ELF executables (.dll) by GenFw tool: modifying the file headers.
To verify that "all components' entry point is _ModuleEntryPoint":
Check the .dll generating command line in build report (build -y <BUILD_REPORT_FILE>), we have two flags "aarch64-none-linux-gnu-gcc" -o xxx.dll -u _ModuleEntryPoint -Wl,-e,_ModuleEntryPoint ...:
-u: gcc --help -v|grep "undefined SYMBOL" gives -u SYMBOL --undefined SYMBOL: star with undefined reference to SYMBOL.
Wl,-e: ld --help|grep "entry" gives -e ADDRESS, --entry ADDRESS Set start address.
Check all .dll files that Entry point address == _ModuleEntryPoint: find . -type f -name "*.dll" -exec sh -c "readelf -a {} |grep -E 'Entry point address|_ModuleEntryPoint'" \;
Its entry point is the entry point of whole UEFI FD image (i.e., from bl33_base_addr jump to this _ModuleEntryPoint):
Topology of the UEFI Firmware File
A UEFI Firmware File (actually a UEFI Firmware Device - FD file) is a collection of UEFI binaries encapsulated into a single image. The format of this image is defined by the Platform Initialization Specification Volume 3. A Vector Table is located at the base of this file. A 'BL' branch instruction at the base of the firwmare (location of the Reset Entry into the Vector Table) will jump to the first 'SEC' module of the UEFI Firmware Image.
--- https://github.com/lzeng14/tianocore/wiki/ArmPkg-Debugging
To verify the statements above:
Disassember the reset vector (i.e., the 1st word) of generated .FD (we got offset=0x360):
$ xxd -l 4 -e TEST.fd <== dump 4 bytes in little endian
00000000: 140000d8 <== BL {PC}+(0xd8<<2); offset=0x360
Check the Entry point in .dll (we got offset=0x240):
$ aarch64-none-elf-objdump -t ArmPlatformPrePiUniCore.dll|grep _ModuleEntryPoint
0000000000000240 g F .text 0000000000000000 _ModuleEntryPoint
$ readelf -h ArmPlatformPrePiUniCore.dll|grep Entry
Entry point address: 0x240
Compare contents of two files at different offset (we got identicial content):
$ xxd -s 0x360 -l 64 TEST.fd <== skip 0x360 bytes, dump 64 bytes
00000360: 901e 0094 050a 0094 ea03 00aa a1cd 0a58 ...............X
00000370: 0200 e0d2 2200 c0f2 0240 a0f2 0200 80f2 ...."....#......
00000380: c303 a0d2 e3ff 9ff2 6304 00d1 6300 028b ........c...c...
00000390: 0400 a1d2 0400 80f2 2000 03eb 8400 0054 ........ ......T
$ xxd -s 0x240 -l 64 ArmPlatformPrePiUniCore.dll <== skip 0x240 bytes
00000240: 901e 0094 050a 0094 ea03 00aa a1cd 0a58 ...............X
00000250: 0200 e0d2 2200 c0f2 0240 a0f2 0200 80f2 ...."....#......
00000260: c303 a0d2 e3ff 9ff2 6304 00d1 6300 028b ........c...c...
00000270: 0400 a1d2 0400 80f2 2000 03eb 8400 0054 ........ ......T
Prepare an empty pkg, and make it build ok. The main purpuse is to do some exercise with EDK2 build system, and use the empty pkg as the start point for the new platform.
Make a copy of RaspberryPi.dec, change all gRaspberry to gMyPlatform.
Make a copy of RPi4.dsc and RPi4.fdf, and comment out all stuff in DSC and FDF file.
Replace all GUIDs in DSC/FDF/DEC files, generating new ones using online guid generator.
Note that PCD are declared in DEC files, and DEC files are refered by modules (INF files). As the empty package contains no module, no PCD definition will be available in FDF. So for a success build of the empty package, we need to comment out all PCD reference in FDF.
The NOOPT build command for MyPlatform is as below:
#!/bin/bash
export WORKSPACE=/home/bruin/work/tianocore
export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
pushd $WORKSPACE
source edk2/edksetup.sh
echo "Building BaseTools..."
make -C edk2/BaseTools all
echo "Building UEFI firmware for MyPlatform..."
GCC5_AARCH64_PREFIX=aarch64-none-linux-gnu- build \
-n 4 \
-a AARCH64 \
-p Platform/MyCorp/MyPlatform/MyPlatform.dsc \
-t GCC5 \
-b NOOPT \
-v -d 9 -j MyPlatform-build.log \
-y MyPlatform-build-report.txt \
-Y EXECUTION_ORDER \
-Y PCD \
-Y LIBRARY \
-Y DEPEX \
-Y HASH \
-Y BUILD_FLAGS \
-Y FLASH \
-Y FIXED_ADDRESS \
all
popd
Add the 1st component ArmPlatformPrePiUniCore. This component is to prepare the HOBs for DXE phae. The main purpose is to get serial port working and memory config correct. Another purpose of this step is to familiar with steps for adding a component/module/lib. Below is a brief summary of the steps:
Uncomment the module's INF into both DSC ([Components] section), and FDF ([FV.FVMAIN_COMPACT]).
Rebuild the pkg, and resolve all Instance of library class [xxxLib] is not found errors reported, by updating [LibraryClasses] sections of DSC.
This step is a repeating process for dozens of times.
Some lib-class has multiple lib-instances, making sure choose the appropriate lib-instance (ref the build-report of RPi4).
if encounter ModuleEntryPoint.iiii:31: Error: immediate out of range: enable gArmTokenSpaceGuid.PcdFdBaseAddress and gArmTokenSpaceGuid.PcdFdSize in FDF.
if encounter undefined reference to _gPcd_BinaryPatch_PcdSerialClockRate: set PcdSerialClockRate in [PcdsPatchableInModule] section in DSC. FIXME: why? ref.
Check the PCDs listed in build log: inspect any abnormal PCD values, and supply correct values.
Customize platform-specific drivers or libraries.
SerialPortLib: locate the lib-class header file (MdePkg/Include/Library/SerialPortLib.h) by find edk2 -type f -name "*.dec" -exec grep -Hn SerialPortLib. The following functions are required:
SerialPortInitialize()
SerialPortWrite()
SerialPortRead()
SerialPortPoll()
SerialPortSetControl(): RETURN_UNSUPPORTED
SerialPortGetControl(): RETURN_UNSUPPORTED
SerialPortSetAttributes(): RETURN_UNSUPPORTED
ArmPlatformLib: interface header at Include/Library/ArmPlatformLib.h. The following functions are required:
ArmPlatformGetCorePosition(): return cpu idx in the cluster given the MPIDR value. this function is used in _ModuleEntryPoint for setting stack for secondary cores. Assuming one cluster for now.
ArmPlatformIsPrimaryCore()
ArmPlatformGetPrimaryCoreMpId()
ArmPlatformGetBootMode()
ArmPlatformPeiBootAction()
ArmPlatformInitialize()
ArmPlatformGetVirtualMemoryMap()
ArmPlatformGetPlatformPpiList()
etc...
Uncomment more modules in DSC/FDF, module by module...For driver/libs which are RPi platform specific, we can:
either search the edk2/edk2-platform for similiar driver or lib instances, or
copy the RPi4 implementation and comment out most of the content, make the pkg build success first, and then bug fixing.
Debugging: my current main debugging method is through adding "printf()", i.e., the edk2 macro DEBUG((DEBUG_INFO,)). One needs to set gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel to an appropriate value to see more debug info.
Running the example /examples/kuka_iiwa_arm/kuka_simulation gives me the following error:
Blockquote
Traceback (most recent call last):
File "/home/felix/.cache/bazel/_bazel_felix/6a5b9f62883c4665b1f398a636821629/external/drake_visualizer/lib/python2.7/site-packages/director/lcmUtils.py", line 117, in handleMessage
callback(msg, channel=channel)
File "/home/felix/git/drake/bazel-bin/tools/drake_visualizer.runfiles/drake/tools/workspace/drake_visualizer/plugin/show_frame.py", line 93, in _handle_message
frame_channel.handle_message(msg)
File "/home/felix/git/drake/bazel-bin/tools/drake_visualizer.runfiles/drake/tools/workspace/drake_visualizer/plugin/show_frame.py", line 36, in handle_message
vis.updateFrame(transform, name, parent=folder, scale=0.1)
File "/home/felix/.cache/bazel/_bazel_felix/6a5b9f62883c4665b1f398a636821629/external/drake_visualizer/lib/python2.7/site-packages/director/visualization.py", line 879, in updateFrame
obj.copyFrame(frame)
AttributeError: 'ContainerItem' object has no attribute 'copyFrame'
Example was started with:
bazel-bin/tools/drake_visualizer &
./bazel-bin/examples/kuka_iiwa_arm/kuka_simulation
bazel-bin/lcmtypes/drake-lcm-spy shows that the channel DRAKE_DRAW_FRAMES is up and messages are being transmitted.
Information about my system:
Operating system: Ubuntu 18.04
gcc: gcc (Ubuntu 7.4.0-9ubuntu1~18.04.york0) 7.4.0
python: Python 2.7.15+ // This is the default python version
bazel run #drake//common:print_host_settings: gcc (Ubuntu 7.4.09ubuntu1~18.04.york0) 7.4.0
cmake: 3.15.4
drake was built from source using bazel 0.29.0
If I run
bazel-bin/tools/drake_visualizer &
./bazel-bin/manipulation/util/geometry_inspector ./manipulation/models/iiwa_description/sdf/iiwa14_no_collision.sdf
The Kuka arm is shown in the visualizer and I can use the sliders to control the configuration of the arm.
Edit: My problem is that when I run /examples/kuka_iiwa_arm/kuka_simulation, no frames are displayed in the visualizer.
This should be fixed once we update the version of Director shipped with Drake.
We're already in the process of doing so via our Python 3 update: https://github.com/RobotLocomotion/drake/issues/12046
Thanks for reporting this!
I installed drake binary in my ubuntu 16.04 xenial by
curl -o drake.tar.gz https://drake-packages.csail.mit.edu/drake/continuous/drake-latest-xenial.tar.gz
sudo tar -xvzf drake.tar.gz -C /opt
And I find_package(drake) in my cmake and try to do optimization.
But I got the following error
/opt/drake/include/drake/common/autodiff.h:15:1: error: static assertion failed: Drake requires Eigen >= v3.3.3.
static_assert(EIGEN_VERSION_AT_LEAST(3, 3, 3)
and
/opt/drake/include/drake/common/autodiffxd.h:232:69: error: ‘MakeAutoDiffScalar’ was not declared in this scope
return MakeAutoDiffScalar(m_value * other, m_derivatives * other);
I think I am including right Eigen which is located in
/opt/drake/include/eigen3.
How could I fix it?
By the way in the Mac, it works well with the same code.
It may be that you've (either directly or indirectly) called find_package(Eigen) before you did so on Drake, in which case CMake may be finding your system Eigen rather than the Drake-provided version; this is noted here (sorry that it's not yet in a more obvious location):
https://github.com/RobotLocomotion/drake-shambhala/tree/b3d7804/drake_cmake_installed/src/pcl#eigen
If you do find_package(drake) first, then it should allow find_package(Eigen) to work later on.
If that doesn't work, could you post a link to your code in a GitHub repository, or can you make a minimal reproduction issue?
I have a small working example of the tensorflow object detection api working locally. Everything looks great. My goal is to use their scripts to run in Google Machine Learning Engine, which i've used extensively in the past. I am following these docs.
Declare some relevant variables
declare PROJECT=$(gcloud config list project --format "value(core.project)")
declare BUCKET="gs://${PROJECT}-ml"
declare MODEL_NAME="DeepMeerkatDetection"
declare FOLDER="${BUCKET}/${MODEL_NAME}"
declare JOB_ID="${MODEL_NAME}_$(date +%Y%m%d_%H%M%S)"
declare TRAIN_DIR="${FOLDER}/${JOB_ID}"
declare EVAL_DIR="${BUCKET}/${MODEL_NAME}/${JOB_ID}_eval"
declare PIPELINE_CONFIG_PATH="${FOLDER}/faster_rcnn_inception_resnet_v2_atrous_coco_cloud.config"
declare PIPELINE_YAML="/Users/Ben/Documents/DeepMeerkat/training/Detection/cloud.yml"
My yaml looks like
trainingInput:
runtimeVersion: "1.0"
scaleTier: CUSTOM
masterType: standard_gpu
workerCount: 5
workerType: standard_gpu
parameterServerCount: 3
parameterServerType: standard
The relevant paths are set in the config, e.g
fine_tune_checkpoint: "gs://api-project-773889352370-ml/DeepMeerkatDetection/checkpoint/faster_rcnn_inception_resnet_v2_atrous_coco_11_06_2017/model.ckpt"
I've packaged object detection and slim using setup.py
Running
gcloud ml-engine jobs submit training "${JOB_ID}_train" \
--job-dir=${TRAIN_DIR} \
--packages dist/object_detection-0.1.tar.gz,slim/dist/slim-0.1.tar.gz \
--module-name object_detection.train \
--region us-central1 \
--config ${PIPELINE_YAML} \
-- \
--train_dir=${TRAIN_DIR} \
--pipeline_config_path= ${PIPELINE_CONFIG_PATH}
yields a tensorflow (import?) error. Its a bit cryptic
insertId: "1inuq6gg27fxnkc"
logName: "projects/api-project-773889352370/logs/ml.googleapis.com%2FDeepMeerkatDetection_20171017_141321_train"
receiveTimestamp: "2017-10-17T21:38:34.435293164Z"
resource: {…}
severity: "ERROR"
textPayload: "The replica ps 0 exited with a non-zero status of 1. Termination reason: Error.
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/root/.local/lib/python2.7/site-packages/object_detection/train.py", line 198, in <module>
tf.app.run()
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/platform/app.py", line 44, in run
_sys.exit(main(_sys.argv[:1] + flags_passthrough))
File "/root/.local/lib/python2.7/site-packages/object_detection/train.py", line 145, in main
model_config, train_config, input_config = get_configs_from_multiple_files()
File "/root/.local/lib/python2.7/site-packages/object_detection/train.py", line 127, in get_configs_from_multiple_files
text_format.Merge(f.read(), train_config)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/lib/io/file_io.py", line 112, in read
return pywrap_tensorflow.ReadFromStream(self._read_buf, length, status)
File "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
self.gen.next()
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/errors_impl.py", line 466, in raise_exception_on_not_ok_status
pywrap_tensorflow.TF_GetCode(status))
FailedPreconditionError: .
I've seen this error in other questions related to prediction on Machine Learning Engine, suggesting this error probably(?) is not directly related to the object detection code, but it feels like its not being packaged correctly, missing dependencies? I've updated my gcloud to the latest version.
Bens-MacBook-Pro:research ben$ gcloud --version
Google Cloud SDK 175.0.0
bq 2.0.27
core 2017.10.09
gcloud
gsutil 4.27
Hard to see how its related to this problem here
FailedPreconditionError when running TF Object Detection API with own model
why would code need to initialized differently in the cloud?
Update #1.
The curious thing is that the eval.py works fine, so it can't be a path to the config file, or anything that train.py and eval.py share. Eval.py patiently sits and waits for model checkpoints to be created.
Another idea might be that the checkpoint is somehow been corrupted during upload. We can test this bypassing and training from scratch.
In .config
from_detection_checkpoint: false
that yields the the same precondition error, so it can't be the model.
The root cause is a slight typo:
--pipeline_config_path= ${PIPELINE_CONFIG_PATH}
has an extra space. Try this:
gcloud ml-engine jobs submit training "${JOB_ID}_train" \
--job-dir=${TRAIN_DIR} \
--packages dist/object_detection-0.1.tar.gz,slim/dist/slim-0.1.tar.gz \
--module-name object_detection.train \
--region us-central1 \
--config ${PIPELINE_YAML} \
-- \
--train_dir=${TRAIN_DIR} \
--pipeline_config_path=${PIPELINE_CONFIG_PATH}
I'm using CMake 3.4.1, on Windows 10, with MSYS2 (everything up-to-date as of Dec. 25 2015).
When I use CMake's find_file command, it won't work unless the path is in Windows-style. This is a problem for me, because I'm trying to use findwxWidgets.cmake, which fails because of this.
For example:
CMakeLists.txt:
cmake_minimum_required(VERSION 3.0)
find_file(version_h version.h PATHS /mingw64/include/wx-3.0/wx)
message(STATUS "version_h: ${version_h}")
Running cmake spits out:
-- version_h: version_h-NOTFOUND
But it's clearly in there:
>>> file /mingw64/include/wx-3.0/wx/version.h
/mingw64/include/wx-3.0/wx/version.h: C source, ASCII text
I'm wondering if this is a bug, or if there's some obscure flag I have to set to get this to work. How do I get CMake's find_file to find files with UNIX-style paths?
MinGW-w64 cmake can't understand MSYS2 paths. You might propose a path transformation test program to the CMake developers, but that's fairly gross and I'd hope the would reject that. Instead these things must be solved case-by-case. wx-config, being a shell script, is providing an MSYS2 path.
This is a bug in the currently release MSYS2 wxWidgets packages that will be fixed in the next release. To work around it, find the line in /mingw64/bin/wx-config or /mingw32/bin/wx-config:
prefix=${input_option_prefix-${this_prefix:-/mingw64}}
(or /mingw32 of course) and add after it:
if [ "x${MSYSTEM}" = "xMINGW32" ] || [ "x${MSYSTEM}" = "xMINGW64" ]; then
prefix=$(cygpath -m ${prefix})
fi
Be careful to remove it at upgrade time though.