Frsky Sensors

[ChrisBird]

This PR allows the Frsky SPort FLVSS sensor to be used as a battery monitor (including cell level battery monitoring), it also sets up the framework for the other sensors to be used too. I will be integrating in the MVLSS, current sensor, Battery Voltage sensor & the airspeed sensor.

There is an Frsky Sensor library that will track the actual hardware interaction, and then the batt mon will probe that library for the values in the battery framework. The reason for this is that the sensors are not just battery monitors and it makes sense for one thing to control the interactions.

I do have a question around MP, it appears that some of the values for current sometimes 'pop' up even though I have current set to false (Batt Percentage, Current and assoicated items). This results in some values popping up and then disappearing. Any suggestions on how to resolve this would be appreciated.

I will also add the other vehicle types once the PR is closer to merge quality.

I'd appreciate any suggestions on getting it merged. I'll jump on the next few dev calls if that helps.

This requires either a craft & theory telem cable, or the combo listed on the frsky telem wiki entry, alternatively it can use a MAX3232 with a diode on it to convert RS232 one wire to TTL (TX/RX). Sensors (can be daisy chained) plugs into the RS232 to TTL converter then into the flight controller serial port.

I will do a wiki page for how to wire it up.

Its in reference to: #6296

[yaapu]

Hi Cris, great job! would you mind taking a look at this PR https://github.com/ArduPilot/ardupilot/pull/12200, there's an sport packet decoder that you could reuse to decode sensor data, after you write the poll bytes you would read all incoming data and feed it to the packet decoder which would then call the frame handler once the frame is decoded, the frsky sensor library should also be callable from the frsky telem library when the FRSKY sensors are chained on the frsky bus with ardupilot, I think we can join forces and merge our efforts

[ChrisBird]

Hi Alessandro,

I like the idea of joining forces on this. I was trying to get your attention at the dev conference but Louis skipped over my question as a 'user' question and I wasn't given a chance to explain so we could touch base. Had we both been there in person I would have come up and had a chat with you to clarify what I was working on.

I've had a quick look at your PR and I think we can make this work. No need to duplicate code. I really like the idea of having the battmonitor, airspeed, etc work when daisy chained to a receiver too. My use case was without but I can see having both options will be much more useful.

I'll find out the best way to apply my stuff on top of your PR (I'm assuming I can fetch your pr and merge it into mine - not sure how that will affect my PR - might ask on gitter the best way to do this).

Regards,

Chris

[yaapu]

great! I'm really sorry we could not get in touch! Ok my basic idea is to refactor some code in my PR to extract a namespace dedicated to frsky protocol stuff, so we can recycle it. I was thinking about the protocol decoder, crc, defines and the like. There is also a method to calculate frsky sensor IDs from their idx so you can loop like get_sensor_id(idx). Sensors should have a base class that in ardupilot style we should call AP_Frsky_Sensor_Backend. Brainstorming here. Users should enable specific sensor from parameters, this would allow to enable a subscription type integration between the telemetry library + scripting + bidirectional + sensors. There are 3 ways to have this working:

• AP_Frsky_Sensor in his own thread (no synchronization required)
• AP_Frsky_Telem thread that calls Ap_Frsky_Sensors singleton for subscribed sensors (no syncrhonization required)
• Both the above at the same time by having 2 data buses (synchronization required)

We should use discord and perhaps ask @tridge to create a #telemetry channel

[yaapu]

@ChrisBird I refactored the frsky bidirectional code, now there's frsky.h which would allow you to include the sport protocol parser and reuse some code, like the sport packet struct for instance.

If you drive the polling meta code should probably be like send polling header while (byte = serial data) { if (parse(byte)) { if (is_sensor_packet()) parse_sensor_packet() } } If the sensors are chained on the bus with the flight controller, I would instantiate your singleton with an argument to prevent uart and thread opening/creation and simply pass the parsed sport_packet_t* to your parse_sensor_data() method. What do you think, could it work?

[ChrisBird]

@yaapu excellent, I'll take a look this week and see what I can make happen. Will be towards the tail end of the week.

Re: the polling side I think I can make that work.

[ChrisBird]

@yaapu how far away are your changes from being merged? In the mean time I've cloned your repo and working off of that. I can then apply the changes back to my repo as a patch once yours is merged. Does that sound like a reasonable approach?

[peterbarker]

@ChrisBird @yaapu 's stuff's been merged now.

I did a quick rebase on the branch here on github and it wasn't a terrible rebase.

Are you still interested in chasing this?

[didokiuchukov]

Hello,

Count me as tester, if you need one. I can contribute with testing FrSky SmartPort Airspeed sensor - ASS-100 with INAV/ Arduplane on F765, F405-WSE, Minipix, Omnibus F4V3 and 405 mamba. I don't have too much coding experience but I'll be able to properly bug report.

Greetings,

[ChrisBird]

@ChrisBird @yaapu 's stuff's been merged now.

I did a quick rebase on the branch here on github and it wasn't a terrible rebase.

Are you still interested in chasing this?

Hi @peterbarker,,

Yes I'm happy to chase this still. I should have some time this week and next week to reapply my changes with the rebased code and we can go from there.

Regards,

Chris

[UAVSkies]

Need help...anyone?

https://discuss.ardupilot.org/t/frysky-lipo-battery-voltage-sensor/68868

[ChrisBird]

Hello,

Count me as tester, if you need one. I can contribute with testing FrSky SmartPort Airspeed sensor - ASS-100 with INAV/ Arduplane on F765, F405-WSE, Minipix, Omnibus F4V3 and 405 mamba. I don't have too much coding experience but I'll be able to properly bug report.

Greetings,

Hi @didokiuchukov, that would be great. I dont have the airspeed sensor, I have plenty of other sensors. I will rebase and apply my changes and then likely get you to run a custom version which will output some log data for me to make sure its reading the values correctly.

Thanks,

Chris

[Johnex]

Any updates on this? I would love to know if it would be possible to use one of the I2C ports instead of UART?

[ChrisBird]

Any updates on this? I would love to know if it would be possible to use one of the I2C ports instead of UART?

Hi, I've been super busy with my other work and have only gotten back to it this lately, I am spending some time on it this weekend. No its using a UART port.

It'll take another week to get my head around everything and the PR updated. Trying to reuse as much of the AP_Frsky_Telem components to keep maintenance down.

Regards,

Chris

[hagfelsh]

Hi! My understanding of the version control process is pretty basic, but it appears this was never merged into a release. Is that right?

[peterbarker]

Hi! My understanding of the version control process is pretty basic, but it appears this was never merged into a release. Is that right?

Correct - this is still not merged.