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

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.

+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

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)

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

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 😉

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

@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 that 😉

@modaltb I see. It's good to know the story 😉

If 22027 is the default one, it will be all right.

To be honest, I didn't touch the CBRK_IO_SAFETY before, and it's a bit weird why it was automatically modified for some reason.

Actually, I was trying to refresh a re-compiled 1.11.3-0.2.3 with my modification (increasing GPS log rate). So, I guess it might reset the value to 0 by PX4 default.

Anyways, thanks so much!

That was actually a very good question. Any recommendations?

I think you'll need to create a new service that behaves like voxl-qvio-server ? That might be the easiest if you want to drop it. Maybe try copying qvio-server and modifying to publish mocap data?

Hi Jonathan,

The underlying pipelines for the CV sensors are all delicately built and only support very specific resolutions. I'll update our documentation to better reflect this, but in general: The stereo pipeline can only do 30hz(for now, we're working on this) since it's very custom and the tracking camera can do 30,60,90, and 120hz. The hires camera is more standard and has more robust pipelines implemented to support more standard video stream configurations.

As for the manual exposure/gain, have you set the auto exposure mode to "off", if not you're just setting up the starting point for the camera and the AE library will still perform it's usual duties.

If you're still having issues after this let me know and we can dig through more of what you're seeing.

@DarkKnightCH Use a flat tipped screwdriver or similar device to slowly pry it out. Take your time working both sides of the the Hirose connector. Take care as the pins can get bent if too much force is applied

@Adrian-Hidalgo All right, thanks. I will check them step by step, and hope it will be solved soon 😉

Seems to be an issue with QGC itself. The latest v4.2.3 I’m running is where it’s failing. If I revert back to the latest 4.1.* (4.1.7) it works.