@voxltester said in Microdds not working with Microhard modem:
Is there any one who is an expert on the microhard and network setting?
You will need to reach out to microhard for config setup on that front.
@voxltester said in Microdds not working with Microhard modem:
Is there any one who is an expert on the microhard and network setting?
You will need to reach out to microhard for config setup on that front.
@Nitin-Varma-Vegesna said in Apriltag relocalization not relocalizing?:
@Nitin-Varma-Vegesna Is there any release that is known to work for April Tag Detection?
https://gitlab.com/voxl-public/voxl-sdk/services/voxl-tag-detector
The dev branch is the most recent - I have to check with the engineering team on this as I am unsure the priority of april tag detection and positioning based off it. Will relay back
https://www.loom.com/share/bf52e252ab09444bb366f265a3f36dc5
Alright take a look at this loom please - it might help point you in the right direction in terms of training your model.
Zach
Let me try and train a custom model and run a loom on it in the next few days and get that over to you showing how I do it!
It seems the TOF sensor and camera port 2 are not functional. I am assuming that you tried using both M0135 adapters to test port 2? Considering that it was working before, this is likely not a software issue, but a hardware issue, but it is not clear why exactly.
All of your cameras are interchangeable in the camera ports, as long as the camera ports and sensors are working (and the sensormodule drivers are set up correctly).
By default, the port 1 (camera slot 1), is reserved for use in a stereo configuration when used with M0076, like this one : https://docs.modalai.com/voxl2-camera-configs/#c10---front-stereo-only . So it will not work as a generic camera port when used with M0135. The functionality can be re-configured in software (requires a change in the kernel), but we don't have a ready-to-go kernel with just this change (we can revisit this later, if needed).
By the way, you can also test VOXL2 J8. J8 is set up in a similar way as J6, that is the J8L can be used for any camera, but J8U is reserved (by default) for another stereo pair. However, this will allow you to test yet another port just to double check things. The camera slot IDs for J8 are 4 and 5. Please note that the orientation of J8 is rotated compared to J6 and J7. You can see how a TOF sensor is attached to VOXL2 J8 via M0076 adapter : https://docs.modalai.com/voxl2-camera-configs/#cx---two-time-of-flights-tof . M0076 is a single port version of M0135 interposer (only providing the Lower camera port).
So, if you test VOXL2 J8, use the lower camera port 4 (J8L).
Yes, M0040 is EOL, so the replacements are not available. The upgraded version of TOF sensor is here : https://docs.modalai.com/M0169/ , however it has different dimensions and connector requirements. We can discuss this further if needed.
What is your goal? Do you need the original configuration working or are you potentially looking for any updates?
Alex
OK, i understand. So i think the next step is to figure out what exactly is not working: cameras, M0135 interposers or VOXL2.
Since we know that the camera slot 3 hardware and software path seems to be working, you can try plugging in other cameras (hires, TOF) in to that slot:
com.qti.sensormodule.imx214_3.bin from /usr/share/modalai/chi-cdk/imx214 to /usr/lib/camera/. You can leave the existing sensormodules in /usr/lib/camera/, no need to delete.voxl-camera-server -l to see if the camera is detectedcom.qti.sensormodule.irs1645_3.bin camera driver)Alternatively, if you have another VOXL2, you could do some testing with that, but I am assuming that another VOXL2 is not available.
Alex
@Leo-Allesch , thanks for checking that. I am assuming that the cameras used to work at some point - can you confirm? What happened between the working and non-working state?
Alex
@Leo-Allesch , sorry for the delay.
Based on your previous post, only one camera is detected:
Cam idx: 0, Cam slot: 3, Slave Address: 0x00E2, Sensor Id: 0x7750
(if more cameras were detected, you would see them show up in that list, which is output of voxl-camera-server -l).
This is the tracking camera in camera slot 3 (VOXL2 J7 Upper slot). The slot numbers are also labeled in the diagram https://docs.modalai.com/voxl2-d0005/, specifically you can see 0, 2, 3 labeled on the M0135 interposers that are plugged into VOXL2:

I do see the correct sensormodules in /usr/lib/camera/. (slot 0 for TOF and slot 2 for IMX214).
I suspect that you have the hires camera and TOF module plugged in backwards into the M0135 adapters. The tracking camera (unfortunately?) has a different connector orientation compared to other cameras, but pin1 is correctly marked with a dot (or a number 1) on all connectors.
Your cameras should be connected like in the picture below:

Another look (in the assembly of the drone):

Please double check the connections.
Alex
@greg_s said in Starling 2 not following navigation path:
One thing that looks suspect is the voxl-mapper pipe size 64k bytes is much smaller than expect (usually in MB, e.g. 32MB-64MB). Is this a preloaded 3D map?
Otherwise your VIO data looks good. It appears the drone does go to the 1st setpoint (1st leg of the trajectory) where that setpoint also looks as if it is landing. It's possible the landing detector was triggered and why everything stops.
I suggest the following:
power up, ssh into 2 terminals
terminal 1 -- run the voxl-mapper
terminal 2 -- run voxl-vision-hub --debug_offboard
take off in position mode, bring up the portal into mapper 3D view as normal, perform a 360 yaw to get a good map
Select "Plan a Point": draw your point and position it correctly
switch to offboard mode (which you have set correctly to 'trajectory')
Select GO!
Select "Follow Path"
(If no follow path is offered then the A* path creation failed)
Hopefully with that sequence, you'll see the drone move along the path. If it does not, then the voxl-mapper output in terminal 1 will tell us if a latency is the culprit.
As an example, here's how I expect the above to play out.. If you cannot repeat this then it maybe worth upgrading to SDK 1.6.3 (as the example was generated in).
@JoonaR can you please provide your order number? Is there a chance you ordered the "no radios" configuration?