When you were looking for cameras in voxl-portal - was the voxl-camera-server actually running? you need to make sure that it's running (either as a background service, which normally starts up using systemd right after boot, or manually if you are running the camera server in a terminal in the foreground).
It does look like the 3 AR0144 and 1 IMX412 were detected, so lets first make sure you can view those corresponding streams first.
Alex
Do you need to be able to control the servo from PX4 or it would be acceptable to have an API you could use on the CPU / Linux on VOXL2 ?
Alex
@Jetson-Nano , 60C is not an issue for embedded devices (throttling limit is around 95C, at which point the CPU will start reducing frequency to avoid overheating).
However, you mention that the temperature can reach 90C. Please note that the camera server itself most likely is not the main cause of the CPU temperature, but the consumers of the image frames may be using significant CPU.
You should identify the main causes of temperature rise by looking at output of top to see rough cpu usage of each process, but also try disabling mapper or openvins or hires image processing (if any).
Also, without any cooling, it is not a surprise that VOXL2 could overheat if its cpu / gpu load is very high. The SoC cannot run without cooling at full power. Airflow during flight usually provides significant cooling and you can manage the system load when not in flight or add cooling for stationary use cases (lack of air flow from propellers),
Alex
The M0159 has been replaced by M0202, which has identical functionality but slightly smaller outline to fit the Hadron better. M0202 will be officially available shortly.
Here are the CAD files:
M0181
M0202
Alex
@Hector-Gutierrez , since you have a standard camera configuration, you should run the following command to configure your VOXL2 for C27:
voxl-configure-cameras 27
This command should copy the correct sensormodule files to /usr/lib/camera and set up a default config in /etc/modalai/voxl-camera-server.conf for this camera arrangement.
Alex
@george-kollamkulam That port is internally connected to the 5V coming from the main VOXL2 power (which is technically 5V 6A). Obviously you would be limited by the connector pins, which are rated around 1A max continuous. Also, drawing too much from this pin, can bring down the whole VOXL2 (if that 5V output on J19 is shorted to GND, for example).
@george-kollamkulam , is there any reason why you cannot use 5V from J19 on VOXL2?
Enabling 5.0V output on the Mini ESC would need a firmware update, so if you can stay closer to the standard configuration, it will be easier to maintain (for you and for us as well).
Alex
@Jetson-Nano , please confirm the ESC is working by using a usb to serial connection directly to the esc and voxl-esc Python tools on a Linux PC or VM.
You can run simple commands to detect the esc and perform spin tests if needed, this is all documented.
https://docs.modalai.com/voxl-escs/faq/
If the esc is ok, then you will need to double check the FC v2 setup.
Alex
@Jetson-Nano , I am not the best person to answer questions regarding open-vins. Let me double check with other team members.
Also, can you please clarify your question "which is the preferred imu for the extrinsic when I am using voxl 2 + fc v2 + M1073" -- what do you mean which IMU? VOXL2 has two IMUs - one is used by PX4 for flight (accessed from DSP) and the second IMU is connected to the CPU. The latter is used for all VIO processing.
Alex
Yes we do sell those parts. Please contact us via online form. https://www.modalai.com/pages/contact-us
The part number you will need is M10000524
Alex
@smiley , we made a small adjustment to the M0159 board to make it fit into the Hadron better (board outline). That was a small board re-spin (same functionality). Checking on the status..
Alex
Hello, @Stefan-Amundarain ,
Let's try to narrow this down. Can you reproduce the issue without flying?
When the issue occurs, does the camera server restart completely, or you only lose hires camera feed. I suggest running the test on the bench with voxl-camera-server running in foreground so you can easily see what's happening in real time.
Please try to reproduce on the bench all 3 cameras (hires, tracking, TOF) working with your Ark Flow board working as well, then you can just move the platform by hand, if needed, to cause the camera failure and investigate what:
We can go from there.
Also, can you please provide details how the ARK Flow is actually connected to VOXL2 (electrically) and also confirm that the issue does not happen at all without ARK Flow plugged in?
Also, using voxl-portal should not cause the camera server or the portal backend to get bogged down if your image is reasonable size (not full 4k image), but a small 720p is just fine.
You could view the 3 camera streams thru voxl portal during the test or just have the voxl-inspect-cam tool running and inspecting just the streams that you want (you can provide the streams to inspect as arguments to the tool, such as voxl-inspect-cam hires tracking_down tof_depth, etc. Either voxl-portal or voxl-inspect-cam should properly use the camera pipeline with all camera streaming, so that you can catch the fault.
Alex
@shivam-rana , if you have a few wifi adapters which are currently not detected by VOXL2, if you plug into a standard Linux machine and if they are detected, you should check with chipset is used on those adapters and we can see if that's available (but not currently compiled) option for the VOXL2 kernel. We can add some documentation to help you build your own test kernel with enabled module and see if that works.
The VOXL2 kernel build guide is here : https://docs.modalai.com/voxl2-kernel-build-guide/ but it does not explicitly state how to make modifications to enable additional components. For those folks who have built kernels before, this may be easy to do, but for the first time it could be very difficult to do the right thing, but the change could be very small (one line). So we can see if it's possible to enable the driver that you need, but there would be no guarantees about functionality, since it would be untested (by us).
Alex
The primary causes of ESC not being detected by the FC (aside from hardware / wiring issues) is using incorrect UART port or incorrect baud rate. So you should make sure the ESC is running the latest firmware, double check the params that you want to use on the ESC (for your motor / prop) and you can also set the ESC baud rate in the ESC params. You should set up your ESC (using voxl-esc tools) before plugging it into your FC, so that you know exactly what your ESC is set up to do and then you just need to match your PX4 params to what you set in the ESC (baud rate, rpm limits, and use correct UART port).
Alex
@ysc ,
I am sorry, the camera ID vs slot ID may be a bit confusing when you first start playing with camera configurations.
In your case you only have one camera plugged into Camera Hardware Slot 2, (so you use the sensormodule with index 2), but once the cameras are detected by the system, they are assigned with camera ids which start with 0. So in your configuration file, you need to set camera_id to 0 and it should be called camera_id, not camId. -- you actually have both of those, so please remove camId and camId2 entries, and just set camera_id to 0.
You also have some duplicate (incorrectly named) parameters such as pre_width and pre_height -- the correct ones are preview_width and preview_height, which are also there. I think you probably got those from the information that camera server prints out when it starts, which actually does not use correct parameter names, such as camId and pre_width, etc... We should fix that..
Alex
@victochen , sounds good, feel free to ask more questions.
The 62A current draw (1.3KW!) for one motor is probably OK for motor to sustain for a short period of time, but my guess is that the motor itself would overheat pretty quickly. Unfortunately I could not find any test data about this particular motor, which is unusual.
If we knew the propeller's thrust vs rpm, you could estimate your hover power draw right from this calibration plot (knowing the weight of your drone).
In any case, after you do a short first flight, you should analyse the log data, if you are using PX4, you can use flight-review to view the PX4 logs. Additionally, we maintain our own version of the flight review analysis tool, which includes some VOXL2 specific updates including all the ESC data (commanded and actual rpms, etc). You can find the fork of flight-review and instructions how to use it locally on your machine here : https://github.com/modalai/px4-flight-review
The total current (as the FPV ESC does not measure the individual motor current), will be reported in the battery_status message in the PX4 log and is viewable using flight-review (there is a section for battery voltage / current).
Also just to give you an idea of M0138 performance (and you can reproduce these tests), here is a test of 4 2207 motors with 5x4x3 props, 6S battery, spinning at 25K RPM (in closed loop RPM control mode) with full airflow cooling of the ESC. You can see the the ESC temp(s) go up pretty quickly, but this particular test was pretty short, i think i did not want to cook the motors, since ESC temps were still fine. The ESC is pulling around 125-130A total in this test and the performance is stable. You will notice two temperature bands in the 4 temperature measurements because these temps are reported from different locations (the higher temps are from the MCU's built-in temp sensors, which run a bit hotter due to MCU power consumption) and the lower two temperature measurements are from dedicated temperature sensors located next to the Mosfets (top and bottom of board).
voxl-esc tools provide the tools to perform this analysis on the bench pretty easily and find out how your propulsion system is stressed under different conditions. You can also get similar logs from flights / px4-logs for real use case analysis.
Finally, our ESC driver in px4 supports warning and critical temperature limits, which will send out warnings to QGC if those limits are reached. The limits are disabled by default, but you can enable them with params: https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/actuators/voxl_esc/voxl_esc_params.c#L238 . However, i am not 100% sure of the behavior of PX4 if ESC reports critical temps, it could enter some failsafe mode, or something like that - you should double check that, if you enable these warnings.
Alex
@shivam-rana , based on the following kernel recipe, which we have added for VOXL2, https://gitlab.com/voxl-public/system-image-build/meta-voxl2/-/tree/qrb5165-ubun1.0-14.1a/recipes-kernel?ref_type=heads, these wifi chipsets should be enabled.
Please note that these are the drivers that we are added on top of what was available in the default kernel. Also note that not all the available drivers in the kernel are actually built.
All the kernel modules are built into the kernel, so there is no easy way to tell which ones are available by just looking at the files on VOXL2.
I just looked at a voxl2 kernel build, looking at the following directory : lu.um.1.2.1/apps_proc/build-qti-distro-ubuntu-fullstack-perf/tmp-glibc/work/m0054-oe-linux/linux-msm/4.19-r0/build/drivers/net
I see the following:
more modules.builtin
kernel/drivers/net/dummy.ko
kernel/drivers/net/mii.ko
kernel/drivers/net/tun.ko
kernel/drivers/net/veth.ko
kernel/drivers/net/bonding/bonding.ko
kernel/drivers/net/ethernet/cavium/common/cavium_ptp.ko
kernel/drivers/net/ethernet/marvell/sky2.ko
kernel/drivers/net/ethernet/qualcomm/rmnet/rmnet.ko
kernel/drivers/net/ethernet/smsc/smsc911x.ko
kernel/drivers/net/phy/libphy.ko
kernel/drivers/net/phy/fixed_phy.ko
kernel/drivers/net/phy/microchip.ko
kernel/drivers/net/ppp/ppp_generic.ko
kernel/drivers/net/ppp/bsd_comp.ko
kernel/drivers/net/ppp/ppp_deflate.ko
kernel/drivers/net/ppp/ppp_mppe.ko
kernel/drivers/net/ppp/pppox.ko
kernel/drivers/net/ppp/pppox.ko
kernel/drivers/net/ppp/pptp.ko
kernel/drivers/net/slip/slhc.ko
kernel/drivers/net/usb/r8152.ko
kernel/drivers/net/usb/lan78xx.ko
kernel/drivers/net/usb/asix.ko
kernel/drivers/net/usb/ax88179_178a.ko
kernel/drivers/net/usb/cdc_ether.ko
kernel/drivers/net/usb/cdc_eem.ko
kernel/drivers/net/usb/smsc75xx.ko
kernel/drivers/net/usb/smsc95xx.ko
kernel/drivers/net/usb/net1080.ko
kernel/drivers/net/usb/rndis_host.ko
kernel/drivers/net/usb/cdc_subset.ko
kernel/drivers/net/usb/zaurus.ko
kernel/drivers/net/usb/usbnet.ko
kernel/drivers/net/usb/sierra_net.ko
kernel/drivers/net/usb/cdc_ncm.ko
kernel/drivers/net/usb/qmi_wwan.ko
kernel/drivers/net/usb/cdc_mbim.ko
kernel/drivers/net/wireless/cnss_prealloc/cnss_prealloc.ko
I am double checking with the team whether this is the list of all the network drivers that are available in the current kernel that ships with voxl2. It does not look like there are any wireless drivers in that list.
I just did a quick test and plugged in an usb to ethernet adapter and checked dmesg:
[ 2.816050] usb 1-1: new high-speed USB device number 2 using xhci-hcd
[ 2.958614] usb 1-1: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 1.00
[ 2.958620] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2.958624] usb 1-1: Product: AX88179
[ 2.958626] usb 1-1: Manufacturer: ASIX Elec. Corp.
[ 2.958629] usb 1-1: SerialNumber: 008CAE4CD66BCC
[ 3.392879] ax88179_178a 1-1:1.0 eth0: register 'ax88179_178a' at usb-xhci-hcd.0.auto-1, ASIX AX88179 USB 3.0 Gigabit Ethernet, 8c:ae:4c:d6:6b:cc
The ax88179_178a driver is in the list above, so that kind of makes sense and it looks like it was enabled in the kernel using the following config entry : CONFIG_USB_NET_AX88179_178A=y. (I am just providing this information in case you or anyone else wants to actually build the kernel and enable more drivers).
It may be possible to enable other drivers, but you would need to know how to build the kernel yourself, and there may be issues with building drivers that are not currently enabled.
Alex
@victochen , your latest calibration curve looks good! 62A steady state at full power (single motor), not to mess with! 
If you are going to push the ESC hard, you should watch the ESC temps (reported in PX4 esc_status topic). Depending on your average current draw, you may need significant cooling of the ESC (the ESC may be thermally limited, not limited by current capacity). technically speaking if your ESC runs hotter than 120C, that is a red flag (the MCUs on ESC are technically rated for 125C, and will likely run fine at higher temps, but that is just not a good practice to run them this hot). I typically recommend keeping the ESC below 90C in steady-state for good practice. Personally, my preferred temps are much lower (60-70C max), but that is way below the rated specs and obviously depends on the application.
Also, did you calibration using the suggestions for the low-kv motors, or not? I would not consider 1000kV low, necessarily. Increasing the commutation advance per those instructions can reduce the efficiency (and heat up the motor a bit more).
Also, i am not sure if you have changed the RPM controller gains at all - i would suggest starting soft first, maybe even set kp and ki to 0. Setting the RPM controller feedback gains too high could create issues if you have IMU noise from vibration, so it's good to start off with less aggressive RPM control and then increase the gains as you gain more confidence (which will allow to do better attitude control of the drone with updated attitude controller gains). Starling 2 MAX ESC gains were pretty soft, so you could start with that as well.
When you update the PX4 params (assuming you are using PX4), make sure that you update the ESC RPM limits for the voxl_esc px4 driver.
Regarding running the script on VOXL2, i did not yet get a chance to try it, but it should work the same.. it was previously tested. I will test it out and will report back..
Alex
@victochen , i just did a quick test using the voxl-esc tools from the dev branch (latest) and the results look good (although this is a different motor/prop). My test was running on a Linux PC, not VOXL2. I am going to try running it on VOXL2, however, do you have ability to try the calibration on a linux PC? Initially, i would still limit the max power to like 60-70% until you can get the tool actually working properly. I am not sure what's going on. You should only see one set of green dots in the RPM vs Time plot (one set per transition). Like you see in my plot. In your plot, there are multiple groups of green dots at the same power / rpm level, which suggest the test script is not working as intended. The green dots represent the values at the end of the transition, which are used for the data analysis (to avoid the transients).
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/tree/dev/
@victochen , can you please tell me the exact calibration command you are running on voxl2?
From the following plot, i see an issue that looks like the clock is being stretched and the intervals between the calibration steps are getting longer and longer. I will double check this to make sure it still runs fine on my test setups.
Alex
