That was the reason. In the voxl-px4-start script 9 i2c deviced were initialized. Removing few of them that we are not using was enough to make it work. The interesting part is that even if the device is not connected and the initialization of the module fails, it still counts for the limit of 8 devices.
Thank you.
Hi thank you for the reply. They already do have the same frequency.
I'm trying to understand what's happening inside the _config_i2c_bus function i2c.cpp, however it's a callback set during the initialization of px4 I'm guessing by this function in I2C.hpp
static void configure_callbacks(_config_i2c_bus_func_t config_func,
_set_i2c_address_func_t addr_func,
_i2c_transfer_func_t transfer_func)
{
_config_i2c_bus = config_func;
_set_i2c_address = addr_func;
_i2c_transfer = transfer_func;
}
which is called by px4muorb_orb_initialize in uORBProtobufChannel.cpp. However px4 doesn't directly called it and the definition of the function:
int px4muorb_orb_initialize(fc_func_ptrs *func_ptrs, int32_t clock_offset_us) __EXPORT;
makes me think that it's called by an external service but can't find which one. Can you help me understand what happens during the px4 initialization and what's calling px4muorb_orb_initialize?
Hi,
I'm working on a voxl2 with sdk 1.4.1 and I need to handle three i2c devices in voxl-px4. The devices are the following:
Each of the device is handled by a px4 module, initialized in voxl-px4-start. Until I start only two i2c devices everything works fine however the third one always fails at this line "_i2c_fd = _config_i2c_bus(get_device_bus(), get_device_address(), _frequency);" of i2c.cpp.
Note that the order of initialization matters, for example if I initialize the devices in the order 0x44, 0x29, 0x77 the device 0x77 will fail. If the order is 0x29, 0x77, 0x44 would be the 0x44 device to fail.
This is how the three modules are initialized in the voxl-px4-start script
qshell vl53l1x start -X -b 4 -R 0 #range finder facing forward
qshell finder_i2c start -X -b 4 -M 0 #custom module that handles the rangefinder facing downwards
if [ "$POWER_MANAGER" == "VOXLPM" ]; then
# APM power monitor
qshell voxlpm start -X -b 2
fi
In this case the voxlpm fails to initialize with the following error log
INFO [qshell] Send cmd: 'voxlpm start -X -b 2'
INFO [muorb] SLPI: Marking DeviceNode(qshell_req) as advertised in process_remote_topic
INFO [muorb] SLPI: qshell gotten: voxlpm start -X -b 2
INFO [muorb] SLPI: arg0 = 'voxlpm'
INFO [muorb] SLPI: arg1 = 'start'
INFO [muorb] SLPI: arg2 = '-X'
INFO [muorb] SLPI: arg3 = '-b'
INFO [muorb] SLPI: arg4 = '2'
INFO [muorb] SLPI: *** I2C Device ID 0xd24411 13779985
INFO [muorb] SLPI: Initializing VOXLPM on channel 0
INFO [muorb] SLPI: Set up I2C bus mutex for bus 2
ERROR [muorb] SLPI: i2c init failed
INFO [muorb] SLPI: PX4_qshell: no instance started (no device on bus?)
ERROR [muorb] SLPI: Failed to execute command: voxlpm start -X -b 2
INFO [qshell] cmd returned with: -1
INFO [qshell] qshell return value timestamp: 356875512, local time: 356879115
ERROR [qshell] Command failed
I'm most interested in the Starling 2 slam outdoor performance. I know that the sensor configuration (tof+tracking) of the drone works best indoor due to the relative short range of the tof sensor. However i would like to know if you have some data about outdoor performance. Is it completely unusable or it works only in certain environments? If objects are outside of the tof range does the localization still work only with the trackers (visual odometry)? If so, how far from the ground or the surrounding objects can the drone be to localize?
Going back to a indoor environment, in case of bad lighting conditions does the slam algorithm work properly even without (or with a limited) help from the tracking cameras? Is the tof also influenced by the ambient lighting?
Thank you