Hello Rolando,

It will not be possible to fully use four ov7251 cameras at the same time due to i2c address conflict. the downward camera can coexist with the stereo pair because

• one of the stereo cameras is actually on a different i2c bus
• ov7251 camera has two i2c addresses, so with some software configuration it works. However, having 3 ov7251 cameras on i2c bus cannot be done without a conflict.

In a condition of i2c conflict between cameras, what will happen is..

• system will be able to detect each camera at boot time because probing happens while other cameras are powered off
• you should be able to fully use the conflicting cameras one at a time (not concurrently)
• if you use the conflicting cameras concurrently, commands sent to one camera will go out to both cameras, for example exposure and gain control. nothing will physically break, but this is currently not a supported use case.
• there will also be a short glitch after you started the first conflicting camera and when you are starting the second conflicting camera, since the first one will also get re-initialized with the commands intended for the second camera

in your case, the ov7251 plugged into J2 was not detected because the camera configuration xml file is not configured to query this camera on J2 connector. If you wanted to enable it, you need to back up and edit the following file : /system/etc/camera/camera_config.xml and add an entry that looks like below (then reboot). The slave address 0xC0 is one of the two possible slave addresses for this camera. The other one is 0xE0 and is already used by the camera plugged into J4 (downward facing).

So are you using one of the stereo cameras + stereo flex + extension cable? if you are using the stereo flex with one camera, make sure to use the left port on the flex because the right port is connected to the secondary i2c bus, accessible only in stereo configuration. Also, multiple stereo pairs are not supported on VOXL and stereo can only be used in J3.

With the below config addition, you should be able to detect all 4 ov7251 cameras and successfully use the following configurations without confilicts:

• J2 + J4 (hires slot + tracking slot)
• J3 + J4 (stereo slot + tracking slot)
• if you want to use J2 + J3 (hires + tracking slot), change the I2C id to 0xE0, but then it's the same thing as current stereo + tracking.

Now, in this configuration you should also be able to run all 4 cameras together but depending on the i2c ID of the camera in slot 0, it will conflict either with left stereo or tracking camera. I would not mess with stereo, so you could set i2c id of slot 0 to the same as in slot 2 (hires and tracking). then there is is still an issue of exposure/gain controls between the two cameras fighting with each other (both cameras will receive both exposure/gain updates).

In order to prevent two cameras from fighting exposure/gain settings the only way to do it is to prevent one of the camera drivers from sending out exposure/gain updates at all. Then both cameras will have the same exposure/gain computed based on one camera's image. This would require a little bit of work on the camera driver side but it's possible (though not supported now).

Anyway, this is just a long explanation of what you could try and what you will see.

<!-- ov7251 tracking camera in camera slot 0 -->
  <CameraModuleConfig>
    <CameraId>0</CameraId>
    <SensorName>ov7251</SensorName>
    <SensorSlaveAddress>0xC0</SensorSlaveAddress>
    <ChromatixName>ov7251_chromatix</ChromatixName>
    <ModesSupported>1</ModesSupported>
    <Position>FRONT</Position>
    <MountAngle>360</MountAngle>
    <CSIInfo>
      <CSIDCore>0</CSIDCore>
      <LaneMask>0x1F</LaneMask>
      <LaneAssign>0x4320</LaneAssign>
      <ComboMode>0</ComboMode>
    </CSIInfo>
    <LensInfo>
      <FocalLength>4.73</FocalLength>
      <FNumber>2.2</FNumber>
      <TotalFocusDistance>1.9</TotalFocusDistance>
      <HorizontalViewAngle>64.1</HorizontalViewAngle>
      <VerticalViewAngle>51.6</VerticalViewAngle>
      <MinFocusDistance>0.1</MinFocusDistance>
    </LensInfo>
  </CameraModuleConfig>

Hi

If you are looking for more low level functionality and a bit easier to experiment with, you may want to check out https://gitlab.com/voxl-public/utilities/voxl-rtsp/-/tree/dev . This tool is good for testing or running simple scenarios. This tool accepts some commands (like exposure control) via command line, so you could add a simple feature to save an image upon a command line input. Please see README to see how the exposure control input works and code for how it's implemented.

Please make sure that voxl-camera-server is disabled when you run voxl-rtsp.

If you still would like to go through the voxl-camera-server approach, we may need some more input from respective devs :).

I hope this helps..

Alex

The ipk is available here now : http://voxl-packages.modalai.com/stable/voxl-hal3-tof-cam-ros_0.0.5.ipk - you should be able to use the launch file to choose between two modes (5=short range and 9=long range) and fps, which are listed in the launch file.

It looks like your machine does not have QEMU support or is missing ARM support on your host machine. Please try instructions here : https://www.stereolabs.com/docs/docker/building-arm-container-on-x86/ (which also show you how to run ARM64 docker images on x86)

.. or if you wanted to continue using voxl-camera-server for 4K, just modify the server to save yuv frames on-demand and convert to jpeg later, as we discussed above..

Hi Ryan,

Does the micrortps agent need to open a standard UART port, such as /dev/ttySx or /dev/ttyUSBx or similar? how hard is it to extend the micrortps client to use libvoxl_io functionality to access the serial port via libvoxl_io instead of standard serial port libraries? You would need to use this header https://gitlab.com/voxl-public/core-libs/libvoxl_io/-/blob/master/lib/include/voxl_io.h and link against libvoxl_io.

If changing micrortps code is not an option, then some sort of bridge could work. I have done similar things before using pseudo terminals (pty/tty pairs). Basically the bridge could be the master and would read/write using ptyXY and micrortps would be the client and read/write using ttyXY. However, i don't think pseudo terminals are available on VOXL.

https://stackoverflow.com/questions/52187/virtual-serial-port-for-linux this discusses the pseudo terminal as well another solution using socat. Now, socat is not available on VOXL either, but if you use docker, it can be installed in a small container using apt-get install socat.

Let me check if we can easily add the socat and pseudo terminals to the VOXL system image..

It seems perhaps the most robust solution (for now) would be extending micrortps to work with libvolx_io serial ports..

Alex

I double checked with other devs on the team and the jpeg snapshot feature in voxl-camera-server is still in development. I don't have a good ETA for the feature.

However, perhaps we can go back to evaluating voxl-rtsp for your application. If you disable hires camera in voxl-camera-server, you should be able to use voxl-rtsp with hires camera after voxl-camera-server has started for other cameras.

voxl-rtsp supports outputting jpegs. You can first confirm that you can access hires camera jpegs with voxl-rtsp (I don't think it can do 4K30 jpegs, but lower resolution/frame rate should work). That should work and then you could add an input to trigger voxl-rtsp to actually save a jpeg upon request (instead of every frame). This can be done similarly how exposure/gain commands are accepted by voxl-rtsp via a named pipe.

Hopefully this can work for you..

I am not sure how to resolve the authentication issue, but you can always use docker save myimage:latest | gzip > myimage_latest.tar.gz to a tar file, then docker load on another machine and push to docker hub.

Also, by the way, you can build your docker image for VOXL on a regular linux machine. Qemu allows you to emulate arm and arm64 architectures and Docker supports this. This is how the voxl-emulator runs on x86-64: So, basically you can build your docker image on a x86-64 host and then push it to docker hub or copy directly to VOXL.

I know that does not answer your question, but hopefully there is a workaround here..

Alex

Hello Matthew,

When you execute voxl-gpio write, it configures the desired pin to OUTPUT mode and sets the desired state (0=low or 1=high). When you execute voxl-gpio read, the pin is configured as INPUT with a pull-up, so any previous pin state is no longer applicable. If nothing is connected to the pin while it is configured as INPUT, it will read 1 due to the pull-up.

If you would like to test the pin read and write functionality, you could set up a loop back connection, where you connect two pins together and you write one pin and read another.

I hope this helps

Alex

You can try docker save myimage:latest | gzip > <path_to_sd_card>/myimage_latest.tar.gz . <path_to_sd_card> should be /mnt/sdcard.

Note that SD card will be quite a bit slower than built-in EMMC, you might want to do some testing to find a fast and reliable SD card.

From personal experience the following SD cards have worked well and fast:

• Lexar Professional 1066x
• Kingston 64GB microSDXC Canvas Go Plus

However there are plenty of SD cards to choose from, you may want to run some SD card tests before you use it for something important. There are some fake SD cards out there which result in corrupt data.

Also, if you wanted Docker to use SD card for storing all images, check this article : https://docs.modalai.com/docker-on-voxl/#move-docker-image-from-data-to-mntsdcard

Hello Swaroop,

The ModalAi ESC can support most common motors. The ESC is rated for 2-4S battery voltage. The current rating is 15-20A continuous (per motor), depending on air cooling. What motors / propellers are you considering using with ModalAi ESC? We have some tools and calibration procedure for adjusting ESC parameters for new motors : https://gitlab.com/voxl-public/flight-core-px4/voxl-esc/-/blob/master/tools/calibration.md

Regarding support of 8 motors, the ModailAi ESC has hardware support for using two 4-in-1 ESCs on a single UART connection (8 ESC channels with IDs 0-7). However, our PX4 ESC driver does not currently support more than 4 motors.

Alex

Also can you please try voxl-esc-spin.py --power 0. -- this will not spin but get the feedback. I am curious if temperature will rise. it seems like it will, since in your first test the temperature differential was already high by the time you started the script (meaning it heated up since you applied power, before spinning).

In general, while spinning at low power, the ESC MCU temps should be around 40deg C and pretty even. ID3 seems to be heating up and heat is spreading to ID2 (next to it) and other IDs that are farther and more insulated in terms of heat transfer. Please inspect the ESC for any damage or loose solder or loose components.

@Chad-Sweet , this is using voxl-esc python tools, the parsing should be correct. Indeed, this is odd.

@hmlow

When you just plug ESC into 8V power (power supply), can you please look at idle current draw? at 8.00V with no motors spinning, the current draw should be 30-40mA. if you see higher current draw, this probably means something is wrong with one of the ESC channels.

Also, can you briefly turn on the ESC (enough to heat up to 50C for ID3), then turn the power off and feel with your finger if it is indeed hot compared to others. Please don't touch the ESC if the reported temperature is higher than 50C.

I have never seen the temperature measurement being incorrect, so I suspect that there is some issue with the board. You can see that in steady state, the ESC ID3 is spinning 100rpm slower than others which are within 10-20rpm, so that is a sign of an issue with ID3.

Alex

If you are artificially limiting the motor RPM to 75% power, then it should always be achievable, though you should test. Whatever that RPM is, check at lowest battery voltage and make sure the ESC can still achieve that RPM (most likely power will be close to 90%+). In that case, you can specify same max rpm limits in ESC and PX4.

I believe PX4 will scale the thrust to be between min and max rpm, so full throttle should try to max out the RPM (with some margin for control) but the hover throttle param is a good question, probably better to ask @modaltb , since I am not an expert in that. or @James-Strawson

Yes, the ESC calibration using QGC is not needed, but you do need to run the ESC calibration using voxl-esc tools. Note that using voxl-esc tools requires connecting the ESC UART directly to a linux or mac computer in order to communicate with the ESC.

The PX4 min/max rpm should be set according to the actual min/max values of the motor/propeller with modalai ESC. Note that for min RPM, the ESC may have a lower setting for min RPM than you would want to use in PX4. Dropping the RPM too low in flight could cause some instability in PX4 attitude controller, so you don't always want to go to the absolute minimum. When you perform the ESC / motor calibration, note the RPM results from applying 15% power and that may be a good one to use as minimum RPM (just a rule of thumb..). For maximum RPM px4 param you can put the maximum RPM achievable at nominal battery voltage. Note that maximum RPM is a function of battery voltage, and if you tell PX4 the maximum RPM at full battery voltage, then PX4 will incorrectly assume that that max RPM is achievable at lower voltages too. To be conservative, you can put the max rpm at nominal or lowest battery voltage you would use. The maximum RPM vs battery voltage is actually something we are looking at right now how to properly handle in PX4.

When using RPM control, the mapping between thrust and RPM is usually an almost perfect quadratic, so you should probably use THR_MDL_FAC = 1 to make it quadratic. However, let me double check that last point.. The value of this parameter should not change when you change motor / propeller, since thrust is almost always a pure quadratic vs rpm.

Hello,

Currently the documentation for basic ESC calibration is here : https://gitlab.com/voxl-public/flight-core-px4/voxl-esc/-/blob/master/tools/calibration.md and most parameters are briefly documented in the XML files as well. However, not everything is clear, as you pointed out. We will update the documentation soon with more information.

In short, the RPM controller on the ESC is in the following form:

power_applied = feed_forward_power + kp * proportional_error + ki * integral_error

• feed_forward_power is calculated from the quadratic curve a0,a1,a2 parameters you mentioned. Those parameters are obtained by running the esc calibration script. This term is used by ESC to apply required power in order to achieved steady-state desired RPM
• kp and ki are the proportional and integral gains
• proportional error = rpm_desired - rpm_current (calculated by the ESC), similar for integral error
• max_rpm delta is the cap on RPM error that is used for feed forward term, proportional term and integral term calculation
• max_kpe and max_kie are the maximum proportional and integral power terms (kpproportional_error and kiintegral_error). This cap can overlap with max_rpm_delta, I will explain in more detail separately
• In general, you want to start off tuning by setting kp and ki to zero and just calibrate the feed forward term. After this is done, the ESC should track RPM pretty well even with varying battery voltage (within +/-2V within nominal voltage as defined in params). The response to RPM changes would be very soft, similar to traditional off-the-shelf ESCs. Then you can set non-zero kp and observe faster response. This part is highly dependent on the system that you have (whole drone) because if the rpm commands you feed into ESC are noisy, this noise will be amplified by high kp in the RPM controller and can feed back into creating even more vibration. In general, you want to have non-zero kp but not too high so that the controller is stable with clean input (no noise) but also does not respond to the high-frequency noise fed with the rpm commands (the original high frequency noise can be coming from propeller vibration being picked up by the gyro)
• in general setting kp and ki to zero will achieve good results and will still be better than off-the-shelf ESCs because RPM tracking is accurate and consistent across battery voltage changes.

Please let me know what other questions you may have and I will try to incorporate in a more official write-up.

Alex

For standard motors using DShot, I believe a standard mixer is used. Perhaps this page will be useful : https://docs.px4.io/v1.12/en/concept/mixing.html#mixer-loading . You should be able to use a debug console to check which mixer is being used? Maybe @modaltb knows?

Negative command typically does mean the command in opposite direction. negative actuator_controls simply means the control is in the opposite direction.

actuator_controls is an array of 4 normalized (to -1..1) values (pitch,roll,yaw,thrust). actuator_outputs are outputs that are coming from the mixer. The mixer converts pitch,rol,yaw,thrust to four motor commands. The units of the motor commands are dependent on where they are sent to (PWM driver or whatever).

You can see some more info here : https://discuss.px4.io/t/how-mixer-work/3886/5

Also, motor direction can be sometimes controlled in software (as well as switching motor wiring). It depends on implementation of the ESC. Sometimes it is easier to wire all motors to ESCs the same way (without switching wires) and then use the direction in software in order to control the spin direction.

It seems like Dshot is used if signals around 1us are observed. Regular PWM would have been 1000-2000us range!

Hello,

Are you asking about ModalAI ESC? You can find information at https://docs.modalai.com/modal-escs/ and https://docs.modalai.com/modal-esc-v2-manual/. Please see information about V2 (V1 is obsolete). To answer your question about communication, the ModalAI ESC accepts control input via UART. The interface is implemented in PX4, you can find more information here https://docs.modalai.com/modal-esc-px4-user-guide/ and https://github.com/modalai/px4-firmware/tree/modalai-1.12-dev/src/drivers/uart_esc/modalai_esc.

Actuator Controls should be available to log via PX4 which would the the commanded RPM sent out the motors.

What Drone platform are you using and can you confirm that you have the ModalAi ESC V2?

Please review the documentation and let us know if you have other questions.

Alex