@wilkinsaf Flying correctly for the most part yes.
Except during specific maneuvers as i have described in my first post (details in the github link) and the third post.
Its challenging to summarize the issue in a few lines..
@wilkinsaf Flying correctly for the most part yes.
Except during specific maneuvers as i have described in my first post (details in the github link) and the third post.
Its challenging to summarize the issue in a few lines..
@wilkinsaf actually no, I'm using neither GPS nor mag (disabled both) as my flights are entirely indoors
@wilkinsaf That solved the issue for you?
Any devs?
I was able to produce this issue on two separate Starlings and a customized 250g drone
@Eric-Katzfey said in Starling infinite loop switching between Position and Manual mode:
And if you start voxl-camera-server and then put it into position mode is that okay?
Not immediately. The longer the system was in the endlessly switching state the longer it takes for it to recover even after voxl-camera-server is started. Can be in the order of minutes.
My guess is that you stopped voxl-camera-server but not some of the other services that depend on it like voxl-qvio-server, voxl-vision-hub, etc. and so they are sending erroneous data to px4 which confuses it.
During this weird behavior I have attempted to turn off all other services that might be doing this, which includes the 2 that you have mentioned. The only exception is voxl-mavlink-server which obviously I can't turn it off but after restarting it, it's still weird behavior is still present.
You are, obviously, trying some non-standard stuff here.
Yes I do understand that. I'm just wondering why it appears only when the WiFi interface is used for communication and not when cellular 5G is used...
Also, with respect to the RC, make sure you set RC=EXTERNAL in /etc/modalai/voxl-px4.conf so that the RC drivers are not started needlessly.
Ok will do so thanks
@Eric-Katzfey said in Starling infinite loop switching between Position and Manual mode:
@hmlow Can you clarify a couple of things?
Why do you disable voxl-camera-server?
Will only start the service before the aircraft is going to take off, which may or may not take quite a while.
Im using the Starling to dev and test this but will eventually be ported over to smth else.
If you keep it enabled does it solve the issue?
Yes
When you say no RC transmitter does that just mean that you do not turn on the transmitter or do you actually disable the RC driver in PX4?
Do not turn on the transmitter (in fact i did not purchase any). Control is done entirely with QGC with a gamepad/joystick.
If the mode of communication is WiFi, this issue shows up.
If the mode of communication is cellular (modified Starling with the 5G Quectel modem), this issue does not occur.
And when you say GNSS and Baro disabled (my bad, enabled) how are you doing that?
EKF2_GPS_CTRL 0
SYS_HAS_GPS 0
SYS_HAS_BARO 1
EKF2_BARO_CTRL 1
EKF2_HGT_REF 3
EKF2_EV_CTRL 15
Hi did anyone manage to verify this?
Hi did anyone manage to verify this?
While the logs and graphs above are based on my own customized aircraft, I just tried the same maneuver on the Starling (with shipped params and configured for indoor VIO) and i can confirm that the same observation is repeatable.
Im curious if you guys would see the same uncommanded climb/sink if you would roll your own Starling aircraft left (or right) for 10 - 20m (3m/s, with CP turned off) and then in the opposite direction. The logs would also show that the EKF2 estimates having the same issues as i have described here and on the github post..
Hi devs
Can i trouble you guys to verify if this following is a legitimate bug?
I am able to repeat the observation on 2 different units of Starling.
SDK1.0 with voxl-px4_1.14.0-2.0.43
VIO only. GNSS and Baro disabled. No RC transmitter.
Note: On a customized aircraft configuration (same SDK 1.0 and same voxl-px4 version as above) but with connection done over cellular 5G, this issue does not occur.
Thanks
@Moderator Yes the extrinsics are correct and the VIO pose matches PX4 EKF2 estimates well except during the segments max velocity rolling maneuvers at 3m/s where VIO and EKF2 Vz and z deviates (but VIO's estimates is correct and matches with visual observation), which is what this post was about in the first place.
Comparison of x y z between VIO and EKF2 local position estimates:
Comparison of Vx between VIO and EKF2 estimates:
Comparison of Vy between VIO and EKF2 estimates:
Comparison of Vz between VIO and EKF2 estimates:
Im attaching the voxl-logger VIO logs and PX4 ulg file here. The 2 files are already time synced so you can plot them directly.
Thanks
Amended the EVV and EVP noise and gate size values..
Doesnt seem to have made any diff; EKF2 local position Vz and z gradient are still in different directions during full left and right roll, whereas VIO reported Vz and z are seemingly correct instead. I have uploaded this log on the github post as well.
Extrinsics are correct because the VIO outputs are correct as mentioned.
I should also add that this is not based on the Starling but a smaller customized drone.
Have clocked at least 50hrs of indoor flight from SDK 0.9 thru 1.0 but only recently did i realize this behavior as i adjusted the max velocities up to 3m/s from 1m/s.
At 1m/s this issue is barely noticeable.
@Moderator yes I have configured the extrinsics.
I should also add that I have been flying this configuration for the last 6 months entirely indoors without any problems. I would imagine that extrinsics should not be the issue here since it affects only the qvio-server outout. Qvio's Vz and z are correct; it's the fused EKF2 outputs that are problematic (refer to the post I made in GitHub above).
I only realized this issue recently when I increased the various forward and side velocities from 1m/s to 3m/s.
Can I trouble you guys to try it on the Starling in an indoor environment with say at least 15-20m of empty space? Let the aircraft move forward or sidewards at full speed.. does it climb (or sink) while moving and visibly corrects the altitude after it has stopped (by as much as 0.5m)
Hi all
Im encountering an issue where the Vz and z estimated by QVIO is accurate but the fused Vz and z estimated by PX4's EKF2 is not, and in fact, inconsistent and moving in different directions. Im not sure if its a mainline PX4 or ModalAI PX4's bug, but i would appreciate if someone could take a look?
I posted the whole issue in detail on mainline PX4's github here:
https://github.com/PX4/PX4-Autopilot/issues/22196
Im on SDK1.0 and voxl-px4 is voxl-px4_1.14.0-2.0.43.
Many thanks
Thanks for the clarification!
@Moderator I am aware of the page.
What I meant was that I am unable to locate the thermal cal parameters like SYS_CAL_ACCEL on the Parameters page on QGC and so am wondering if ModalAI's customized PX4 is without that feature?
Hi devs
I thought I'd perform thermal cal for PX4 IMU but I realized that params like SYS_CAL_* and TC_* were missing.
I'm on SDK 1.0'x voxl-px4.
Were they removed?
Thanks
H devs
As the title suggests, is it possible to have voxl-streamer stream RTSP/RTP over TCP instead of what i understand is currently implemented as UDP?
Thanks