R

RobotRoss

A clarification, are the imuModes enumerated, 0,1 2 or 1, 2, 3 ? I.e. is Default = 1 the Copy mode or Linear_Interpret_Gyro?

thank you, makes sense & I'll deploy imu_mode=2. Ross

Thank you. For my small robot application , the IMU data from the OakD to sense rotational velocity I.e yaw about the vertical z axis. I would like to understand the best choice of the 3 modes. Is there a description available that explains how these 3 mode effect the generated rotational data?

The ros 2 stereo_inertial.launch.py launch script includes a imuMode parameter, default=1. What are the characteristics of this parameter, and are there other parameter values and what are their significance ?

Tnx a lot- I should have realized the significance of "Inertial" which sure was an obvious issue that I completely overlooked. No indication on the Luxonis documentation of this condition. I have an original Kickstarter version that has no IMU, which the IMU utility correctly indicated was not installed. I also checked the stereoinertialpublisher.cpp code and there appears that the code expects an IMU in the camera and there is no smooth check otherwise other than crashing Ross

Some progress in that I confirmed my Oak-D has no IMU and I can use a ROS command line parameter to force a camera.i_enable_imu: false i.e. no_imu state

ubuntu@rp4-ub22h-mt:~/depthai-python/examples/IMU$ python3 imu_version.py

IMU type: NONE, firmware version: 0.0.0

ubuntu@rp4-ub22h-mt:~/depthai-python/examples/IMU$ python3 imu_firmware_update.py

IMU type: NONE, firmware version: 0.0.0, embedded firmware version: 0.0.0

Warning! Flashing IMU firmware can potentially soft brick your device and should be done with caution.

Do not unplug your device while the IMU firmware is flashing.

Type 'y' and press enter to proceed, otherwise exits:

y

IMU FW update status: 0.0%

IMU FW update status: 0.0%

Firmware update failed!

However, I with the Luxonis Developer Alexander advice , I was successfully in running :

ros2 launch depthai_ros_driver camera.launch.py model:=OAK-D-LITE paramsfile:=/home/ubuntu/Desktop/no_imu.yaml which publishes a bunch of image topics

no_imu.yaml is

/oak:
ros__parameters:
camera:
i_enable_imu: false
i_enable_ir: false

Though the ros2 launch depthai_examples stereo_inertial_node.launch.py camera_model:=OAK-D-LITE enableRviz:=False params_file:=/home/ubuntu/Desktop/no_imu.yaml

still throws an error even using the no_imn.yaml file ;(

So I added to my Issue #495 for "Alexander" to answer.

Oak-D Lite KickStarter version (0.0.0) on RaspberryPi Ubuntu 22.04/ROS 2 Humble with depthai-ros installed with 3 successful launch: mobile_publisher, rgb_stereo_node, stereo.launch display image on rqt.

This launch starts up ok configuring camera resolutions, then

[stereo_inertial_node-2] what(): IMU(5) - IMU invalid settings!: IMU not detected. Your board doesn't have IMU or requires firmware update (Set imu.enableFirmwareUpdate(True) explicitly.). 1, 347
[ERROR] [stereo_inertial_node-2]: process has died [pid 5770, exit code -6, cmd '/opt/ros/humble/lib/depthai_examples/stereo_inertial_node --ros-args --params-file /tmp

Other posts refer to trying to reset and update firmware don't work, including a try with: https://discuss.luxonis.com/d/3422-depthai-ros-pointcloud-with-no-imu-oak-d-lite configuring a no_imu.yaml

If necessary, specifically how do I upgrade s/w or what param to set?

If the Terminal is enabled for x86_64 ("Use with Rosetta" box checked" and there is NO previous Homebrew installed in the native arm64 Mac, this may work. The problem I had was that I had apreviously installed Homebrew which goes into /opt/homebrew space and sets "HOMEBREW_PREFIX: /opt/homebrew " and matching "PATH" locations. This apparently confuses the depthai installation scripts which installs another homebrew stack in "/usr/local/homebrew" space but does not completely configure the default paths . Execute "_% brew config" to see your default path settings. While I have NOT yet followed these instructions, check out the #macos for posts by whab which uses a virtual environment: https://discord.com/channels/790680891252932659/924798973519216651/934391777811636294 .

Yes, I can confirm the same success with a Ubuntu 20.04 VM on my Mac M1 and that the scripts run fast. As described for a Linux installation, must enable the udev rule. I will look forward, though for release of a native MAC arm64 Homebrew wheel installation. I’ve also installed the depthai on a Jetson Nano B01 Ubuntu 18.04 and Raspberry Pi 4/4G Raspi OS Buster 32 bit arm7.( though the compile takes 35 mins)

Erik, Tnx for response. My (Homebrew) installed python3 from arm64 terminal.app (uname -m arm6) is:
which python3
/opt/homebrew/bin/python3
Ross@Kepler-2 ~ % python3 --version
Python 3.9.9
From x86_64 terminal-rosetta2.app
which python
/usr/bin/python
Ross@Kepler-2 ~ % python3 --version
Python 3.9.9

I have a 1st native “terminal.app”, uname -m arm64. Homebrew is installed in /opt/homebrew & there is text in the PATH environment to this folder. This is the default, per this response to 'brew config" from the Native arm64 and Rosetta x86_64 terminal.
From arm64 terminal.app
Ross@Kepler-2 ~ % brew doctor
Your system is ready to brew.
Ross@Kepler-2 ~ % brew config
HOMEBREW_VERSION: 3.3.9
ORIGIN: https://github.com/Homebrew/brew
HEAD: 96137bc19e68398ebbb7033379df288cd8b9a3f9
Last commit: 4 weeks ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 551bdc22ddc5695e9db3e7a59c30b4dba83fc904
Core tap last commit: 23 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_CASK_OPTS: []
HOMEBREW_CORE_GIT_REMOTE: https://github.com/Homebrew/homebrew-core
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.8 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit arm_firestorm_icestorm
Clang: 13.0.0 build 1300
Git: 2.32.0 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 7.77.0 => /usr/bin/curl
macOS: 12.1-arm64
CLT: 13.2.0.0.1.1638488800
Xcode: 13.2.1
Rosetta 2: false

From x86_64 terminal-rosetta2.app
Ross@Kepler-2 ~ % brew config
HOMEBREW_VERSION: 3.3.10
ORIGIN: https://github.com/Homebrew/brew
HEAD: 385892f3d27dcab0f5a1cb47c3927d9d65ed007c
Last commit: 33 hours ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: aa2f643fd4215653c61d968ca54ff5c56b6f3da6
Core tap last commit: 20 hours ago
Core tap branch: master
HOMEBREW_PREFIX: /opt/homebrew
HOMEBREW_REPOSITORY: /opt/homebrew
HOMEBREW_CELLAR: /opt/homebrew/Cellar
HOMEBREW_CASK_OPTS: []
HOMEBREW_CORE_GIT_REMOTE: https://github.com/Homebrew/homebrew-core
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 2.6.8 => /System/Library/Frameworks/Ruby.framework/Versions/2.6/usr/bin/ruby
CPU: octa-core 64-bit westmere
Clang: 13.0.0 build 1300
Git: 2.34.1 => /opt/homebrew/bin/git
Curl: 7.77.0 => /usr/bin/curl
macOS: 12.1-x86_64
CLT: 13.2.0.0.1.1638488800
Xcode: 13.2.1
Rosetta 2: true
Ross@Kepler-2 ~ % uname -m
x86_64

The 2nd terminal-rosetta.app was configured enabled for Rosetta2, as described by your Brandon Dec 20 note “69-depthai-apple-m1-based-macs”. uname -m x86_64. There is a 2nd homebrew installed in the pre-M1 folder /use/local/homebrew This text is not in the PATH. I ran the python3 -m install_requirements.py from this Rosetta2 enabled terminal, with the earlier posted result. The system seems to want to run the arm64 version of Homebrew Python to build your depth wheels, even while using the x86_64 terminal, probably because of the PATH text , with the resulting errors. Is there a way to force the system to stay with the x86_64 terminal Homebrew for running python3 ?

So since the Mac M1 has been out for over a year now and presumably Homebrew has matured, can you release a native arm64 depthai wheel? I’d rather not potentially break my current Homebrew jury rigging the x86_64 Rosetta2 terminal. I note there are other Data Scientist packages in arm64 Homebrew , such as numpy, scipy.
Regards
RobotRoss

With a new Oak-D-Lite on my Mac Mini M1 Monterey, using a 2nd Rosetta enabled Terminal that shows "uname -m" is x86_64, I was unable to run "python3 -m pip install depthai", apparently due to conflict with the "default" installation in /opt/homebrew. Collecting depthai
Using cached depthai-2.14.0.0.tar.gz (325 kB)
Installing build dependencies ... done
Getting requirements to build wheel ... done
Preparing metadata (pyproject.toml) ... done Building wheels for collected packages: depthai
Building wheel for depthai (pyproject.toml) ... error
ERROR: Command errored out with exit status 1:
command: /opt/homebrew/opt/python@3.9/bin/python3.9 /opt/homebrew/lib/python3.9/site-packages/pip/vendor/pep517/in_process/in_process.py build_wheel /var/folders/_j/1spktm_s02xgtcbwv77rwfn80000gn/T/tmplmufspx7 ....and lots more errors !