Hi,

VOXL comes with FastCV installed, the 2 headers can be found in /usr/include/fastcv/ and the libs are in /usr/lib/ :

voxl:/$ find /usr | grep fastcv /usr/include/fastcv /usr/include/fastcv/fastcv.h /usr/include/fastcv/fastcvExt.h /usr/lib/libfastcvadsp_stub.so /usr/lib/libfastcvopt.so /usr/lib/rfsa/adsp/libfastcvadsp.so /usr/lib/rfsa/adsp/libfastcvadsp_skel.so

Hi @Anton-Gereles ,
Can you please elaborate on your platform and specific problems you are having?
I'm sure our Software team will want to know that to respond appropriately.

That being said, our components and hardware elements are all at least rated for 0-70C, with many of them exceeding that. However, be mindful that is a non-condensing requirement.
If you are operating in extremes (we have many customers that do), you need to be mindful of condensation risks. Rapid change in temp from a "room temp" building into an outdoor setting with high humidity and much colder temps (and especially vice versa) can create condensation.
In these types of environments, you may need to provide some type of enclosure to protect the electronics against this build-up.
Also, our products are not dust and particle ingress resistant as a default, again this would be something we leave our customers to define for their industrial/mechanical design requirements for an enclosure.
Hope that helps and if you do provide more failure info, our SW team could respond.
Thanks!

Hi,

We've published an RB5 platform release that uses the entire VOXL SDK stack instead of the rb5 software suite. This supports using voxl-camera-server and voxl-streamer as you would on a voxl or voxl2. This release can be found here

The camera server is working with another set of cameras after I reflashed the voxl 2. This might be a hardware issue. Thank you.

https://forum.modalai.com/topic/1328/camera-servers-docker-build-royale-331-spectre-4-7 may have some answers for you on voxl-camera-server which is something ModalAI is working on WRT the build.

@darwin-keem,

It looks like voxl-mapper failed to reach your goal point, resulting in it sending over the partial trajectory it solved for viewing but not giving you the option to follow the path. You can try giving the RRT solver another second or so by increasing the rrt_max_runtime_nanoseconds param, and it should be able to fully plan to your endpoint.

The path generation code has been rewritten and thoroughly optimized in the latest dev package, so if you are still having issues with this planner it may be worth checking out some of the updates on our dev repo.

Hi,

The default framerate of 15 hz will limit the sensor to around 2-3 meters, lowering this to 5hz will allow you to see the full range of the sensor. As for the IR image, it's meant to help debug what the sensor sees, this isn't a normal camera with exposure/gain so the IR image will represent what the sensor actually sees, not necessarily in the most human-viewable format (Note that we often find the confidence image looks better to our eyes for demos).

Yes it should work -- I haven't explicitly tried pointing directly downwards myself. https://docs.modalai.com/flying-without-gps/ has some insight and a nice video about the subject of using VIO outdoors.

It does work at 45* reasonably well especially with enough altitude to pick out features.

Thank you!

Here is the log:

-- Logs begin at Thu 1970-01-01 00:01:35 UTC, end at Thu 1970-01-01 00:03:25 UT C. -- Jan 01 00:01:37 apq8096 systemd[1]: Started voxl-vision-px4. Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: ERROR validating VIO data receiv ed through pipe: read partial packet Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: read 156 bytes, but it should be a multiple of 324 Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: ERROR validating VIO data receiv ed through pipe: read partial packet Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: read 156 bytes, but it should be a multiple of 324 Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: ERROR validating VIO data receiv ed through pipe: read partial packet Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: read 156 bytes, but it should be a multiple of 324 Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: ERROR validating VIO data receiv ed through pipe: read partial packet Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: read 156 bytes, but it should be a multiple of 324 Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: ERROR validating VIO data receiv ed through pipe: read partial packet Jan 01 00:01:38 apq8096 voxl-vision-px4[2018]: read 156 bytes, but it should be a multiple of 324

@Ed-Sutter Thanks! Always better to start a new thread for a different question.

@Anton-Gereles Try to upload these parameters - https://gitlab.com/voxl-public/flight-core-px4/px4-parameters/-/blob/master/helpers/m500/ekf2_indoor_vio.params

This will allow you to fly outdoors without GPS using VIO.

I think this is what you are looking for? https://docs.modalai.com/flying-without-gps/

Hi,

voxl-camera-server requires voxl-cross >=v2.0. This includes the proprietary packages built in, which contain some hardware specific headers and libs (like android's liblog, not voxl-logger). As for APQ camera server vs voxl camera server, The builds for the two platforms used to be separate but we managed to merge them in together recently and are working out the last few kinks in the unified voxl-camera-server, after which we will deprecate the apq specific one.

@Ed-Sutter There is more to it than on the surface, as our SW team has gone to great lengths to figure out how to prevent corruption, so I still think it's the correct thing to follow as per that link, but we do need to educate users on the differences.
Adding some type of hardware level button and "safe to remove" indicator has been in discussion for years, but the practical implementation of that (since for most use cases, we'd want it different than a smart phone) leads to a whole bunch of low-level work that may not actually succeed.
These chips "think" they are in a phone, no matter what we do, so we try to work around it the best we can.
I know the team still thinks about this... maybe we'll get a clean solution one of these days.

@Vinny ok, thanks again..