M0117 ESC rough control
-
@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
@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 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.
@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:
- px4 driver for CRSF RC
- how to start the CRSF driver in PX4 on VOXL2
- in
/etc/modalai/voxl-px4.confselectRC=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 haveVOXL2_IOboard plugge into J18 (ESC_UART, uart 2) :
- in
elif [ "$RC" == "CRSF_RAW" ]; then /bin/echo "Starting CRSF RC driver" qshell crsf_rc start -d 7 -b 115200I 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 , 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:
- px4 driver for CRSF RC
- how to start the CRSF driver in PX4 on VOXL2
- in
/etc/modalai/voxl-px4.confselectRC=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 haveVOXL2_IOboard plugge into J18 (ESC_UART, uart 2) :
- in
elif [ "$RC" == "CRSF_RAW" ]; then /bin/echo "Starting CRSF RC driver" qshell crsf_rc start -d 7 -b 115200I 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.
-
@Alex-Kushleyev This sounds like a good plan. Let me see how far I can get.
@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.
-
@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.
@Aaky In general, HITL is a good way to test RC.
-
@Aaky In general, HITL is a good way to test RC.
-
@Eric-Katzfey So can the RC driver work in HITL directly without any additional modification in code?
@Aaky Should be fine. I fly with actual RC in HITL all the time.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login