VOXL 2 IO - 8 PWM channels & Futaba (SBUS) Rx
-
I want to drive 5 motors and 2 servos from the VOXL 2 IO module.
I saw that the latest firmware only supports 4 PWM channels for now and am curious if the firmware development for this module is a high priority, or, rather, is the ModalAI team expecting to push out a new firmware to support 8 PWM channels soon? Soon being within April.
This is a necessary function for my platform.Additionally, I want to connect a Futaba receiver to the RC SBUS port on the VOXL 2 IO module at J3; however, the Futaba is a 5V system (power & signal) and its SBUS is inverted from the FrSky SBUS.
Is it currently necessary for me to step down and invert the signal before connecting the Futaba Rx to J3 of the VOXL 2 IO module? -
@konwersa , we have been beta testing updated firmware that enables 8 PWM channels and supports standard SBUS on J3. Please see my post here (scroll down to my post March 19). There are instructions how to install updated firmware to M0065 and use a new branch of PX4 that supports this. Several forum users have been testing this and we should have this officially released within several weeks.
J3 provides 5V output for the SBUS receiver and has level inverters for the signal. see more information in the data sheet https://docs.modalai.com/voxl2-io-datasheet/
This thread has additional discussion on this topic and also a pre-built .deb with px4 that supports the new feature : https://forum.modalai.com/topic/3265/additional-voxl-2-pwm-ouputs/ (link to px4 deb on March 28)
Alex
-
A Alex Kushleyev referenced this topic on
-
That's great! Thank you @Alex-Kushleyev
-
@Alex-Kushleyev , Are there any plans for the VOXL 2 IO Module to support DShot?
-
@konwersa , what are you expecting to gain by using dshot? It would help us if you can explain your use case. Thank you!
-
@Alex-Kushleyev , we like the ability to have controls and telemetry on 1-wire and, most importantly, it simplifies ESC calibration. We don't want our customers to deal with ESC calibration in the field.
-
@konwersa , have you considered using ModalAi escs? We use uart protocol which is more robust than dshot (it has been a standard for decades). Uart interface provides telemetry from each esc. Additionally, our ESC does closed loop RPM control for maximum performance. After a one time calibration using your motor and propeller, no other calibration is required, just load correct esc params to all ESCs.
We also provide tools to fine tune esc performance and plot the results for visual confirmation and you can run automated tests using python scripts.
-
@Alex-Kushleyev , we did consider using ModalAI's ESCs, but our configuration is now a lift-cruise (5 motors) and we will be using the APD 40F3.
-
@konwersa , thank you for clarifying, I understand.
The dshot support is not currently on our official release roadmap, but we have experimented with it using M0065.
To help me understand better your use case, a few more questions..
- in your application you would need 5 dshot outputs, correct?
- when you talk about ESC telemetry, are you referring to bi-directional dshot or the uart-based telemetry? (do you know the difference?)
- do you also need M0065 for RC input (SBUS or something else)?
Alex
-
@Alex-Kushleyev , I appreciate your effort to understand our needs.
I'm only vaguely familiar with dshot. To my knowledge, bi-directional dshot makes use of 1 wire for control & telemetry with 16-bit data packets for control (idk how big the telemetry packets are).
I am not sure of the difference between bi-directional dshot & uart-based telemetry aside from the fact that the uart telemetry uses a separate telemetry wire.
As of right now, we would need:
- 5 dshot outputs for the ESCs - bi-directional dshot would be ideal for wiring simplicity
- 2 PWM outputs to our servos (control surfaces)
- M0065 for RC input - Futaba SBUS
- I also want to use the spare (8th) "PWM" on the M0065 as a GPIO to control a low power mode for my GPS
I haven't dealt with the various ESC control & telemetry protocols yet. If you have any information to add to or correct my understanding, I would be happy to learn more.
Alex
-
Here is a good resource that describes dshot, telemetry and bi-directional dshot : https://brushlesswhoop.com/dshot-and-bidirectional-dshot/
Uart telemetry is the easiest from software point of view and would only need one wire on a typical 4-in-1 esc, but in your case you would need a extra wire from each esc.
Standard bi-directional dshot provides rpm feedback only (for rpm-based filtering of gyro data). There is also extended dshot telemetry which supposedly can provide voltage, current, esc temperature.
Can you please take a look at the article and clarify which telemetry data you would need from the esc?
I am not sure yet if receiving dshot response on single wire with dsjot commands is possible on m0065, we have not tried it. I would need to look into that.
-
Thank you for the resource! We certainly had some confusion regarding dshot, bi-directional dshot, and esc telemetry interfaces.
In the long term, we will need to obtain all of the available telemetry via the UART telemetry interface. The telemetry interface is something we will have to account for in a later hardware revision in a month or two.
We are developing a quick & dirty Rev 1 platform right now, so we will forgo the ESC telemetry & dshot for the time being.
On Rev 2 of our hardware, I will be looking to incorporate dshot control (5 channels) and the serial telemetry (5 channels). From the telemetry, we want RPM, voltage, current, temp - all the bells & whistles.
So, the topic of discussion now is less about telemetry (as I will have to create a design in Rev 2 to accomodate our telemetry needs) and more about the capabilities of the M0065 moving forward.
M0065 needs on J1 include
- dshot control x5
- pwm control x2
- gpio x1
I may also look into potentially repurposing J2
-
Thank you for clarifying. In my testing, I have confirmed the ESC telemetry (not dshot telemetry) by repurposing J2 for UART rx that received the telemetry data. So i would request the telemetry via DSHOT commands (for one ESC at a time so that uart packets from different ESCs do not collide) and receive the packet via uart on J2 and parse it. This exists in the experimental code.
For DSHOT output, we have implemented 4x dshot outputs so far, but up to 6 should be supported by hardware. I would need to double check that you could mix dshot and pwm, there could be a limitation due to shared hardware timer between different output pins.
As for GPIO on/off, i believe it is possible to use the existing PWM functionality to just make the pulse width equal to 100% so that the pin always stays high (just need to make sure there is no glitch) or 0% for the pin to always stay low. That would be nice so that there is no need for additional GPIO interface.
Please give me a few days to check a few things, mainly to make sure that we can do 5 dshot and 3x pwm (1 pwm used as gpio)
Alex
-
I'm glad that we were on the same page with repurposing J2 for the ESC telemetry! Using a PWM at 100% or 0% is a great idea to avoid reconfiguring the pins.
@Alex-Kushleyev said in VOXL 2 IO - 8 PWM channels & Futaba (SBUS) Rx:
Please give me a few days to check a few things, mainly to make sure that we can do 5 dshot and 3x pwm (1 pwm used as gpio)
Have you confirmed the status of mixing dshot & pwm as well as the possibility of 5 dshot channels?
Alex
-
@konwersa , I am sorry for not getting back to you sooner. DSHOT support in M0065 is still a possibility but I do not have a specific timeline for implementing this, also considering that you have a very specific use case, which would need a custom firmware because M0065 does not support arbitrary configuration of the 8 IO pins due to the fact that the hardware timers are shared between pins and only certain combinations are possible.
I did double check that the hardware can support 5x dshot, 2x pwm, and 1x gpio (but not 5x dshot and 3x pwm due to a timer conflict), but it would be a very specific pin assignment (which is not really a problem as long as you know what it is).
A much more common use case would be 4 dshot + 4 pwm, which would be much easier for us to support. This is what we have prototyped, but the feature has not marked for a release. If there is enough demand from the users, it would make the decision easier, otherwise it is hard to prioritize it..
If you have other options for your dshot application, please consider pursuing those, since I cannot give you a clear timeline for the feature you requested.
Alex