dev20110619 plus hardware current sensor, LCD keys navigatio

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

dev20110619 plus hardware current sensor, LCD keys navigatio

Post by Hamburger »

Hi,

I added:
+ LCD key-navigation
+ Powermeter hardware sensor support
+ freeimu v01 sensors definition and orientation (hope I got it right)

http://code.google.com/p/multiwii/sourc ... 10619_plus

looking forward to v1.8 now !
Cheers, Hamburger

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Alexinparis »

Hi,

I've just added the modification on the live repository:
http://code.google.com/p/multiwii/sourc ... 2FMultiWii

the 1.8 will be released only if I get enough positive feedback.
it's not the case for the moment ;)

AlainB
Posts: 4
Joined: Wed Jun 15, 2011 8:46 pm

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by AlainB »

Hello Alex,
I discovered it was possible to follow the modification on the live repository... it's great !
I understand it was available starting with dev20110619 not since ...0607 ?

Feedback: my test-craft" was flying nicely with dev20110607...
... with dev20110619 it is highly unstable whatever PID tuning (perhaps due my incorrect "defined" configuration ?)
remark:
- I started the in-depth study of rev20110607 but because a large re-shuffling of the code... I am lost at this moment !
- re: for me, with a ALLINONE breakout, mag-orientation configuration is ROLL "Y" and PITCH "-X"

Cheers, Alain

fguichard
Posts: 2
Joined: Wed Mar 16, 2011 10:05 pm
Location: France Caluire

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by fguichard »

hi

we have fond one bug on powerValue with hardware current sensor.

if we have PSENSORNULL = 510

pmeter6Raw -- pmeter6Avg -- powerValue
525 --------------> 4110 -----------> 65533
525 --------------> 4132 -----------> 65530
525 --------------> 4149 -----------> 65528
525 --------------> 4161 -----------> 65526

change in code

MultiWii.pde line 206-209

#if (POWERMETER == 2)
pmeter6Raw = analogRead(PSENSORPIN);
pmeter6Avg = (pmeter6Avg * 3 + pmeter6Raw*8)/4; // average of last 4 values; use value*8 for better accuracy
powerValue = abs(PSENSORNULL - pmeter6Avg/8);
...
should be

#if (POWERMETER == 2)
pmeter6Raw = analogRead(PSENSORPIN);
pmeter6Avg = (pmeter6Avg * 3 + pmeter6Raw*8)/4; // average of last 4 values; use value*8 for better accuracy
powerValue = abs(PSENSORNULL - int( pmeter6Avg / 8) );
...


My current capteur : Allegro | Products | ACS758 http://www.flashrc.com/452-capteurs_composants.html

#define PSENSORNULL 530
#define PINT2mA 244
#define PLEVELDIV 230400L

regards

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Hamburger »

sorry, I do not understand the problem from your description. You may very well be right, it is just me, I do not understand.
What defect does your explicit conversion repair? I am not good with this type/casting stuff, can you explain, please?

So you do have hardware current senosr working? Great!
Hope you find it useful. Could you verify the refernce voltage for the sensor to be stable enough over entire flight? For me this does not seem to be true with the BEC output from HK SS ESCs.

Thanks for the input

fguichard
Posts: 2
Joined: Wed Mar 16, 2011 10:05 pm
Location: France Caluire

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by fguichard »

hi

we have an ACS 758 current sensor. we have test with latest dev version and we have strange value of "power" on GUI.

A 0% of throttle ( current is 0,2A ) the power value in GUI increase very quickly

for exemple

if PSENSORNULL = 510 and AnalogRead = 525 then powerValue = 65533

see bellow exemple test code

int PSENSORPIN = A8;

#define PSENSORNULL 510

static uint16_t pmeter6Raw, powerValue , intPowerMeterSum; //used for current reading
static uint16_t pmeter6Avg = PSENSORNULL * 8; //used for smoothing current reading
static uint32_t pMeter[7];

#define PHARDINTDIV 64 // doNotChange - must divide the sum of analogRead()*cycleTime over cycles to keep small enough for uint32
#define PLEVELDIV 230400L

void setup()
{
analogReference(DEFAULT);
Serial.begin(115200); // setup serial
for(uint8_t i=0;i<7;i++) pMeter[i]=0;
}

void loop()
{
delay(20);
//pmeter6Raw = analogRead(PSENSORPIN);
pmeter6Raw = 525 ;
Serial.print(pmeter6Raw) ;
Serial.print(" ----------> ") ;
pmeter6Avg = ( pmeter6Avg * 3 + pmeter6Raw * 8 ) / 4 ;
Serial.print(pmeter6Avg) ;
Serial.print(" ----------> ") ;
powerValue = abs ( PSENSORNULL - pmeter6Avg/8 );
Serial.print(powerValue) ;
Serial.print(" == ") ;
powerValue = abs ( PSENSORNULL - int (pmeter6Avg/8) );
Serial.println(powerValue) ;
Serial.print(" ?? ") ;


}


regards

Escuse me for my poor english
regards

escuse me for my english , i am franch

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Hamburger »

ah, ok thank you.
So I will have to make changes:
1.
pmeter6Avg a signed int, so make pmeter6Raw a signed int.
pmeter6Raw = analogRead(PSENSORPIN);

2.
PSENSORNULL - pmeter6Avg/8 will be evaluated as an unsigned int, if pmeter6Avg is an unsigned int. When the expression happens to be negative, this leads to overrun. The surrounding abs() is 'too late' and cannot cure this anymore.
So will make pmeter6Avg a signed int.

problem I have is that the analogRead(PSENSORPIN) returns 'jumpy' values on consecutive reads (that is also true already for the analogRead(VBATPIN) ). Building average over time is not really desirable. We will see what is possible.
From the man page:
It takes about 100 microseconds (0.0001 s) to read an analog input, so the maximum reading rate is about 10,000 times a second.

This does imply that we could read on every MW cycle (approx. every 2 to 6 ms equal to 500 to 160 times a second) easily.
to test:
a) reduce reading rate to 10 times a second
b) change programming setup ( saw a hint about interfrence from other pins and/or pwm activity somewhere)

Hamburger

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by ziss_dm »

Hi Hamburger,

analogRead(PSENSORPIN) returns 'jumpy'

probably because of "aliasing". To make it "right" you should probably do the following:

1) Install analogue LPF (resistor + capacitor ;) ) before ADC, not sure what bandwidth you need, but i would guess 2Hz would be enough.
http://www.muzique.com/schem/filter.htm
http://www.electronics-tutorials.ws/fil ... ter_2.html
2) Read ADC with frequency=Cut off freq. * 2
3) Run simple digital LPF with cut-off freq twice as low.

So if 2hz is enough for you:
1) R=10k, C=10uF
2) Read ADC with 4hz
3) Diginal LPF: Value = (Value * 3 + AnalogRead())/4

Just mine $0.05 :) Last step maybe not even needed. :)

I hope it would help.

regards,
ziss_dm

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Hamburger »

Hi ziss_dm,

ziss_dm wrote:probably because of "aliasing". To make it "right" you should probably do the following:

1) Install analogue LPF (resistor + capacitor ;) ) before ADC, not sure what bandwidth you need, but i would guess 2Hz would be enough.
http://www.muzique.com/schem/filter.htm
http://www.electronics-tutorials.ws/fil ... ter_2.html
2) Read ADC with frequency=Cut off freq. * 2
3) Run simple digital LPF with cut-off freq twice as low.


thank you for your thorough insight and thoughts.
But I am not sure if this is really solving the correct problem.
For a test I did use an 'empty' arduino that does only analogRead() in main loop with cycle time slowed down to 2 seconds. For input voltage I use regulated power supply at fixed setting. And still the two lowest bits of analogRead() seem to be random. To me this seems to be an inaccuracy of the AD-converter in the arduino. As such I do not expect to 'heal' this inaccuracy with any filtering/smoothing. Please correct me if this is wrong thinking!

Instead I intend to ignore this and maybe even right-shift the two lowest bits out (or replace them with the average value 10 binary). With the resolution of my sensor two bits equals 4*130mA= approx. 0.5A. If you take into account the average hover current of 10A (or more on most larger copters) this results in an error margin of [0%, 5%] or an average of 2.5% over time.

This random fluctuation on the lowest two bits seems to also be independent of the absolute value. My sensor has Vss=5Volt and outputs Vss/2 for I=0 A and Vss/2 +- 1V for I=25A (sign depending on direction of hall sensor). So depending on sensor orientation this maps to either [2.5 , 3.5] or [1.5 , 2.5] Volts range. My impression is it does not really matter to arduino's AD which interval it is given to work on.

Also this 10bit AD with effective 8bit does not get worse if frequency is increased to 400Hz. If I am not mistaken we will have to live with valid 8bits. I would love to stand corrected!

What do you think?
Hamburger

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Hamburger »

fixed the int/uint overrun issue, hopefully.
you may find the fixed version (plus some other changes) in a patched version against r181 here
http://code.google.com/p/multiwii/sourc ... Fr181-plus

The inaccuracy of the 10bit AD conversion remains to be investigated for good. For the time being I decided to blurr the display by dropping one digit of precission.

Hamburger

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Alexinparis »

Hi,

I've just made some update based on your last diff + some code arrangements

ziss_dm
Posts: 529
Joined: Tue Mar 08, 2011 5:26 am

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by ziss_dm »

Hi Hamburger,
You are absolutely right, ADC is noisy. :D But even standalone High-end ADC also noisy.
In your application, you probably should not really care about noise in "instant" ADC values, but it is desirable to get precise values from integrators. To archive that, you need to make sure, that your noise has gaussian distribution, etc.. Or in other words remove all non-gaussian noise sources. One of the big such sources - signal aliasing, which also really easy to remove and test :) Additionally proper choice of input LPF and sample rate could reduce size of variables needed for integration. :)

I can give you another example, why you need input LPF, and why it cold affect precision: For example, your saple rate 2sec and somethere betwen reads you had huge spike of current, let say 100A for 0.5sec. Without input LPF, you just missed that completelly your readings: 0,0,.., your integrator still zero. But if you had LPF, this spike would be "stratched" long enough to pickup by ADC. (another question is it easy to make analogue LPF with time constant 4 sec). Increasing sample rate reduces chances that you missed something, but not completelly eliminate it. As I remember, bandwidth of the hall sensor 30-40Khz, that means, without LPF, you need ADC sample rate 60-80khz, which is not currently possible.

So, in short, my points are:
1) I would reduce sampling frequency as it would help dealing with fast growing integrators.
2) To reduce aliasing effects and not to loose information, I would use input LPF.
3) We are not interested in instant values, so I would not use digital filter, as integrator by itself big low pass filter.

regards,
ziss_dm

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Hamburger »

ziss_dm wrote:So, in short, my points are:
1) I would reduce sampling frequency as it would help dealing with fast growing integrators.
2) To reduce aliasing effects and not to loose information, I would use input LPF.
3) We are not interested in instant values, so I would not use digital filter, as integrator by itself big low pass filter.


Hi ziss_dm,
thanks for the explanation. Finally I got to reading about aliasing in Wikipedia. You had mentioned it before but it did not register with me. After vacation I will solder and code your suggested strategy. From your hint: at worst we have cycle time of approx. 7ms, at best 3ms (for my setups). So I will use
a) sampling rate of 20ms <=> 50Hz in software (that is approx. 5 main loop cycles - should catch most motor spin-ups and -downs)
b) LPF hardware for 25Hz => R=10k, C=640nF
c) eliminate cycleTime from integration, remove software smoothing filter

Your advice (and links) are very helpful, looking forward to see it into effect.
Hamburger

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Hamburger »

followup to my own post.
software implementation is done, waiting for integration:
http://code.google.com/p/multiwii/sourc ... Fr187-plus

base: r187

changes:
+ powermeter hardware sensor: sample rate 50Hz, no software smoothing filter, requires LPF hardware filter (RC)
+ distribute timed tasks (powermeter, telemetry) in annexCode() to avoid bulk: set intervals to odd lengths

Cheers, Hamburger
Attachments
r187.diff.zip
hardware powermeter with lpf
(2.72 KiB) Downloaded 149 times

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Hamburger »

Reminder:
could save some bytes - for arduino MINI and other memory starved situations.
Or just invest 20$ in a PRO MINI and be done.

a)
if NUMER_MOTOR (set in Output.pde) was known in MultiWii.pde where pMeter[PMOTOR_SUM + 1] is declared.
For now PMOTOR_SUM is set to 8, but could be reduced to NUMER_MOTOR.
b)
in lcd_telemetry() (LCD.pde) could use generic function to output an uint16_t to char[] instead of current copy-n-paste code.
c)
remove unused variables for baro, log, telemetry, powermeter (MultiWii.pde), if feature not used
d)
make nunchuk code sections removable via define
e)
investigate, why config with BMA020 defined gives smaller binary compared to without BMA020 (probably true for other ACCs?)

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Alexinparis »

Hamburger wrote:c)
remove unused variables for baro, log, telemetry, powermeter (MultiWii.pde), if feature not used

you can declare variable.
if you don't use it, it won't take memory space.
That's why I removed some #define in your diff to clarify a little the code.

e)
investigate, why config with BMA020 defined gives smaller binary compared to without BMA020 (probably true for other ACCs?)

It's because nunchuk IMU code is not compiled when another I2C acc is selected
(in computeIMU(): if (!ACC && nunchuk) { )

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Hamburger »

Alex, thanks for clarification.

Here's some photos of the current status and functionality of telemetry and powermeter (with hardware current sensor). Uses the LCD (and possibly Bluetooth or some other wireless 'serial' connection) in the latest dev version (r190 and above)

two options:
a) manually select one page via button of the LCD
b) automatically cycle trhough all 4 pages every 2 seconds

Hamburger

Argh, photo size limit exceedd. So lokk here for photos:
http://www.rcgroups.com/forums/showpost ... ount=16104

User avatar
guru_florida
Posts: 45
Joined: Sat Mar 26, 2011 4:51 am

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by guru_florida »

What are the possible hardware sensors that can be used? I know just about anything that outputs an analog signal, but what have people used so far and what luck have they had? I see the ACS758 is one option.

How is the hardware sensor fairing versus the soft mode in accuracy? Measuring real current can be a bag of worms, I've been there. Proper LPF is the tricky part in order to remove the aliasing, otherwise the reading is often off. I could see soft mode being very accurate with some tweaking.

Does the software support using the A6 or A7 pin instead of the default A2? I am already using A2 for a GPIO pin but I have the A6 and A7 available on my Atmega328P.

Thanks,
Colin

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: dev20110619 plus hardware current sensor, LCD keys navig

Post by Hamburger »

guru_florida wrote:What are the possible hardware sensors that can be used? I know just about anything that outputs an analog signal, but what have people used so far and what luck have they had? I see the ACS758 is one option.

How is the hardware sensor fairing versus the soft mode in accuracy? Measuring real current can be a bag of worms, I've been there. Proper LPF is the tricky part in order to remove the aliasing, otherwise the reading is often off. I could see soft mode being very accurate with some tweaking.

Does the software support using the A6 or A7 pin instead of the default A2? I am already using A2 for a GPIO pin but I have the A6 and A7 available on my Atmega328P.


with software I get 5% accuracy which is good enough for me (not with HK SS ESC but with plush and blueseries - do not know why)

you can bsically use any and all sensors that output 0v to 5V range. I have good results with amploc sensors.
The pin is set via #define, so you can change that.
Hamburger

Post Reply