Hello @Richa,
The documentation states the following: (https://docs.modalai.com/micro-coax-user-guide/)
The part number for the coax mating connector is the following : DF56C-26S-0.3V(51).
If you are designing a carrier board for VOXL2, you could request some help from our engineers to help review the design before you send it for manufacturing.
I hope that helps.
Alex
Hello @HsinSWT ,
When i see results like this, i would say there is probably 90% chance that the motor is bad. Unfortunately, there is a chance that the ESC is bad as well, and there is no good way to check the ESC without a known good motor (however the ESC failure is unlikely).
As I mentioned in the previous post, if you had a milli-ohm meter, you could test the motor winding resistance to confirm whether the motor is good or bad. A tool like that measures resistance with high precision (similar to a regular Ohm meter). However, if you don't have one, it may not be worth buying it..
You will not be able to measure the winding resistance of these motors correctly with a regular Ohm meter. However, you will be able to detect a complete open circuit (which could be the case, maybe worth trying). If testing resistance using a regular Ohm meter, any two connections between the 3 motor phases will read 0 ohm (or close to that). If a wire is broken, then you can detect it.
The Starling 2 motor (3000kV) has around 0.360 - 0.370 Ohm phase-to-phase winding resistance.
In order to confirm that the ESC is working properly, you could temporarily connect one of the working motors to the ESC Channel 0 and do the same spin test (using voxl-esc tools), just to confirm that the ESC Channel 0 is working fine.
In order to fix the issue, you could order a new motor and replace it yourself (will be a lot cheaper): https://www.modalai.com/products/starling-2-replacement-parts?variant=49707605393712
You could also send the whole drone back for repair (https://www.modalai.com/rma)
Alex
@tom , what would be the right course of action here? Thanks!
Hello @Dronodev ,
The other side of the M0166 PCB has a picture of a tiny figure which shows the nominal "up" orientation. You will see the little guy in the image below (coax cables are going up):
So if you flip the camera around to point away from you, then reference frame will be (right-handed):
So your first diagram (on the left) is correct.
Here is specifically what en_rotate flag in voxl-camera-server.conf does for AR0144 camera:
voxl-camera-server)If you enable the rotation this way, you will need to either re-do the camera calibration or rotate your intrinsics manually, which I guess is trivial.
In terms of extrinsics (in /etc/modalai/extrinsics.conf file), you will need to update the camera rotation by 180 degrees along the Z-axis, if en_rotate flag is used (assuming you had it already configured for the non-rotated configuration).
Alex
@Richa , you should find information you need in the links below:
Alex
Hello @awagner ,
I am sorry this happened to you. A few questions / comments:
It seems your motor is too large for this mini ESC
https://docs.modalai.com/voxl-mini-esc-datasheet/
the kp value is very aggressive (typically i would recommend starting at 0 kp and ki (proportional and integral gains) and ramp those up to increase responsiveness.
the spin-up type should be set to 1 (sinusoidal), since it is much more reliable. Which parameters did you start with when you calibrated your ESC? i suspect that improper spin-up caused the ESC to get out of sync and fail due to excessive current.
I know it can be difficult to get started with using new hardware. Aside from the need for updated esc parameters, the issue here is that the mini ESC is not suitable for your motors / propellers. I strongly recommend upgrading to our FPV ESC , which is build to handle a lot of power and stress:
Once you get the FPV ESC, I can help with the tuning (let me know, i can provide updated params before you test gain).
Please submit an RMA request, https://www.modalai.com/pages/rma . I would recommend at least a discount on the new ESC. We will try to improve documentation to avoid this in the future.
Alex
Hello @taiwohazeez ,
Thank you for sending updated images.
Just for sanity checking, please double check that the other tracking camera on your drone is in focus and does not have this issue.. (i assume that is true).
To me, it definitely looks likes either
If you are comfortable with unscrewing the lens completely and wiping it (front and back) with a new microfiber cloth (preferably long strand) and screw it back again to check if there is any improvement. Also, once you remove the lens, you can take a look at the sensor itself, any dirt or smudges should be very easy to detect because the surface of the camera sensor is very reflective and should be perfectly clean. I can't recommend cleaning the sensor itself on your own, since that would involve inserting something inside the camera module, which could lead to damage. Please dont keep the lens out of the lens holder for a long time (hours) as dust or dirt may get inside on the surface of the sensor (do not perform this procedure in a dusty environment).
Please reach out to https://www.modalai.com/pages/rma if you need further help to get this fixed / replaced.
Alex
@l05 , when in doubt, you can add a print statement in your app as a sanity check to make sure you are running the correct version of the application. Then check your print statement at run time.
If you are modifying an existing app in voxl-mpa-tools, you just need to use the voxl-cross docker image to
dpkg -i <package.deb> on target) or using a convenience script deploy_to_voxl.sh which is typically present in most voxl projects -- this script will push the deb to voxl2 and install the deb.If you are adding a new app to voxl-mpa-tools project, you will need to modify the CMakeLists.txt file in the tools folder, it should be self explanatory how to add a simple app. Once you build and deploy, your new app will be installed into /usr/bin on voxl2.
If you have any other questions, let me know.
Alex
Hello @shalini-kumari ,
The M0186 camera uses the Sony IMX664 sensor. You can find high level information for the M0186 module here https://docs.modalai.com/M0186/ (as well as a link to the basic documentation from Sony).
The camera sensor itself (within M0186 module) requires three primary voltages, 3.3V, 1.8V and 1.1V. The maximum power consumption is 0.6-0.7W (theoretical), although we have not explicitly measured it.This is for a worst case, full frame resolution 120FPS. VOXL2 and the M0186 module provide the appropriate voltages for the IMX664 sensor to function properly.
Note that the power consumption of the whole system will not only depend on the camera resolution, fps, it will also depend on what you are doing with the images in VOXL2 (since VOXL2 will also consume power processing the images).
Hopefully this helps.
Alex
Hi @Aaky ,
I looked at the log using our customized version of flight-review (https://github.com/modalai/px4-flight-review), which you can run locally on your linux machine (the custom version of flight-review provides additional plots related to ESC and some other fields).
The RPM tracking looks good - tight tracking and not a lot of noise in commands (meaning IMU is well isolated, there are no significant vibrations or esc-induced oscillations).
ESC temps are ok (although this is a pretty short test!)
Power
The total battery current seems to be around 35A, meaning 8-9A per motor, which is still a very comfortable load for this ESC, as long as you can keep the ESC temperature not exceeding 100C (it should still run OK at 125C and higher, but that's definitely not recommended, and if you have to do that for short bursts, it may be ok). Unless you are trying to push the performance to the limit somehow, stay below 90-100C for the ESC temps. You can also significantly help with ESC cooling by adding a heat spreader to significantly increase the thermal mass of the ESC (which is very low, since the board is so tiny). Adding a heat spreader will make the cooling more efficient.
You should double check your PX4 params for min and max rpm to match what you have in the ESC params, since at the end it seems that PX4 is sending a low RPM that is not achievable by the ESC:
Since we are talking about ESC temps, you can actually set up a parameter to send a warning or critical message (which you should see in QGC) for different ESC temperature thresholds : https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/actuators/voxl_esc/voxl_esc_params.c#L249. Just for full disclosure, we don't test this PX4 feature frequently, but my understanding is that if you hit the warning threshold, QGC should show a warning and CRITICAL limit may actually cause a behavior change in PX4, I am not sure. The ESC driver in PX4 just sends out a warning message, but how it is handled is up to PX4.
Honestly I don't really see any issues with this setup, even though it is heavier than I would recommend for this ESC. I would suggest that you slowly build up confidence in this setup and start flying a bit more aggressively and checking the log for the metrics i mentioned in this post and checking ESC temps.
Alex
Hello, @HsinSWT ,
I am assuming your are using a 12V AC/DC adapter, which is higher voltage than the 2S battery used with Starling 2. Using 12V bench testing is OK, so that should not be an issue.
The ESC should already have the correct parameters loaded for the Starling 2 Motors and the correct battery voltage (2S). Inability to start at the nominal voltage, but success when using 12V is likely a symptom of a motor damage. Even though the ESC does have voltage compensation, it is limited (on purpose, for safety) and if you apply higher voltage, like 12V instead of 7-8V, the ESC will actually output higher power during the spin-up phase.
Also please make sure you are using the latest ESC firmware, there are a lot of tips here : https://docs.modalai.com/voxl-escs/faq/
Once you start using voxl-esc tools, you can also spin one motor at a time (or all 4 at a time) and get real-time RPM feedback. You could use your 12V supply and spin the motors at 10% power and see what RPMs they actually spin at. A faulty motor would spin slower. Please be careful while testing, since the drone could fly up if you send a wrong command, you could also test without propellers, the motor issue should be observable in unloaded motor RPMs as well.
Another typical issue with motors not spinning up is damage of motor windings due to mounting screws going into the windings (which could happen if the landing gear is removed, but the same screws are used to attach the motors). I am not saying this is the case here, but worth inspecting the motor windings on the under side, right where the motor mounting screws could make contact with the windings if the screws were too long.
If you do have a milli-ohm meter accessible to you, you could actually measure the motor winding resistance (while the drone is powered off, but motors can remain soldered to the ESC). You can compare the milli-ohm readings from working motors vs non-working (check all phases pair-wise).
The rust on the inductor is only cosmetic. We are aware of this "issue", but it's really not an issue (rust on a iron case of an inductor - the case does not really affect the inductor itself).
Hopefully this helps!
Alex
@colombe-ai , when you flash a voxl2 SDK, there should be an option to set it up from scratch. did you try it?
https://docs.modalai.com/voxl-suite/
Alex
Please try the following after a fresh reboot:
voxl-inspect-cam tracking_down tracking_front tracking_rear tof_ir hires_small_color
Running voxl-inspect-cam -a can break the camera server because there are too many output streams to process. This used to be a good option in the past for a quick test, but with 5 cameras and ~25 streams this is becoming too heavy. In normal use cases, only one stream is used from each camera.
If you are just getting started, I would suggest updating your drone to at least SDK 1.5 or even 1.6, however you should still be able to get camera streams displayed in voxl-portal or using the limited voxl-inspect-cam command.
If you still cannot get this to work, please do the following to stop the background service for voxl-camera-server and run in in the foreground and past the output:
#stop the background service (it will restart after reboot)
systemctl stop voxl-camera-server
#run camera server in foreground
voxl-camera-server
Alex
Hello @taiwohazeez,
it seems your calibration pattern is significantly warped. It needs to be as straight as possible.
I personally like to perform calibration by displaying a pattern on an LCD screen (flat), which more or less guarantees it being straight. For a monocular calibration, the size of the box does not make any difference (no scale is recovered from the calibration). If you use that approach, then you actually have to move the camera as opposed to moving the pattern, unless you want to move the screen, which actually would be possible on a laptop. Watch out for reflections from screen and also sometimes setting manual exposure also helps (i won't go into detail how to do that here).
You could take your calibration sheet and glue it to a rigid flat surface, but even that can be tricky, since paper glue can cause wrinkles on paper, but those should not be as bad as the deformation seen in your screen shot.
Alex
@Rowan-Dempster , we will go ahead and integrate the limited 32-bit ION buffer support into libmodal-pipe. Did you make any changes to my latest branch from a few days ago? If so, I can take whatever changes you have and do the final integration. If you have not made any changes (and don't have any suggestions), I can just finish it up from here.
Thanks again for your help!
Alex
Hi @Aaky ,
The documentation for the mini ESC states that we recommend using this ESC for drones 750g or less. It seems your UAV weight is around 1800g.
https://docs.modalai.com/voxl-mini-esc-datasheet/
I am concerned that the ESC may overheat (even though sustained current capacity may still be ok). Also, for larger motor like 2206, you may need to add a bypass capacitor to the ESC power ensure stable performance.
Have you performed tests of sustained hover thrust to see what the ESC temperature is like after several minutes of continuous "hover" thrust?
Alex
In order to debug the PX4 modules that run on the DSP side of VOXL, you should run voxl-px4 in interactive mode, such as:
systemctl stop voxl-px4voxl-px4 -dThen you should be able to run qshell vectornav ... command and see its output. If you just run px4-qshell from command line, the prints from the dsp do not propagate back to the user.
Another alternative is to use (sudo) mini-dm (on your linux host that is connected to VOXL2 via ADB) which allows you to see low level messages from the dsp (mini-dm is a tool that is available in Hexagon SDK).
Now, regarding integration of a new driver with the DSP, I am assuming you were able to enable the module to build for the DSP, but it's running correctly because the device is not recognized. This is because in order to use the DSP uart in PX4, you need to call voxl-specific functions to open, read, write on the DSP port. Please take a look how this integration is done in the gps driver : https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/gps/gps.cpp , specifically looking at #ifdef __PX4_QURT and similar conditionals.
Alex
@Rowan-Dempster , sure, that would be helpful. I don't see any issues with merging that in, since if we do it right, it will not affect 64 bit build at all and will only add limited support for 32 bit -- limited, meaning, for clients only, cannot allocate new buffers.
i will check with the team today to make sure we are all good, so perhaps you should wait for that.
Alex
@Rowan-Dempster , nice! I am glad it worked.
i think the issue here is that we have changed the struct definition (of the ion buffer type), which should not be changed for the 64-bit library. So until we hopefully mainline this, you can just manually copy the 32-bit libmodal-pipe.so into /usr/lib/ (while the original 64-bit version will remain in /usr/lib64). Did you try that?
For mainlining this, i think we will need to do a #ifdef 32 bit and insert the allignment dummy bytes as well as bypassing the ion allocation functions, which require libgbm.so.. You could try that change as well, just need to figure out how to detect 64 vs 32 bit in the few source files that we changed.
Alex
@leandro , documentation for M0187 has been updated to include the 3D CAD file :
https://docs.modalai.com/M0187/#3d-drawings
Alex