More Sensor options for Tau Labs Hardware

[Reddog]

I would really like to see the following sensor options added to Tau Labs hardware. There are a few reasons for asking for these sensors to be added. One is safety situations and the other is for testing and real world use.

1. Battery Current (ADC) both real time and cumulative.

2. Battery Voltage (ADC), just real time.

3. RSSI and Link Quality. This information is usually provided via PWM or PPM sum. PWM is probably a better choice. ADC is not a great choice since both ADCs will be used by Battery information.

I currently use EzUHF but am looking to move to OpenLRS because its open source and supports both manual control and telemetry. Both systems output RSSI and Link Quality (bad packets) via PWM.

The above would be valuable for the autopilot to know as once they go above/below a certain threshold you would probably want them to produce a Failsafe condition in Autonomous flight or at least a very large warning.

For more ambitious testing Fixed Wing, having the above output via Mavlink to MinimOSD is a must if I want to test safely and maximise chances of getting my plane back. I am able to watch the live video feed and see important information about the vehicle. If there is a problem I can take over manual control in a split second, even if the plane is well outside of line of sight. In real world scenarios I am able to fly the plane and be aware that all important information is right there in front of my eyes.

[James Cotton]

I think 2&3 should both already work on sparky and quanton already.  Have you already got the battery monitoring through the GCS working, and it isn't showing in minimosd?

--
You received this message because you are subscribed to the Google Groups "phoenixpilot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenixpilot...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Reddog]

I didn't know you had 2 & 3 working already... I had only seen voltage monitoring. I will enable on Sparky ASAP.

BTW - I am driving to a remote area this weekend so I can test things. If there is anything you would like me to test for Fixed Wing, I will try to get it tested.

[Guilhermo Santiago]

Actually #1 is available too, just have a look at the FlightBatteryState, all the information is already there although the ConsumedEnergy is wrongly named.

You have to set your system in the FlightBatterySettings object regarding cell count and capacity or it will may prevent you from flying since the batterymodule gives an alarm if your calculated remaining flight time is below 0.

I have flown with both voltage and current sensor monitoring the values on the GCS and although the voltage and current seemed about right the remaining capacity and remaining flight time seemed to decrease too quickly, so we can have an issue on that calculation, please keep an eye on that and report back.

About RSSI and Link quality, we have implemented RSSI only, no lost packet count, RSSI can be fetched from PWM, PPM or ADC. There are no docs that I know of to set it up so please let us know if you need help.

[Reddog]

Thank you for your informative answer.

About RSSI and Link quality, we have implemented RSSI only, no lost packet count, RSSI can be fetched from PWM, PPM or ADC. There are no docs that I know of to set it up so please let us know if you need help.

I would really appreciate some help on setting up RSSI.

[Guilhermo Santiago]

Sorry for the late reply.

On the ManualControlSettings object:

RssiType- Choose between PWM, PPM or ADC.

RssiChannelNumber- Choose the Rssi channel number, ex '0' for ADC channel 0.

Reboot.

On the ManualControlCommand object:

Check RawRssi with Tx next to Rx and at the furthest usable distance (use range check if possible), take not of maximum and minimum value.

Return to ManualControlSettings:

Fill RssiMax and RssiMin with the values from the previous step.

Your Rssi value will now be available on the ManualControlCommand Rssi field and on the MavLink Stream.

Remarks:

Minimosd extra should be configured with rssi min max values of 0 and 100. (no one has tested taulabs rssi with miniosd AFAIK).

For systems like FrSky with a very short Rssi PWM period there is and extra setting - ManualControlSettings RssiPwmPeriod.

[Reddog]

Thank you Guilhermo!

I can confirm it works on MinimOSD-Extra 2.3.0.8. I configured it to get the values from the PPM stream. There are some really weird values in MinimOSD if you start the plane without the transmitter turned on but it seems to work itself out after a few minutes.

I would like to say a huge Thank You to whomever wrote this, I am sure this will save my plane a number of times! Sure beats flying the plane and watching for failsafe in the way the plane flies.

[Reddog]

I see that you wrote this Guilhermo (did some searching to find who). Thank You!

[Reddog]

I was reading the code here - https://github.com/TauLabs/TauLabs/blob/next/flight/Modules/Battery/battery.c

It seems there is a cumulative current value. Since I am not particularly great at this type of code, could someone confirm if I am correct please?

[Guilhermo Santiago]

Not sure what you mean but somewhere above I stated that energy (in mAh) and remaining flighttime are already part of the computed values and both available trough the GCS and the first available via MavLink.

[Carsten Böhme]

I am trying to use RSSI input to a Quanton from a Frsky D4R-II. The information I have is from this thread and https://github.com/TauLabs/TauLabs/pull/839

These are my settings:
Receiver port = PPM+PWM+ADC (PPM is on input 1, power on input 2, rssi on input 3, current and voltage on 7 and 8)
RSSI type = PWM
Rssi channel number = 2 (RSSI connected to Input 3, channel numbering starts at 0, right?)
Rssi PWM period = 0 (this should be something else for Frsky, but I do not know the correct period)

RawRssi = 6 and Rssi = -99, both do not change.

Connecting the rssi cable instantly kills usb telemetry. Wireless telemetry keeps working.

[Reddog]

I can not help you 100% since I used PPM but I remember being told there were only 2 ADC pins on the Quanton, 7 & 8. Looking here that seems to be correct - http://taulabs.org/TauLabs/doxygen/flight/html/quanton_2board__hw__defs_8c_source.html

Can you get RSSI working if you use pin 7 or 8?

[Guilhermo Santiago]

Try with the default period of 9.6.

[Carsten Böhme]

>Can you get RSSI working if you use pin 7 or 8?

Yes, that gives rawrssi between ~2000 and 3500. This corresponds with voltage measurements taken on the signal pin, 2,2 V.... 3,2 V

Any attempt to connect to inputs 3 to 6 still kills telemetry (now both usb and wireless), so something is very wrong here.

The Frsky manual (and every other source I can find) says that the Rx will give RSSI as a PWM signal: 'RSSI (PWM) and CPPM output - If CH3 and CH4 are connected by a jumper, CH1 will output CPPM for CH1~CH8, and CH2 will output RSSI (PWM)'. I'll find someone with an oscilloscope to look at the signal.

>Try with the default period of 9.6.

Is that milliseconds, i.e. the value for the object would be 9600 µs?

[Guilhermo Santiago]

9.6uS, it is the default value for that object field.

What code version are you using? Does the telemetry stopping issue occur only when you configure the RSSI type or always?

[Jörg Rohde]

I have make an Test descriped here http://fpv-community.de/showthread.php?22230-Tau-Labs-Software-unterst%FCtzt-vielf%E4ltige-Hardware&p=520581&viewfull=1#post520581
It´s in German sorry.
I used an Servotester and it´s working with PWM.
But if I have an Pulstime from 1000-2000µSec how I can have an Periodical of 9.6µSec?
I have set to 8000µSec for my Servotester with an repeat frequenz of 125Hz. It doesn´t matter it works also with this setting with 50 and 250Hz-

[Carsten Böhme]

>9.6uS, it is the default value for that object field.

I was wondering because the field accepts only integer values, so either 9 or 10.

>What code version are you using?

taulabs_master_20131223_164730_ccbf8f549e_win32

> Does the telemetry stopping issue occur only when you configure the RSSI type or always?

Whenever the receiver port is set to PWM (PPM+PWM+ADC or PPM+PWM) and the rssi cable is connected, regardless of RSSI type (even none).

[Carsten Böhme]

same behavior with a D8R-XP Rx and another Quanton

[Carsten Böhme]

Telemetry dies only while the signal is strong, at the edge of range telemetry is maintained.

[Guilhermo Santiago]

Sorry you are right, that field should be a float or nS instead of uS.
I'll be without a Dev machine until Monday, will try fixing it then.

[Guilhermo Santiago]

Our tests with frsky have shown that it uses a much higher frequency than "normal" PWM signals. Are you saying your tests show otherwise?

[Guilhermo Santiago]

[Carsten Böhme]

>Our tests with frsky have shown that it uses a much higher frequency than "normal" PWM signals. Are you saying your tests show otherwise?

No. I only have a simple multimeter, so all I can measure is the mean voltage (this ranges from 2.2 (max range) to 3.2 V (Tx next to Rx).

Jörg does not have a Frsky Rx, he used a servo tester to create a PWM signal.


Do you need more measurements? I can either get a cheap oscilloscope (http://goo.gl/aTbP9i) or ask someone at university with better equipment.

[Jörg Rohde]

I have used my Servotester with 50, 125 and 250Hz. If there comes an PWM with 1000-2000µSec it cound not be faster than 490Hz imho.
Carsten if you have an other FC you could put the signaloutput to the ESC´s on the Quanton RSSI Port, than you have an signal with 400Hz and when you arm that FC you have to see the PWM length on the GCS.

[Jörg Rohde]

A second thought: Use your Quanton - put an Output to the RSSI - arm and when you change the throttle you must see it in the GCS :)

[Carsten Böhme]

I could not resist and got the Hantek oscilloscope. I have just started to toy with it, and it looks like the RSSI signal from D4R-II is indeed PWM with a pulse length of about 9.15 or 9.2 µs. Keep in mind that this is cheap hardware and that I have just started working with it.

[Guilhermo Santiago]

Sorry for taking so long to follow up on this. I have pushed a change with a new default value, the code you are using should work.

I have tested with the D4R and FlyingF3 set for PPM+PWM, with the following values:

• RssiPwmPeriod=260
  
• RssiMax=240
  
• RssiMin=0
  

If you still have troubles set the period to "0" to bypass the fast pwm hack and look at the rawrssi value with the Tx turned of. Use that value for the period. 

[peabody124]

Awesome. If anyone has a chance to test it there is a PR with code to enable FrSky telemetry https://github.com/TauLabs/TauLabs/pull/1081

[Carsten Böhme]

>there is a PR with code to enable FrSky telemetry

I've been waiting for that! Is this aimed at the old sensor hub or smartport?

[Carsten Böhme]

My most basic problem with RSSI is still present with taulabs_next_20140125_143328_b725ae7cf9_win32. PPM+PWM+ADC enabled and rssi line connected from Frsky receiver port 2 to Quanton input 3 stops telemetry. (Only with PWM enabled, if input is set to PPM+ADC, nothing bad happens)

Any ideas how stupidity on my part could be involved?
If the signal is connected to the third input of Quanton, which Rssichannelnumber do I need to set?

[Carsten Böhme]

On Revomini, just enabling PPM+PWM gives an RC input error. I did not investigate further.

[Guilhermo Santiago]

Unfortunately to test that I would need other Frsky hw witch I don't have. Also I'm ditching all my FrSky hw and replacing it with the OSS OpenLRS. 

[Guilhermo Santiago]

I completely forgot about that issue. Will try having a look at it this week, only on Quanton though since I don't have any OP hw besides CC.

[Carsten Böhme]

I will test the frsky bridge as soon as I have information on the required TTL<=>RS232 converter. Would these do? http://www.ebay.de/itm/10-Stuecke-Mini-RS232-auf-TTL-Converter-Module-Konverter-Board-Modul-/280735985895


@Guilhermo: if you need a D4R-II to work on the RSSI issue let me know.

[Lilvinz]

On 26.01.2014 00:10, Carsten Böhme wrote:
> I will test the frsky bridge as soon as I have information on the required
> TTL<=>RS232 converter. Would these do?
> http://www.ebay.de/itm/10-Stuecke-Mini-RS232-auf-TTL-Converter-Module-Konverter-Board-Modul-/280735985895

Yes, those will work.

[Carsten Böhme]

Can 'we' (which unfortunately excludes me, I can't do that) modify our mavlink bridge to talk to frsky smartport? If this is working http://www.diydrones.com/forum/topics/amp-to-frsky-x8r-sport-converter, then all the necessary info should be in his arduino code.

[Reddog]

If you look at the code in the link you posted you will notice they are translating Mavlink data into FrSky data. There would be no point converting Mavlink to FrSky, it would be much smarter to write a UavTalk to Frsky converter. If I am reading the code correctly - if you look at the function _MavLink_receive() (in tab MavLink_FrSkySPort) you can see where they are reading the Mavlink data and putting it into variables. If you look at the function FrSkySport_Process(void) (in tab FrSkySPort) you will see where they are sending those variables to the FrSky receiver in FrSky format.

You could use the above code/information as well as the Uavtalk to Mavlink code (in Tau Labs) to work out how to write a Uavtalk to FrSky converter. Just replace the Mavlink part with the Frsky part in the existing Uavtalk to Mavlink converter code.

[Carsten Böhme]

4th attempt... Just deleted 3 posts about current sensor issues. All were on the wrong trail. The following is reproducible.

Quanton, latest Next, Attopilot 180 A current sensor
- telemetry via USB gives correct current readings in GCS
- telemetry via OPLink gives only garbage

Voltage reading is fine in both cases.