Posts made by hmlow

@hmlow
Anyone?

Hi ModalAi folks

Any idea when will the ToFv2 be added to the online store?

Thanks

@Alex-Kushleyev I'll glue it back in place myself. Thanks!

@Alex-Kushleyev

Yes the lenses is clear and unscratched.
I just tried gently rotating the lens and it does rotate!
I have not tried rotating the rest of the OV7251 cam lens in case i end up inadvertently damaging them.

Regarding your point about flying out the window -
I have flown these aircrafts outdoors before and even with motion, for as long as the features are far away, the quality metric is bad.

However, i noticed that the quality metric shown here remains extremely good even though the features are more than 100m away:
https://forum.modalai.com/post/11882
Two key difference here though:
-OV9782 is used (higher resolution)
-Sharper images (you can see that the entire frame is sharp vs the regular OV7251 where the corner/edges are always soft (pillars in the opposite bldg)

Should the OV7251 (even the regular, working ones) be better focused?

Supplementary post to elaborate what i mean when i said that the VIO works well indoors but Qual drops instantly when the features are far away. The images arent exactly sharp:

@Alex-Kushleyev

These two below are captured from a custom drone that is known to fly reasonably well in feature rich indoor environments.
When flying outdoors, even if the scene is feature rich and QVIO is actively tracking 20+ features, the quality drops drastically (to -1) if they are far away like more than 200m away. I have at least 10 identically built so far and they exhibit similar behaviors indoors/outdoors.

The Murata box is placed at around 20cm and 60cm respectively:

I wont consider the lens to be sharp as you can hardly make out the words "murata" at 60cm. Got me thinking if the poor outdoor performance is due to the lenses being poorly focused.

Then, these two below however are taken from a brand new builds:

This im quite sure has got something wrong with the lens/focus isnt it?
I dont think the lens can be adjusted in the first place.

Is the OV7251 fisheye tracking cam supposed to be somewhat out of focus rather than being very sharp?

@Eric-Katzfey

Did anyone manage to send AT commands to the EM9291?
Doesnt seem to be possible as no virutal serial ports ttyUSB* were created.

While it is possible to use qmicli --nas-xxxx functions to set and query information, it is no where near the flexibility offered by AT commands.
For instance, i may wish to lock preferred network to LTE instead of 5G/LTE to prevent it from switching back and forth.

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

@Cliff-Wong

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.

1. Disable voxl-camera-server launch on startup ie. systemctl disable voxl-camera-server
2. Reboot/power up the Starling
3. Connect to Starling over WiFi
4. Flight mode shown by QGC is Manual mode. Now, select Position mode on QGC to command the flight mode change.
5. From here on, flight mode switches back and forth between Position and Manual endlessly

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.

VIO log
PX4 log

Thanks

@Cliff-Wong

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.