@stevet All right, thanks so much for that, and I will have a try about it then

@Alex-Gardner All right, thanks so much for double-checking

Hi @Chad-Sweet thanks for that, and it seems it could work by setting a higher value of the maximum speed in QGC. I will test it again to see if it could work to achieve a fast speed in the mission mode

Hi @張為超 All right, thanks so much for that, and I will then have a look at it

Yes, chr is an issue most likely. Take a look at how uint8 from a binary representation is sent here : https://gitlab.com/voxl-public/voxl-sdk/core-libs/libapq8096-io/-/blob/master/lib/python/voxl_i2c_apm_v1.py#L48 you can do something similar (also example for hex). The data type needs to be some sort of an int. #values of configuration registers CTRLA (address 0x00) and CTRLB (address 0x01) CTRLA = np.uint8(int('0b01011000',2)) #offset calib every 128 conv, volt=Sense+; so sampling takes about 35ms (for both voltage and current together) CTRLB = np.uint8(int('0b00000100',2)) #addresses of registers for reading data REG_VRAW = int('0x1E',16) REG_IRAW = int('0x14',16) #write configuration to both LTC2946 devices p.slave_config(ID0) p.write(0,8,CTRLA) p.write(1,8,CTRLB) ... p.slave_config(ID0) vraw_batt = p.read(REG_VRAW,8,2) iraw_batt = p.read(REG_IRAW,8,2)

+1 for this functionality if possible. Would it be possible to merge the color branch into dev/master for the next release? If speed is a problem I think it would be acceptable to limit this to lower resolutions as a starting point

We do not have any recommended or supported gimbal solutions at this time, sorry. We have had a difficult time finding one that is readily available. Some folks have had luck with Tarot gimbals though, you could try that.

sorry for the slow reply. We have a bunch of data from our dyno bench here

@Developer-Evaluation Exactly. If you're using an alternate data link for motor control such as LTE or Microhard the RC radio is purely for safety purposes.

This issue pops up from time to time and it is, without fail, a hardware issue. Can you check not just the connectors for your stereo cameras but also the cables themselves. They can develop kinks or get scratched and expose the traces if they go through any number of unfriendly environments, which will regularly lead to hal3 being unable to see the device.

Great, thanks for the info. I suspected something along those lines.

@PawelJ Thanks for sharing! Great work!

Hi @jsearlePSU_ARL , I wouldn't expect battery affecting the measurement, but possibly vehicle response (although not at 34%). The default params are setup for 4s as well. When batteries get low, 'power' gets low, and thus response, so the oomph to move to desired location, but not the sensors ability to measure (that power source is from the VOXL power module output, not tied to the motors power per-se).

Hi @gonzalo-mackay , The m500 is used in a lot of use cases, altitude hold mode being used by our test pilots for sure. We have a decent amount of videos showing usage here: https://www.youtube.com/c/ModalAI

No, but the code for that utility can be found here, seems like a great feature to add! Also, QGroundControl likely logs that same information