13 replies to this topic

[Brian]

I would like to wire up a simple battery voltage monitor and ultimately current monitor to a CC that simply reports the status back to the GCS.  I see a Battery module in git, and it looks like it probably would support what I want it to do, but I'm not sure what the status of it is.  I've also seen development on something similar using and i2c sensor, but that appears to be different, and doesn't appear to use the battery module.

Is the Battery module be in a state that's close to working?  Is this the way I should go in integrating this capability?  Has anybody else done this on the CC?

[Scott]

I have an I2C battery and current sensor working with CC. See this thread. Only problem I found is that GPS, telemetry and I2C can not all be used simultaneously due to the limited set of interfaces.... so I'm currently using it without GPS.

I'm using the attopilot voltage and current sensor. Code is yet to be integrated into Next.

[Brian]

I looked at that branch, and that's part of my confusion.  Your modules appear to do something similar, but I couldn't tell how it reports back to the GCS and what the GCS does with the information.  It also seems to duplicate functionality in the Battery module.

What I would like it some sort of battery gauge on the GCS and/or at least a warning when the battery goes below a certain level.

[Scott]

It reports back via one or two UAVObjects, namely "analogsensorvalues" and/or "gasenginedata", which can then be used as the source for a bargraph indicating battery or current. Audio warnings can also be set based on these UAVObjects I believe.

[D-Lite]

Another possibilty would be to use one (or two) of the PWM inputs as analogue inputs. I looked this up some time ago and I think there are at least two pins that have ADC as an alternate function. Another (but rather crude) idea: have a small external circuit that converts voltage to PWM and use the PWM input directly. This way you wouldn't even have to change the code.
I bought two ACS715 current sensor and intend to do the first method, but not in the near future :-).

[Brian]

D-Lite, on 08 December 2011 - 09:28 AM, said:

Another possibilty would be to use one (or two) of the PWM inputs as analogue inputs. I looked this up some time ago and I think there are at least two pins that have ADC as an alternate function. Another (but rather crude) idea: have a small external circuit that converts voltage to PWM and use the PWM input directly. This way you wouldn't even have to change the code.
I bought two ACS715 current sensor and intend to do the first method, but not in the near future :-).

Actually, the last 4 PWM input pins support ADC, so I plan to use the last 2 for the purpose.  There's some extra components on those lines (resisters, capacitors, and diodes, I think), so I need to make sure that they wont interfere, but I don't think they will.

I don't mind changing the code to remap the pins.  On my Vtail I am using 4 of the PWM input ports as outputs.  Of course I looked at the documentation AFTER I wired it, so I wired it to outputs 2,3,4,5.  The PPM+servo mode remaps 4 of the inputs as outputs, and I had planned to just use that, but it remaps pins 3,4, 5,6, so I ended up changing the code anyway!

I would really like to have another configuration screen in the GCS that allows one to assign a set of functions to each of the pins on the CC board individually.  The flight code is very flexible, and almost supports that now, but it would take some more significant changes to the GCS.

[Reddog]

Would it be worth it to create an i2c expander board that can accept these types of expansion modules and allow for more modules to be added? It might even help with the Revo if there are no enough i2c headers.

[D-Lite]

Reddog, on 08 December 2011 - 10:56 PM, said:

Would it be worth it to create an i2c expander board that can accept these types of expansion modules and allow for more modules to be added?

The problem here is not so much I2C. It's a bus system where you can simply connect several devices to the same I/O lines. The problem with I2C on CC is, that it shares the connector and I/O lines with one of the USARTs. If you need two USARTs, you cannot use I2C any more. Only solution to work around this would probably be an USART controller that hooks up to I2C but this doesn't make too much sense in my opinion. Or find a GPS or telemetry device that uses I2C instead of USART.

[Scott]

D-Lite, on 09 December 2011 - 08:31 AM, said:

Or find a GPS or telemetry device that uses I2C instead of USART.

Funny you mention this. I actually thought about implementing the I2C interface for the Ublox GPS. Perfect for the low frequency updates but seems to be a lot of work that may not be necessary with the Revo comming up.

[D-Lite]

Scott, on 09 December 2011 - 08:51 AM, said:

Funny you mention this. I actually thought about implementing the I2C interface for the Ublox GPS. Perfect for the low frequency updates but seems to be a lot of work that may not be necessary with the Revo comming up.

I also thought about this already but the I2C pins on my GPS modules are not easily accessible. And the I2C layer for the GPS would have to be re-written for every manufacturer. Apart from that, it's a good option and not too much work, I think.

[Brian]

I checked in a new branch (Brian-BatteryModule) that updates the battery module to compile and work with the latest next branch.  You can enable ADC ports similar to what I posted here.  You then need to define what ADC channels the voltage and current monitors are on like this (also in STM32103CB_CC_Rev1.h):

//-------------------------
// Battery ADC
//-------------------------
#define PIOS_BATTERY_VOLTAGE_CHANNEL		4
#define PIOS_BATTERY_CURRENT_CHANNEL		5

There it no support in the GCS to change battery settings, so you need to edit the settings in the object browser (Setting/FlightBatterySettings).  When you get these setup correctly, the battery status will show on the PFD, and you will also see warning/errors when the battery goes below your preset thresholds.

I started a review to get my updates merged into the next branch.

[Harbormaster]

Hi Brian -- You seem like just the guy to answer this question: Is there any point in a user configuring these flight battery settings when setting up CopterControl? I'm guessing that the answer is "Not now, but soon?"  (I'm writing up settings for the wiki, and this likes a feature that people would want to know about. I am, anyway. ) Thanks!


object name="FlightBatterySettings" id="0x8F3E8B2">

<field name="Type" values="LiPo"/>

<field name="NbCells" values="3"/>

<field name="Capacity" values="2200"/>

<field name="VoltageThresholds" values="9.8,9.2"/>

<field name="SensorType" values="None"/>

<field name="SensorCalibrations" values="1,1"/>

</object>

Edited by Harbormaster, 27 December 2011 - 10:11 PM.

[Brian]

Harbormaster, on 27 December 2011 - 10:11 PM, said:

Hi Brian -- You seem like just the guy to answer this question: Is there any point in a user configuring these flight battery settings when setting up CopterControl? I'm guessing that the answer is "Not now, but soon?"  (I'm writing up settings for the wiki, and this likes a feature that people would want to know about. I am, anyway. ) Thanks!

I believe that you are correct that these are values that a user will want to set eventually, but not currently.

The holdup currently on the battery module is that there is no standard interface for reading battery stats on the CC.  I wired mine through an ADC channel, which is not ideal because the ADC channels are used by the gyros on the CC, and reading the gyros fast and accurately is critical to stabilization.

Others have used an ADC that sits on the I2C bus, which is probably better, and I may switch to doing that, but it's still not standard.  There is some work being done on a generic I2C driver that would feed values of the I2C bus to the GCS.  I haven't looked at in in detail, but this may be a way to make it configurable.

In any case, I think it's important to be able to monitor battery status via the GCS, and I hope this will eventually be easy for a user to configure.

[Harbormaster]

Thanks Brian.