M0117 ESC rough control

Aaky

More details about my setup, I am trying to send S.BUS signals from my Transmitter via Doodle labs serial port and on UAV side, receiving the serial packets from Doodle labs modem and then feeding them into VOXL2 IO board. I do not have inverter for converting inverted UART to normal UART on Doodle labs with GCS side which I am planning to insert but will I need inverter for back converting normal UART to inverted UART on UAV side before feeding into VOXL2 IO or not is the question.

Alex Kushleyev

@Aaky, as the diagram shows, there is a hardware buffer/inverter present in voxl2_io board on the sbus input port.

J2 port (designated as spektrum input) on voxl2_io does not have the inverter and is currently unused. I could set up this port as non-inverted sbus input that will work just like the inverted one.

If you want to use the current sbus input port, you will need to invert the signal and also use parity bit in each byte (sbus standard)

Aaky

@Alex-Kushleyev Thanks for the inputs.
Can you set J2 as non inverted please? Can I use it directly with my non inverted Sbus packets then?

Alex Kushleyev

@Aaky , yes it should work with non-inverted uart. You would need to send the following uart format in order to be compatible with sbus : Even parity, 2 stop bits, 100,000 baud. Are you able to do that from your doodle labs device?

Alex Kushleyev

Also, if you are sending standard uart RC data from doodle labs, you could just feed that directly into voxl2 J18 or J19 and use standard px4 sbus rc driver. That may be the best option and you bypass voxl2_io for more flexibility.

Aaky

@Alex-Kushleyev Integrating on J18/J19 seems to be viable option to me. I will try the same and let you know.

Aaky

@Alex-Kushleyev One more query. Do you have experience with this, say I need to send S.BUS via UART, would only using a inverter circuit in between would work to send S.BUS via UART port of Doodle labs? Considering I set even parity and 2 stop bits on UART settings of Doodle modem.

Another query, Can SBUS RC driver on J18/J19 work other then 100000 baud rate? Like UART standard 115200?

Alex Kushleyev

@Aaky , I just checked, if you use VOXL2 J18 or J19, the UART ports on these connectors are connected to the DSP and it does not currently support baud rate 100,000.

So, if you wanted to send the data in SBUS format directly to VOXL2 J18, J19, the requirements would be:

use standard baud rate, such as 9600, 38400, 57600, 115200, 230400, 460800, 921600, 1000000, 2000000 (all of these are supported by the DSP). Additionally, non-standard supported baud rates are : 250,000, 420,000.
use 1N8 serial port frame type (1 stop bit, 8 data bits, no parity)
non-inverted (standard) signal levels (idle = high, 1 =high, 0 = low)

However, i just checked, there is no SBUS RC driver that is currently supported to run on the VOXL2 DSP. This is because the SBUS is typically inverted signal and it is not possible to handle that in VOXL2 directly.

If you are flexible and able to send the data in the format of Ghost RC or Spektrum, they are both supported directly on the DSP : https://github.com/modalai/px4-firmware/tree/voxl-dev/boards/modalai/voxl2-slpi/src/drivers and you can enable them using /etc/modalai/voxl-px4.conf and /usr/bin/voxl-px4-start (check both files for details)

Alex

Aaky

@Alex-Kushleyev Got it thanks for the information. So it seems unlikely for me to use J18/J19 for RC input since I dont have much flexibility to convert SBUS into Ghost RC or spektrum format right now.
Say I want to use J2 on VOXL2 IO for non-inverted SBUS packets as you mentioned earlier, is that readily possible or we have to do any changes in SW configuration/firmware of VOXL2 IO?

Alex Kushleyev

@Aaky , sure, I can look into it. Can you please check if your Doodle labs serial port can generate the UART frame format that SBUS uses:

100,000 bps
2 stop bits
1 parity bit

If we do not follow this format, it will not be a standard protocol and does not make sense for us to make this change for a specific use case.

Alex

Aaky

@Alex-Kushleyev I am checking with Doodle labs for this serial port settings. Actually baud rate isn't standard so I doubt 100000 would be supported. Apart from that parity and stop bits is fine. So if only standard baud rate support like 115200 is added might still work out for me.

Alex Kushleyev

@Aaky , i am thinking that perhaps the easiest thing to try would be the signal inverter like you originally proposed (between Doodle Labs and M0065 J3). Then there would be no firmware required. Ideally, the signal inverter should be symmetric (for better noise immunity). If you use the single transistor approach, you should put the inverter as close as possible to the receiving end of the signal, otherwise if the wire is long, the output of the inverter will pick up noise due to high impedance of the pull-up resistor (10K) when in "high" state.

But if you cannot output 100K baud rate, that would be a problem.

Alternatively, i think you should re-consider converting the SBUS packet in to GHST or Spektrum packet. If you share mode details how Doodle Labs device is getting the RC data (where is it coming from and in what format), I can make a suggestion how to do this. Then you can just use a standard baud rate and standard driver already supported in PX4 with no hardware changes.

I am hesitant to make changes in M0065 firmware to support your specific use case because maintaining that in the future will be an issue. So lets try to find a workaround.

Alex

Aaky

@Alex-Kushleyev Thanks for inputs Alex.

I am thinking now as follows.

My RC transmitter is smart android tablet with radio sticks inbuilt and has port to output SBUS data. I connected this SBUS data out and received it into Teensy 3.2 development board which is AVR microcontroller based small board.
Now that I have decoded successfully the sbus data into Teensy, I am transmitting this data from teensy into Doodle labs serial port with normal UART setup and 115200 baud rate. My whole intention behind this activity is to route my radio telemetry via Doodle labs modem as physical interface.
Now the doodle labs modem on GCS side will beam this serial data via UDP socket to UAV side modem and via UAV side Doodle labs modem I would get the normal UART SBUS packets out.

Now their are multiple solutions,

This normal UART SBUS data I can either send directly into VOXL2 IO board (if possible) via J2 port with agreed upon frame format?
I get another Teensy microcontroller which would receive normal UART data convert it into SBUS format and output the same to VOXL2 IO J3 port. I am not sure if Teensy can output inverted SBUS tough.

Note : Doodle cant decode 100000 baud rate packets and also inverted ones so direct SBUS packets into Doodle labs modem arent going to work for sure.

My main confusion is SBUS data is having multiple hops in between before it gets to PX4 and amount of latency which I would be introducing is something I dont know.

In solution 1, I am saving one more hop.
Solution 2 looks more clean.

Let me know your thoughts and any background experience.

Aaky

@Alex-Kushleyev Even I can consider converting Sbus into GHST/Spectrum packet on GCS side Teensy itself. Teensy is Arduino style board and if we have good direct libraries to do this it would be beneficial. Let me know if with Arduino style board this can be achieved as an alternative since Sbus packets are already decoded in Teensy and on UAV side I can output standard UART style packets as RC packets.

Alex Kushleyev

@Aaky ,

A few more questions:

can you change the uart configuration of your Android radio? For example, instead of inverted SBUS at 100K baud, transmit normal UART 8N1 at 115200. This would allow you to eliminate one Teensy on the transmitter side
are you able to change the type of data that is sent out from the Android radio? instead of SBUS, maybe another type of packet? (can you change the code running on that device)
are you planning to send any other data via this link from the Android radio to VOXL2? If you plan to send any other messages, then you will need to encapsulate the data in some packet structure, so that the receiving end will be able to differentiate them.

Alex

Aaky

@Alex-Kushleyev Alex I do not have any control over SBUS data been sent out of my android radio that's the reason I need a decoder in between Doodle and Android radio since Doodle can't decode the Sbus packets. Teensy does the job of decoding very well since there are Sbus library available for Arduino and can also out the Sbus channel data on its serial port comfortably. I have connected GCS side of things comfortably now and yet to see data onto Doodle labs modem now.

Customisation of packets is possible on Teensy microcontroller if library is available or if development is simple. Let me know your thoughts on the basis of this information.

Also I am not planning to send any other data on Sbus channel. I just need all data of 16 channels to receive PX4.

Alex Kushleyev

@Aaky , OK, I have an idea that you should try, which does not require any code modification, other than in your one Teensy board that you use:

Teensy device reads SBUS from your Android RC controller
Teensy re-packages the 16 channels of RC data into CRSF RC format
Teensy transmits the CRSF packet to Doodle Labs transmitter using standard UART config 8N1, 115200 (or higher baud rate)
On the drone, the Doodle Labs receiver receives the CRSF data and sends it to VOXL2 directly using standard UART config (can be the same as on the TX side) to one of the UART ports that are connected to DSP
on VOXL2, you start the already available CRSF receiver and provide the baud rate that you use.

More details:

how to generate CRSF packets:
- https://github.com/AlessandroAU/ESP32-CRSF-Packet-Gen
- https://gist.github.com/kielerrr/c506c249722e9f8781d9cb9195e910b8
px4 driver for CRSF RC
- https://github.com/modalai/px4-firmware/blob/voxl-dev/src/drivers/rc/crsf_rc/CrsfRc.cpp
how to start the CRSF driver in PX4 on VOXL2
- in /etc/modalai/voxl-px4.conf select RC=CRSF_RAW
- in /usr/bin/voxl-px4-start , change the following to add the baud rate param (115200 in this case). You will also need to update the uart device if needed (2, 6, or 7 depending on where you plug it in : https://docs.modalai.com/voxl2-connectors/). You will probably use uart 7 (RC_UART) if you have VOXL2_IO board plugge into J18 (ESC_UART, uart 2) :

elif [ "$RC" == "CRSF_RAW" ]; then
    /bin/echo "Starting CRSF RC driver"
    qshell crsf_rc start -d 7 -b 115200

I think this should work..

You can start off by transmitting a fixed CRSF test packet from your Teensy device (you can use the python script i linked to generate the bytes stream for the packet and just hardcode this byte stream to send from Teensy at 50-100hz for a quick test. This will allow you to test everything downstream of Teensy without actually doing the SBUS->CRSF conversion yet.

Aaky

@Alex-Kushleyev This sounds like a good plan. Let me see how far I can get.

Aaky

@Alex-Kushleyev One quick query, while I am creating this whole pipeline, can we test the RC driver with this CRSF packet in HITL environment? I want to be sure about latency and any other hiccup before putting this setup over my aircraft. In HITL I can connect two Doodle modems in same architecture as discussed above with teensy decoding the Sbus packets. Let me know feasibility and required changes if any.

Eric Katzfey

@Aaky In general, HITL is a good way to test RC.