New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AP_SmartAudio: initial implementation #11630
Conversation
This is probably the most asked feature on rcgroups forum. |
hello, Do you have some link on documentation or what is smartaudio ? (I try googling but they is to much flood on the subject) |
This is about controlling a video tx with serial port https://discuss.ardupilot.org/t/is-there-a-way-to-get-smartaudio-working/29025/20 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SergeyBokhantsev Let me start by thanking you for this contribution, this has been requested multiple times.
However, there are a couple of issues with it:
- the commits need to follow our rules (which I think you are aware of), namely the first commit should be split into multiple commits, one per vehicle/library
- I think this is way more complicated than it should be:
- the various versions of the protocol are very similar so having multiple classes doesn't look necessary
- the protocol version can be obtained automatically, no need to have the users set it
- I don't quite understand the "one way" versions, the replies are the confirmation that the command took effect; even if we didn't use them, I don't see any good reason to have a special version just for it
- you have implemented v2 which only has 4 power levels (from 0 to 3), but there are parameters for setting 5 power levels and setting them isn't that useful since they'll be 0 to 3... I understand that v1 and v2.1 can set multiple values (instead of just the 4 levels), but we can address that if we ever get those implemented
If you need help or want to discuss my concerns above, I'm usually around
Gitter chat too (http://gitter.im/ArduPilot/ardupilot).
|
||
// @Param: PROTOCOL | ||
// @DisplayName: SmartAudio protocol version | ||
// @Description: 0: None, 3: Version 2.0 One way |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the link you posted, looks like there are 3 versions: v1, v2, v2.1. What is the One way version?
Also, why isn't this automatically detected? The protocol provides it from the Get Settings command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@OXINARF thanks for the such a complete review! I will go through the questions soon but want to clarify about OneWay and autodetect. The problem is SmartAudio physically is a single-wire half-duplex protocol. That means you have options:
- To somehow configure your MCU to be a half duplex. I don't know if this possible for a wide range of the supported FC
- To connect SA line of VTX to TX/RX lines on FC using the resistors scheme. I personally didn't tested this yet.
- To connect SA line of VTX to TX line on FC, that's why I calling that OneWay. You're not able to get a response but for 90% of the use cases it is not needed :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To somehow configure your MCU to be a half duplex. I don't know if this possible for a wide range of the supported FC
I'm not sure if you are aware that we do support half-duplex, you just have to set the appropriate SERIALx_OPTIONS ibt. According to code comments, it's supported in all F4 and F7s, so quite a wide range should support it.
To connect SA line of VTX to TX line on FC, that's why I calling that OneWay. You're not able to get a response but for 90% of the use cases it is not needed :)
Ok, if we want to support that then we can have 4 options:
- 0: auto-detect
- 1: v1
- 2: v2
- 3: v2.1
Then we can rate limit the sending if needed (I think it's quite low rate already but I'm not against further limiting).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@OXINARF No, I wasn't aware F3 supports half-duplex. I found the half-duplex option goes to UART implementation, but is there any example or doc about using that mode? Or there is no difference and I can just use .Read() and .Write() as in normal mode?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I wasn't aware F3 supports half-duplex.
Did you meant F4? Because we don't support F3.
I found the half-duplex option goes to UART implementation, but is there any example or doc about using that mode? Or there is no difference and I can just use .Read() and .Write() as in normal mode?
There is nothing different, usage is the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I meant F4. Ok thanks, will try that.
|
||
// @Param: TRAILZERO | ||
// @DisplayName: Enable trailing zero | ||
// @Description: If enabled the trailing zero will be sent after SA frame. Some VTX requires that. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. Would it be possible to always send this? Looks like a hard parameter for users to figure out.
|
||
// @Param: PWR_MODE | ||
// @DisplayName: Power mode | ||
// @Description: 0-4: Using of PWR_0 - PWR_4 value, 5: Use Auto power mode based on home distanse |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be better as a @Values
(with 0 to 4 just saying Power 0, etc.). It should still have a description though.
// @DisplayName: Power mode | ||
// @Description: 0-4: Using of PWR_0 - PWR_4 value, 5: Use Auto power mode based on home distanse | ||
// @User: Standard | ||
AP_GROUPINFO("PWR_MODE", 4, AP_SmartAudio, power_mode, 0), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this really be 0 by default? I would expect Auto to be preferred.
|
||
// @Param: PWR_0 | ||
// @DisplayName: Power #0 | ||
// @Description: First (minimal) VTX power level |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't need to be minimal, right?
@@ -0,0 +1,69 @@ | |||
#pragma once | |||
|
|||
#include <AP_Common/AP_Common.h> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this needed for?
|
||
send_command(cmd, sizeof(cmd)); | ||
|
||
actual_state.power = desired_state.power; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should actually be done when getting the answer (which you are ignoring).
@@ -170,7 +170,8 @@ class RC_Channel { | |||
ALTHOLD = 70, // althold mode | |||
FLOWHOLD = 71, // flowhold mode | |||
CIRCLE = 72, // circle mode | |||
DRIFT = 73 // drift mode | |||
DRIFT = 73, // drift mode | |||
SA_PWR_LOW_OR_AUTO = 74, // SmartAudio VTX power toggle: low aux for minimal power, high aux for auto power |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should be PWR0_OR_AUTO. As written in a comment above, it doesn't really need to be a low power.
This needs to be added to parameter documentation.
@@ -101,15 +101,9 @@ void AP_SmartAudio::update() | |||
// TODO: calculate power basing on home distance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you going to add this in this PR? Otherwise we should really remove everything about it, we don't want dead code.
|
||
case SmartAudio_Power_4: power = power_4; break; | ||
default: | ||
power = power_value[power_mode]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You need to check that power_mode is valid, otherwise you could be doing an out of array memory access.
What´s the current status? I am also highly interested in this functionality 🥇 |
What`s the current status of this feature? I am also highly interested 👍 |
Any way to test the current support? |
This PR should be closed because of implementation overhead, also note @OXINARF review notes that shall be taken into account. |
Any news on this topics? In which release can we expect the Smart Audio feature? |
this has been stale for while. see #15174 for reference on current affairs. |
Ok, unfortunate, but hopefully @andyp1per will succeed this time :-) |
smartaudio support was bring by #16464. Thanks for the begin the effort on this ! |
No description provided.