Skip to content
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

Closed

Conversation

SergeyBokhantsev
Copy link
Contributor

No description provided.

@sh83
Copy link
Contributor

sh83 commented Jun 21, 2019

This is probably the most asked feature on rcgroups forum.

@khancyr
Copy link
Contributor

khancyr commented Jun 21, 2019

hello,

Do you have some link on documentation or what is smartaudio ? (I try googling but they is to much flood on the subject)

@SergeyBokhantsev
Copy link
Contributor Author

SergeyBokhantsev commented Jun 21, 2019

ArduCopter/config.h Outdated Show resolved Hide resolved
@sh83 sh83 requested a review from WickedShell June 22, 2019 04:11
Copy link
Member

@OXINARF OXINARF left a 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
Copy link
Member

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.

Copy link
Contributor Author

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:

  1. 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
  2. To connect SA line of VTX to TX/RX lines on FC using the resistors scheme. I personally didn't tested this yet.
  3. 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 :)

Copy link
Member

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).

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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.
Copy link
Member

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
Copy link
Member

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),
Copy link
Member

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
Copy link
Member

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>
Copy link
Member

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;
Copy link
Member

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
Copy link
Member

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
Copy link
Member

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];
Copy link
Member

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.

@Seeelefant
Copy link

What´s the current status? I am also highly interested in this functionality 🥇

@tridge tridge self-assigned this Oct 26, 2019
@Seeelefant
Copy link

What`s the current status of this feature? I am also highly interested 👍

@manotroll
Copy link

Any way to test the current support?

@SergeyBokhantsev
Copy link
Contributor Author

This PR should be closed because of implementation overhead, also note @OXINARF review notes that shall be taken into account.
I did another attempt https://github.com/SergeyBokhantsev/ardupilot/commits/SmartAudio2 but I have no time to complete it, unfortunately.
So anyone interested are welcome to use this branch as a base.
Personally I believe at moment that ArduPilot scripting is the best approach for that protocols.

This was referenced May 16, 2020
@Seeelefant
Copy link

Any news on this topics? In which release can we expect the Smart Audio feature?

@vierfuffzig
Copy link
Contributor

this has been stale for while. see #15174 for reference on current affairs.

@Seeelefant
Copy link

Ok, unfortunate, but hopefully @andyp1per will succeed this time :-)

@khancyr
Copy link
Contributor

khancyr commented Mar 19, 2021

smartaudio support was bring by #16464. Thanks for the begin the effort on this !

@khancyr khancyr closed this Mar 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

10 participants