@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!

@Alex-Gardner All right, thanks so much for that

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

@justinGE This is good information, thanks for sharing!

@Kris The LTE add-on board (M0030) has 2 JST ports for client USB devices

@joshuagaus Even with our new upcoming module we will not support PPM. It looks like there may be some other communication options on that receiver so you may want to review all the possibilities.

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

@Alex-Gardner Definitely interested in open VIO options. Would be awesome being able to use other techniques for picking out key points and even accelerate them on the hardware. Maybe QVIO already does that...

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

Yes, we ship within 10 business days. The payload capability is about 1kg

Thanks!!

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

Reading your post again . . . It looks like you'll have to QGCs running, but using the same router. In the response above, I assumed a single GCS. On each drone, go to /etc/modalai. There should be a file qgc-ip.conf or something similar. You can set the IP of the target laptop, so the MAVLink gets routed properly. Let me know if that works.

We don't believe there are any issues, but we just sent you an email in case.

@MaxG we are currently low on stock of the replacement parts, but they can be found here on our web store. Please check back in the next week or two and those will be in stock. Replacement landing skids can be special ordered. Do you need the entire skid assembly or just the landing skid itself (black part)? Please send a picture to contact@modalai.com and we can get you the parts that you need!

Hi Akash, we do not expect much of the Qualcomm Flight RB5 SDK to work on the RB5 dev kit without a significant amount of work.

@RichieRich GPS unit is mounted by default (as it comes with RB5 5G drone), mast is locked in vertical postion. Turning EKF2_REQ_SACC to 0,75 provided no errors from GPS. Obstacle avoidance was also disabled, so we managed to fly. But I'm still a bit confused why the obstacle avoidance gives error, since the drone was placed on the ground (concrete pavement), no obstacles within few meters, while the minimum distance was set to only 1 m. But this is current setup that works: [image: 1649438004385-0de5d598-3401-4512-9e7b-3ef8202ef635-image.png] Many thanks for your help. We'll try to figure this out and provide info in a few days.

Thank you for the response! I didn't have time to look into this yet. But there is more going on with the system I think. WIFI also doesn't work anymore. And after trying to solve the WIFI, the ADB of the VOXL stopped working. So we for now we are using a different VOXL. Something else we are running against is the message Reject position control, with working VOXL CAM systems installed on our drones. When we fly everything is super! When we land, after the drone has bumped into things while flying (drone is collision proof) or when heavy wind was pushing it. We cannot take off after landing, it will display Reject position control. Only when the we connect a laptop to the QGC, we can hear that the VOXL reboots and then the Reject position control is gone, and we can go fly again. But if we use QGC via the PX4 Telemetry port, this doesn't happen, and we need to unplug and replug the battery to be able to get the Reject position control message away again. We don't really know why this happens and how we can solve this. It would of course be great if the VOXL didn't need to reboot in order the drone can fly again in position mode. But it already would be helpful that the VOXL would reboot without having to have WIFI connection with QGC. Please help!

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)