@tom Apologies for the delayed response, but I took your suggestion and had better luck on 0.9.5. Thanks!

@Moderator
We did two flight tests inside our office in a luminous environment. Temperature seems to be lower while flying (around 60°C), and voxl-camera-server didn't stop. Yet, we could not do extensive tests because in both cases the px4 changed the flight mode from Position to Stabilize for visual failures. We attach a screenshot from QGC.!!

e0d21384-f846-454c-a016-22e7312ce0ea.jpg

@Eric-Katzfey I fixed the problem thanks after I download the Seeker's parameter at gitlab it success arm by my RC and It can fly now

OMG! The protective cap on the camera 😬
You're right! Just saw it minutes before checking it here. There was no cap on the first drone; it was probably dropped or something, so I did not even feel the need to look for it.
Thank you, Adrian; sorry for the trouble. Case closed!

Ever have any luck figuring this out? Stuck on the same issue

The tracking camera calibration worked flawlessly after using the seeker in softAP mode, disabling the dfs-server and using the correct checkboard.
Stereo camera calibration was much harder, and after many attempts there was always a failure in the exstrinsics calibration.
We configured /etc/modalai/extrinsics.conf following this guide https://docs.modalai.com/configure-extrinsics/ .

We tried manual control with Position flight mode and it worked fine. After we tried two simple autonomous flights with mavsdk inside docker, mainly using the set_position_ned() method.
http://mavsdk-python-docs.s3-website.eu-central-1.amazonaws.com/plugins/offboard.html#mavsdk.offboard.Offboard.set_position_ned

First mission: arm the drone, take off 1m from the ground, move forward 1.8m and then land.
This one ended pretty badly, with a drone crash. Mission was not followed at all.
The environment was an office sufficiently illuminated, and the Seeker drone started from the position where it was turned on.

Second mission (simpler): arm the drone, take off 1m from the ground, land.
In this one the drone took off around 2.5m from the ground, and then landed with relatively high speed, hitting the ground.

I don't know if it can be an issue but in both tests dfs-server was disabled.

@g-ferrando You can safely ignore that message.
PX4 doesn't have any filters on the power rail of the ADC so it flags any bit of noise on the 5V power rail. We've taken steps to improve that on FCv2.
On both FCv1, and FCv2, our hardware can operate much lower than that default PX4 warning. If you use our power module and get reports that way of system voltage and current using the I2C bus, you can trust those numbers.
Hope that helps.

Hello @JustinDev23 ,

Rotating Hires camera is not an option in the configuration menu, however you can still do this pretty easily.

When you run voxl-configure-cameras, based on your use case, the script writes an appropriate configuration file to /system/etc/camera/camera_config.xml. In that file, you will see entries for all the cameras expected for the particular use case.

Since you have already enabled the hires camera (IMX214), you already have an entry for it in camera_config.xml, so if you find it, you should see something like this <SensorName>imx214_rot180</SensorName> . What this does it tells the camera framework to load a dynamic library /usr/lib/libmmcamera_imx214_rot180.so - our default is the rotated version. To remove the rotation, you simply change the entry to <SensorName>imx214</SensorName>, which will in turn use /usr/lib/libmmcamera_imx214.so library after you reboot and the image should be right side up.

Please remember that running voxl-configure-cameras again will overwrite the camera_config.xml that you may edit.

Hope this helps!

Alex

If you do reprogram your Seeker, this is the configure script

voxl-configure-mpa -p --family seeker

Hey Adrian, thanks for the reply! Chad also replied this morning affirming the inverted image in the portal is normal. I was afraid to fly it until I could confirm that. On the SIM, like I said in the other post, after inserting the new EIOT SIM I ordered and A: Killing the voxl modem service temporarily then B: booting up and killing the WiFi then 😄 running the shell script to configure the modem with the new custom APN for the new sim (which, by the way, is running on the same ATT network as the prepaid ATT phone sim I was trying to use.. it has to be the provisioning on the carrier side that keeps it from working in the modem) thus making the WWAN gateway the default gateway, I can now get a response to any ping I throw at the internet through the wan. I believe the issue with the SIM card socket that makes me have to take things apart to get the sim to actually click into place properly has to do with board "tweakage" or flexing just enough to make the rather delicate sim card locking mechanism bind. You know the board is basically held in position by the two corner silicone grommets and the B2B connector... it doesn't have any kind of screws or standoffs holding it precisely where you want it against the frame. It's just kind of sandwiched in there. if you were to continue to develop the product, I'd look into screwing it down,, Anyway, now that I have a working SIM, all I have to do is keep it active and hopefully never take the Voxl Cam apart again!

Vinny! You're the man! Good news but a little backround first. I've been building drones for a long time, but I come from the "Other side" using a windows box to configure APMs then Pixhawks with Arducopter using Mission Planner. When I got this thing, I literally built an Ubuntu workstation just to talk to it. I'm an old guy that used to live on the DOS commandl line, but I really have to hone my Linux skills (almost nonexistent..) for this project. Outside of the Arduino IDE and some ancient BASIC, I'm no coder, but I understand microcontrollers, serial, I2C, CAN etc pretty well because I come from an industrial automation background. (Amazon Fulfillment Center Controls lead configuring Cognex and Sick every day..) I figured out the serial ports. (I was using the freaking asterisk in the QGC parameter search box like a typical DOS jockey!) I found that in the 1.11.3 firmware the serial parameters are bit masks and numeric with no real reference for me, but in the latest PX4 release they have a dropdown and real names and values, so I loaded it, changed TELEM1 to 921k and Mavlink mode 2 (offboard), saved the params, then loaded your 1.11.3 custom version back up and restored the params. Done deal. Now I just need the level shifters I ordered today and I can try it out. BTW I also ordered two connector kits, one with a pile of GH 1.25's and the other with a pile of DF13's. I've been meaning to get them for a while cause' I have a huge collection of parts that just don't quite match up 🙂 and also because I wear my super-re-pinner badge proudly! I'll let you guys know how the level shifters work. I ordered two types, one with multiple mosfets and one with the TXS0108E chip so I can see what works best when it goes back together. Thanks for your prompt and helpful reply!

Thanks, Adrian! I will look into building two batteries with Sony VTC6 cells.

@Chad-Sweet Thanks; any comment on what temperatures you or the team have seen trying to stream higher than vga resolution through voxl-streamer? Interested if you are seeing the same using 1080p or the full resolution of the sensor, for example.

@powerralley -- I don't work for ModalAI but my off the cuff answer is "yes" and it is something I am trying to build something similar.

Modal does provide some mapping/SLAM capabilities that use the Time-of-flight depth sensor to build a 3D map of an indoor space. It does work, but not without some tweaks and work on your part.

@Vinny Thanks, this helps a lot!

@Steve-Turner Great, thanks! As luck would have it skycharge is already on our short list; I'll look at the page and see what I learn