Baseflight aka multiwii port to stm32

mr.sneezy · Post by **mr.sneezy** » Thu Mar 21, 2013 11:21 am

Question for TC.

Can you clarify what the status of flight battery telemetry signal from the Naze32/FF board is on the late firmware ?
The reason I ask is that I see a display on my DHT-U that looks like it's from the FC's serial telemetry data (emulating a FLVS-01 sensor or similar) indicating the total pack voltage correctly within 10mV or so, but I'm being assured in a couple of posts in your old RCG thread that FC voltage monitoring is not implemented in your code.
If it's not then I'm getting some freakishly close to flight battery results on my FrSky LCD display from some other source

Thanks,
Martin

Originally Posted by PLMS
I'm running TimeCops latest beta build of the Baseflight MultiWii port from here.
https://github.com/multiwii/baseflig...e/upstream/obj
What are you using ?

brm aka RobertB branch, TC FW - but does not matter, latest TC branch isn't patched yet with patches for FrSky telemetry.
So, you're probably seeing voltage from analog ports on frsky TX...

http://www.rcgroups.com/forums/showpost.php?p=24481432&postcount=5761

timecop · Post by **timecop** » Thu Mar 21, 2013 2:32 pm

If you look at commit history I'm pretty sure there's a patch from fiendie there for displaying faux-FLVS data.

fiendie · Post by **fiendie** » Thu Mar 21, 2013 10:53 pm

mr.sneezy wrote:Question for TC.

Can you clarify what the status of flight battery telemetry signal from the Naze32/FF board is on the late firmware ?
The reason I ask is that I see a display on my DHT-U that looks like it's from the FC's serial telemetry data (emulating a FLVS-01 sensor or similar) indicating the total pack voltage correctly within 10mV or so, but I'm being assured in a couple of posts in your old RCG thread that FC voltage monitoring is not implemented in your code.
If it's not then I'm getting some freakishly close to flight battery results on my FrSky LCD display from some other source
Thanks,
Martin

http://www.rcgroups.com/forums/showpost.php?p=24481432&postcount=5761

I have seen that post and it really puzzles me. For cell voltages to show up on the FLD-02, a modded 9x or whatever you have to send the battery information for each cell with the header 0x06 (ID_VOLT in the code). Prior to the patch only the total voltage was transmitted with the header 0x3A and 0x3B (before and after decimal point). So the screen you're seeing on that telemetry display in your photo shouldn't even have been there.

Voltage from the ADC is displayed on the first screen.

I am currently working an FLVS-01 input for the naze. It's not a lot of work but I have virtually no free time at the moment

mr.sneezy · Post by **mr.sneezy** » Fri Mar 22, 2013 8:32 am

timecop wrote:If you look at commit history I'm pretty sure there's a patch from fiendie there for displaying faux-FLVS data.

After a bit of searching Github and working out what it can tell me, it looks like Moritz Ulrich added the code for reporting the pack voltage via the faux FLVS-01 data 19 days ago, and then fiendie added it to your code. That's about when I connected up the FC telemetry to the receiver serial port...
https://github.com/fiendie/baseflight/c ... 49e6946030

mr.sneezy · Post by **mr.sneezy** » Fri Mar 22, 2013 8:38 am

fiendie wrote:I have seen that post and it really puzzles me. For cell voltages to show up on the FLD-02, a modded 9x or whatever you have to send the battery information for each cell with the header 0x06 (ID_VOLT in the code). Prior to the patch only the total voltage was transmitted with the header 0x3A and 0x3B (before and after decimal point). So the screen you're seeing on that telemetry display in your photo shouldn't even have been there.

I'm not sure what your post was saying because the photo was taken only a couple of days ago, after the Ulrich code was added to TC's source.
No matter, I retested the DHT-U display and FC last night and it tracks pack voltage from 8V to 13V within 0.2 of a volt with the RX's ADC's disconnected from my other sensor so something is working...

fiendie · Post by **fiendie** » Fri Mar 22, 2013 11:13 am

mr.sneezy wrote:I'm not sure what your post was saying because the photo was taken only a couple of days ago, after the Ulrich code was added to TC's source.
No matter, I retested the DHT-U display and FC last night and it tracks pack voltage from 8V to 13V within 0.2 of a volt with the RX's ADC's disconnected from my other sensor so something is working...

Yes, it was a little pair programming thing. I didn't just add code from somewhere, thank you...
Ablomas insisted that the picture was older and it *somehow* worked before, that's what puzzled me.
So if you got the code from there, of course it works...
You should get some flickering on a FLD-02 though because in this particular branch voltage data is being sent every 125 ms.
There are some other changes that made it into the final patch.

I think I lost track of what the actual question was now

So which firmware are you actually running now?

mr.sneezy · Post by **mr.sneezy** » Fri Mar 22, 2013 12:51 pm

I think the question is sorted now. Boiled down mostly to me doubting my own eyes and experience

I'm running the 4th March build. I don't think there is any reason to update again currently, but I see work on updating to MW 2.2 source I think.
Sorry if I don't seem to very 'with it' about all the stuff on Github, it's a thing not familiar to me. I do write some code (for PIC mcu's) but not in an environment like that and not in C code !

I actually have an original pre-production prototype DHT-U display/TX unit, sent to me to give feedback to FrSky. The hardware has changed a bit now, but it still takes firmware updates OK. I have not noticed any flickering yet on that.

fiendie · Post by **fiendie** » Fri Mar 22, 2013 1:13 pm

mr.sneezy wrote:I think the question is sorted now. Boiled down mostly to me doubting my own eyes and experience
I'm running the 4th March build. I don't think there is any reason to update again currently, but I see work on updating to MW 2.2 source I think.

Yeah, should be finished in the next few days.

Sorry if I don't seem to very 'with it' about all the stuff on Github, it's a thing not familiar to me. I do write some code (for PIC mcu's) but not in an environment like that and not in C code !

Git is great once you get the hang of it

Especially for collaboration.

I actually have an original pre-production prototype DHT-U display/TX unit, sent to me to give feedback to FrSky. The hardware has changed a bit now, but it still takes firmware updates OK. I have not noticed any flickering yet on that.

Yeah, the March 4th build sends one frame with info for one cell every second. Somehow I thought you ran the code from Moritz' repository, sorry

The format for cell info is pretty darn weird.

Anyway, glad it works for you

You can tune the accuracy with vbatscale in the CLI a bit but there are some losses due to the division of course.
I just set it to report a little less than VBAT. Better safe than sorry I guess. Especially since you can't set any voltage alarm in the FLD-02 at the moment.

Cheers
Andy

JollyJoker · Post by **JollyJoker** » Fri Mar 22, 2013 8:05 pm

@TC,

as you know about the code ;-)

Will it be possible to mod the buzzer out signal to have about 40kHz modulation on it - to abuse for IR transmitting purpose?
If not, what is preventing it from functioning - except not being coded yet?

Regards Peer

timecop · Post by **timecop** » Sat Mar 23, 2013 4:24 am

Probably - assuming the pnp can switch that fast (no idea really). You might have to remove/jumper the transistor.
The whole buzzer thing is kinda fail because I had to be compatible with FreeFlight hardware, which uses a PNP in a really dumb way to drive the buzzer. If it was me, I'd have inverted the signal and used npn or nfet. PA12 is a pretty boring pin though and you won't get any hardware support (ie. there's no timer on it and nothing useful can be remapped to it unless you can hax something with CanTX? (doubtful)

mr.sneezy · Post by **mr.sneezy** » Sat Mar 23, 2013 6:04 am

Hi all, I had a bit of a tense minute or two flying the quad and I expect some of you have already got a tuning solution.

The scenario. A quad flight at my club, in fine but windy conditions which is typical in my area (later found to be 15 kts). The quad was virtually the same as used a few evenings ago when I very successfully testing the RTH mode a number of times in calmer weather.
I took account of the wind by today with an increase of the nav_speed_max parameter before the flight, adjusted it from 300 to 400 in the CLI. I fitted a micro video camera to get some footage of the club field from afar as well. Telemetry was active via the FrSky DHT-U display.

Anyway, to cut a long story shorter, I took off and climbed to about 100m, then flew it away (down wind) by about 200m, then turned on RTH, and it didn't come back (and I got rather tense)...
The onboard video later shows that the quad rotated to point back at me correctly, but it appeared that the wind velocity overcame the quads ability to return. I let it try longer on RTH for a while, but when the GPS telemetry link data showed it was now 500m away and receding I took it out of RTH and into ACC. With the help of another club member to watch the altitude I managed to successfully fly the quad by the GPS range info in meters. Basically I pushed forward stick all the way (ACC mode) and watched the GPS range. Initially it was going further away so I gave it about 2-3 seconds of rudder and tried again. Third time I got the heading right and it was coming home. It took a minute or so of flight to get it back, then I landed it as normal.

Ok, so the quad didn't like 15 knots of wind in GPS flight mode, I have leaned yet another bit of information about quads and flight controllers

In gyro only mode the quad laughs at 15 knots BTW, it flies around much like my Trex-500 heli. So apparently the size and power of the quad should be sufficient.

The question is, what part of the control system needs to be tuned to allow GPS RTH in some wind. Is it the levelling limit parameters (allow more bank angle), or is it the maximum GPS control limit parameters (or both, or something else)
I bet somebody has been through this in windy conditions with our system already, and can save me reinventing the proverbial wheel.

A second question too.
Would 'Heading Free' mode have helped me get it back more easily, or is it not really meant for that situation ?

Cheers all
Martin
PS. A 550mm size quad at 500m away is a speck in the sky !

fiendie · Post by **fiendie** » Sat Mar 23, 2013 10:51 am

mr.sneezy wrote:A second question too.
Would 'Heading Free' mode have helped me get it back more easily, or is it not really meant for that situation ?

It depends

The heading is always the direction it was facing when you armed it. So if you didn't turn around before engaging headfree mode then yes. Pull back the pitch stick and it will fly back in your direction.

Crashpilot1000 · Post by **Crashpilot1000** » Sat Mar 23, 2013 8:39 pm

@mr.sneezy: LOL, that was the same mistake in thinking i had. Actually the nav_speed_max is just a speedlimiter, but that speed is never reached.... So you will have to crank up the NavR P and perhaps even the PosR P.
BTW in the meantime I have a working acc integration going on for PH - this time it works better. It is Harakiri10 Beta because most of the stuff is untested due to bad weather. RTL is not improved but the current navigation should be at least faster because i set nav_slow to zero (was 1 before and not accessible via CLI).
http://fpv-treff.de/viewtopic.php?f=18& ... 300#p24444
Check it out.

Cheers
Kraut Rob

P.s. For Poshold you will need to tune 2 basic parameters (PosHold P & I), but you CAN tweak many more.... (see description in Link)
I think this time gps / inertia poshold is really D O N E. And i think we are the first here with working opensource stuff. There is always room for improvement (mag, acc etc) but Yippie ya yay !!!

Crashpilot1000 · Post by **Crashpilot1000** » Sat Mar 23, 2013 10:58 pm

@Timecop: I know you are preparing a downgrade to mwii 2.2 but i think cGiesen found a problem with the current implementation of your powermeter feature.
board.h:

Code: Select all

typedef enum {
    FEATURE_PPM = 1 << 0,
    FEATURE_VBAT = 1 << 1,
    FEATURE_INFLIGHT_ACC_CAL = 1 << 2,
    FEATURE_SPEKTRUM = 1 << 3,
    FEATURE_MOTOR_STOP = 1 << 4,
    FEATURE_SERVO_TILT = 1 << 5,
    FEATURE_GYRO_SMOOTHING = 1 << 6,
    FEATURE_LED_RING = 1 << 7,
    FEATURE_GPS = 1 << 8,
    FEATURE_FAILSAFE = 1 << 9,
    FEATURE_SONAR = 1 << 10,
    FEATURE_TELEMETRY = 1 << 11,
    FEATURE_POWERMETER = 1 << 12,
    FEATURE_VARIO = 1 << 13,
} AvailableFeatures;

But it is missing here before "VARIO":
cli.c

Code: Select all

const char * const featureNames[] = {
    "PPM", "VBAT", "INFLIGHT_ACC_CAL", "SPEKTRUM", "MOTOR_STOP",
    "SERVO_TILT", "GYRO_SMOOTHING", "LED_RING", "GPS",
    "FAILSAFE", "SONAR", "TELEMETRY", "VARIO",
    NULL
};

What is powermeter exactly for, anyway?

timecop · Post by **timecop** » Sun Mar 24, 2013 2:43 am

oops, thanks for catching that. will fix the strings array.
I think powermeter could work, when additional adc is used for sensor (real hw current meter, not fake shit from mw)

mr.sneezy · Post by **mr.sneezy** » Sun Mar 24, 2013 3:45 am

Crashpilot1000 wrote: http://fpv-treff.de/viewtopic.php?f=18& ... 300#p24444
Check it out.

Hi Rob,

Thanks for the tip on what to adjust. I'll do that and retest it.

I checked out the Harakiri10 info you posted. Google translate is removing all your formatting like the paragraphs and lists, and turns it into one big block of text. I can follow the gist of it though and it sounds like what I need to try out soon. I will wait for a bit more debugging before I load it though, as at my point of experience I'd not be able to tell if the firmware had a small bug or if I was just setting it wrong anyway.
I saw references to GPS braking and nav orientation settings and that sound good.

Thanks,
Martin

Gaijin · Post by **Gaijin** » Sun Mar 24, 2013 10:15 am

mr.sneezy wrote:
Crashpilot1000 wrote: http://fpv-treff.de/viewtopic.php?f=18& ... 300#p24444
Check it out.
Hi Rob,

Thanks for the tip on what to adjust. I'll do that and retest it.

I checked out the Harakiri10 info you posted. Google translate is removing all your formatting like the paragraphs and lists, and turns it into one big block of text. I can follow the gist of it though and it sounds like what I need to try out soon. I will wait for a bit more debugging before I load it though, as at my point of experience I'd not be able to tell if the firmware had a small bug or if I was just setting it wrong anyway.
I saw references to GPS braking and nav orientation settings and that sound good.

Thanks,
Martin

Hey Crashpilot,

I have agree with mr Sneezy, google translate wrecks your instructions in the translation and makes it very hard to read, it's a real shame as I'd really like to try out Harakiri on my hex especially as I have an HC-SR04 mounted and practically going unused.

I know it's a big as ask but I don't suppose you could run it run it through translate, reformat it and reproduce it maybe here or in a new thread? as the original author you will know which words have been mistranslated or just plain messed up.

:?:

https://plus.google.com/photos/108235385012513539305/albums/5835563810778487569?authkey=CIK_pffOxYOP2QE

JUERGEN_ · Post by **JUERGEN_** » Sun Mar 24, 2013 11:23 am

timecop wrote:....,
I think powermeter could work, when additional adc is used for sensor (real hw current meter, not fake shit from mw)

what did you think?
an ACS756 :?:

http://www.allegromicro.com/Products/Cu ... CS756.aspx

ADC Pin which is your favorite :?:

Crashpilot1000 · Post by **Crashpilot1000** » Sun Mar 24, 2013 12:20 pm

@Gaijin: Yes, i will try the google translate/edit stuff. And post it the german forum on threadpage one as well. BTW Only Sonar readout is supported, but some Forum - members are already working on it. I will not/can not test it but will implement the code as soon, as they have something working on the line. For normal althold and autoland you will not need sonar in any way. The idea for one of the sonar - guys is to film his windsurfing while the copter is parked over the water, so it will detect a wave and climb. I would recommend someone sitting in a rubberboat for that filming event for many reasons anyway, but that is his idea behind sonar. I think sonar is a big chance of great fail during flight and only suitable for very limited applications and it must always be possible to turn it off.
Cheers Kraut Rob

EDIT: Harakiri9a English Manual online here: http://fpv-treff.de/viewtopic.php?f=18&t=1368#p20580
ToDo: Harakiri10PublicBeta Translation

Gaijin · Post by **Gaijin** » Sun Mar 24, 2013 4:13 pm

Thanks for that, most appreciated.

I agree with you about sonar, and I understand it has limits but I see it as a kind of complimentary sensor when it comes to autoland and terrain hugging, plus it's such a cheap sensor and so trivial to install on the Naze32 I thought, why not.

mr.sneezy · Post by **mr.sneezy** » Mon Mar 25, 2013 9:39 am

Crashpilot1000 wrote:
EDIT: Harakiri9a English Manual online here: http://fpv-treff.de/viewtopic.php?f=18&t=1368#p20580
ToDo: Harakiri10PublicBeta Translation

Hey Rob great job, much much better than Googles raw effort. I can follow that no problem. Looking forward to testing Harakiri10.
Thanks,
Martin

mr.sneezy · Post by **mr.sneezy** » Mon Mar 25, 2013 9:48 am

Hey Rob, a cross forum question about setting mag declination to clarify it.
Quote "would require this command in the cli: set mag_declination = 219 (don't forget "save" afterwards). So it's not like the Multiwii where you have to convert the degrees to decimals."

I have a declination of +8 here in Adelaide. I set the CLI value in BF to 8 (not 800). Should it have been set mag_declination = 800 ?
(in BF and HK ?)

Martin

timecop · Post by **timecop** » Mon Mar 25, 2013 9:50 am

mr.sneezy · Post by **mr.sneezy** » Mon Mar 25, 2013 1:52 pm

Oops. I guess I missed that info somewhere.
(and I learn 'another' new thing about the subject

Martin

Crashpilot1000 · Post by **Crashpilot1000** » Mon Mar 25, 2013 9:51 pm

Thanks for pointing out that possible misunderstanding! I updated the guides in this regard. The translation is now complete but still a little bit "odd" thanks to the google/babelfish base and my laziness ... The weather here is awful (cold and lots of wind). I hope you have better testconditions in Adelaide

Cheers
Rob

mr.sneezy · Post by **mr.sneezy** » Tue Mar 26, 2013 7:42 am

Crashpilot1000 wrote: The weather here is awful (cold and lots of wind). I hope you have better testconditions in Adelaide
Cheers
Rob

Well maybe. It's 36C and 20 knots of wind, typical Adelaide summer/autumn day

mbrak · Post by **mbrak** » Tue Mar 26, 2013 8:29 pm

hi

will the ledring-device(i2c) work with baseflight? i case of yes which version v2 or v3 ?:)
will there be any kind of support für i2c oled displays? they are very useful for trimming parameters on the field without pc or any other kind of transmitting hardware (not everyone has an android device

i use apple). i would not have any transmitter with the same frequency as my rc-tx (2.4ghz)
fpv will work fine on 5.8ghz

thanx michael

cGiesen · Post by **cGiesen** » Tue Mar 26, 2013 8:52 pm

I have an LEDRing to, an make some tests.
I didn't get it running

timecop · Post by **timecop** » Wed Mar 27, 2013 12:20 am

mbrak wrote:hi

will the ledring-device(i2c) work with baseflight? i case of yes which version v2 or v3 ?:)
will there be any kind of support für i2c oled displays? they are very useful for trimming parameters on the field without pc or any other kind of transmitting hardware (not everyone has an android device i use apple). i would not have any transmitter with the same frequency as my rc-tx (2.4ghz)
fpv will work fine on 5.8ghz

thanx michael

ledring i2c used to be in, but will probably be removed as noone uses it. i2c is busy enough doing sensor stuff to have it (ab)used for other shit.
none of "i2c displays" will ever be supported - cli is there and works perfectly fine for same purpose + more.

Crashpilot1000 · Post by **Crashpilot1000** » Thu Mar 28, 2013 3:15 pm

@timecop: Hahaha, totally agree but they want to live up to the very spirit of your company: "... buy it make it fly it abuse it crash it buy it..."

mbrak · Post by **mbrak** » Thu Mar 28, 2013 7:59 pm

@timecop

how can i inverse the z-axis of the acc?

is the a wiki or a doc for the complete set commands?

well guys. have anyone of you tried the oled?

but after grumble some moments i agree with you. it is not really appropriate for all the possible commands. but for quick finetune pids it is very helpful. how do you make this on the flightfield? have you allways a laptop in your pocket? or via bluetooth/android?

cGiesen · Post by **cGiesen** » Thu Mar 28, 2013 10:23 pm

@Timecop

I think there are two errors in CLI

The first one I found:

Code: Select all

typedef struct {
const char *name;
const uint8_t type; // vartype_e
void *ptr;
const int32_t min; [b]<- should be UInt32[/b]
const int32_t max;  [b]<- should be UInt32[/b]
} clivalue_t;

The second one I'm still searching.
I want to enter FFFFFFFF (as decimal value of course) but that didn't work.
Did you have an idea?

nicog · Post by **nicog** » Fri Mar 29, 2013 6:16 am

I have the answer for you, naze32 configurator for android.
It has all you need when in the field. Cli management and all.

timecop · Post by **timecop** » Fri Mar 29, 2013 8:02 am

cGiesen wrote:@Timecop

I think there are two errors in CLI

The first one I found:
Code: Select all
typedef struct {
const char *name;
const uint8_t type; // vartype_e
void *ptr;
const int32_t min; [b]<- should be UInt32[/b]
const int32_t max;  [b]<- should be UInt32[/b]
} clivalue_t;
The second one I'm still searching.
I want to enter FFFFFFFF (as decimal value of course) but that didn't work.
Did you have an idea?

pretty sure int32 was chosen to allow negative values.
And it should work for that.

cGiesen · Post by **cGiesen** » Fri Mar 29, 2013 10:06 am

@Timecop
For int32 that works.
But if your read, I want to enter an UInt32 value! (FFFFFFFF)
Now I can enter this value, but it's not stored!
When I set this value by code (Default Values) s´that works!

Perhaps it's not an Error, it's 'only' an enhancement...

timecop · Post by **timecop** » Fri Mar 29, 2013 10:33 am

Why? What is this value for?

cGiesen · Post by **cGiesen** » Fri Mar 29, 2013 10:56 am

I have add LED Toggle fiendie told me from.
And there is a value to define the toggle pattern.
This value is UInt32. In the original code, this pattern ist hardcode, but I want to change this value by CLI.
I know, an nice to have only

timecop · Post by **timecop** » Fri Mar 29, 2013 1:19 pm

You could always split it across 2 uint16's

how can i inverse the z-axis of the acc?
is the a wiki or a doc for the complete set commands?

z-axis = probably using align stuff, but you'll have to do all other sensors too
set = all inside cli.c

Gaijin · Post by **Gaijin** » Fri Mar 29, 2013 6:39 pm

Hey Crashpilot,

Great work on Harakiri, it flys nice and precise if a little soft on default PID's, needs some tuning for me but too cold for that at the moment!

Also impressed with autoland from height hold, one flaw, my Hex is high up on landing gear and bounced and tipped over inverting it, copter went a bit mental turning into a carbon fibre lawn mower, no harm, just need to watch it.

Finally, testing Pos hold resulted in the copter developing an extreme bank and accelerating off forcing an abort, presumably as it tried to navigate to it's imagined position far from where it actually is.
I've had this before with baseflight but never discovered why, with r288 it worked, is it because the magnetic declination is negative here (-1.34) forcing a positioning error.
Any suggestions to fix it, I daren't try RTL until I tame it.

Still, very impressive work

Crashpilot1000 · Post by **Crashpilot1000** » Fri Mar 29, 2013 7:11 pm

@Gaijin: Hi! Thank you very much for your feedback! The Autoland can be problematic for copters with high landing gear because it can tip over. The main reason for this is the baro going crazy in groundeffect (not the acc, like i firstly assumed). The Autoland is more an emergency feature but i use it everytime with my copter (has low groundclearance). You can reduce this effect by reducing Alt P and I. I think your copter has more power than mine so that might be reasonable anyway

. When tilting the "Alt D" will increase throttle to compensate .... i your case: perfect lawn mower
The PH: Yes i think you have some serious mag stuff at play there. The sign of the mag declination is interpreted correctly in the code (uses float point). The mag declination must be put in the cli without the "." in your case: "set mag_declination = -134". When the copter wants to fly to bonanza just put Pos P to zero. Than the copter doesn't know its position at all but it will break movements with the Pos "I" (1.0 default). When you see the copter not breaking in PH and increasing the speed than you have a severe MAG Problem (probably Disturbance) when you see it doing circles the "I" may be to high or you have a slight disturbance of the mag.
Keep it coming!

Cheers
Kraut Rob

P.s.: Hopefully you didn't wreck some expensive props...

Gaijin · Post by **Gaijin** » Sat Mar 30, 2013 10:09 am

No problem's there, the rctimer carbon fibre props are much tougher than the epp slowflys (I don't trust them anymore they snap at the blade root)

2nd test flight, different location, magnetometer re-calibrated, this time without motors running as I was once advised.

Pos hold P set to 0, held position very well

Try again, Pos hold set back to 1, seems to work well, less drift than above but with some circling, i'll try reducing the I term.

how much difference does the magnetic declination really make, I fly at various sites within 15 miles of each other, do I really need to re-set the mag dec for every site?

Still, very impressed, could this lead to waypoint navigation?

Crashpilot1000 · Post by **Crashpilot1000** » Sat Mar 30, 2013 6:03 pm

@Gaijin: Hi! Thanky you for rechecking this stuff! The magnetometer is a very decisive part in GPS functions and i didn't dare to test it without setting the right magnetic declination, so i don't know how much the difference is.
The Parameters PosHold P and I are independent. When one parameter introduces circeling it is mainly that value... changing the other might help. Yes, the drift is controlled by poshold P because only that parameter "knows" the actual position the "dumb" poshold "I" just deals with fighting x/y movements without knowing the absolute position at all.
RTL is wp navigation, but i know what you mean. Yes it's on the line. cGiesens GUI already deals with some WP but the code is still missing because there are also some safety concerns as well and the implementation has to be thought through...
Cheers Kraut Rob

felixrising · Post by **felixrising** » Mon Apr 08, 2013 6:02 am

Hi,

I'm still waiting for my naze32 and a couple of afro mini 32's to arrive, so doing a bit of research, one thing I'm wondering is how best to get some of the features I've been playing with onto these more powerful boards.. namely I've been using nhadrian's "Altitude Hold/Advanced Failsafe solutions by NHA" which do some funky stuff like altitude vario, RTH+Land as well as a failsafe routine which also RTH+Land with vario. It's pretty nice, and a huge improvement over the default failsafe of minthrottle+some number and cross your fingers. What's the best way to realise features likes this.. assuming that I'm not a programmer.

Cheers Felix

timecop · Post by **timecop** » Mon Apr 08, 2013 6:09 am

By purchasing a DJI NAZA. maybe you want to try the german firmware, or learn how to C.
Or maybe convince those guys who are still playing on the end-of-life 8bit platforms to move on.

felixrising · Post by **felixrising** » Mon Apr 08, 2013 6:22 am

NAZA?! NEVER!!! I think there will always be people who like to cram in as much code as possible into the tiny controllers, but at least you've got some nice hardware at a reasonable price (I'm looking at you Autoquad 6) to give people an incentive to move to 32 bit. Anyway, it's cool to see the feature-set of multiwii getting advanced and improved on all fronts (features, hardware, algorithm), that's what's great about OSS.

Crashpilot1000 · Post by **Crashpilot1000** » Mon Apr 08, 2013 8:22 pm

@felixrising: Hi! I currently did a lot of work in the failsafe area. The problem was that "Hinkel" had some FS Problem with a 35Mhz Corona RX. The problem was that on TX signal loss his RX did not send continiously "nothing" but every 15 secs ONE correct RX frame. So FS stopped, re-engaged, stopped, re-engaged ...... Some RX just keep sending their last input till the end of time or catching valid TX signals again. To circumvent this i introduced "failsafe_deadpilot" that is a timeout in seconds (0 disables function). So when no stickinputs for a predefined time (lets say 60 secs) a problem is assumed and a FS is engaged. failsafe_deadpilot is beta because it is not checking if the copter is already doing an automatic mode. So when you set failsafe_deadpilot and do a PH without stickinputs and exceed the timeout the FS will engage (preset: climb to 20 m, RTL, autoland). So the Harakiri 10 Beta with revised FS is called "Hinkel4" (because it took 4 revisions to fix that corona FS sh**, btw hinkel4 also includes support for the mwii - simple - serial - sparkfun LCD http://www.youtube.com/watch?v=1A5eGQ85y30& - not everyone is on fancy BT/Android stuff) here is the link: http://fpv-treff.de/viewtopic.php?f=18& ... 600#p26298.

Cheers Kraut Rob

EDIT: I found better INS values for Harakiri10beta / Hinkel4
Default is:
gps_ins_vel = 0.8
gps_ins_pos = 0.7

But
better is:
gps_ins_vel = 0.7
gps_ins_pos = 0.84

cGiesen · Post by **cGiesen** » Mon Apr 08, 2013 9:18 pm

@Timecop
could you please give me an example, how I can use PIN RC2 as an Servo output and how I can write data to it?
Your is it better to use RC5 or RC6?

Thanks
Carsten

timecop · Post by **timecop** » Tue Apr 09, 2013 1:58 am

RC2 you'd have to change code.
RC5678 in PPM mode you just enable servo mirror and writeservo.

cGiesen · Post by **cGiesen** » Tue Apr 09, 2013 6:49 am

RC6 I have free.

Can you give me an example?
Or cn you say where i have to look?

timecop · Post by **timecop** » Tue Apr 09, 2013 3:28 pm

Code: Select all

        } else if (mask & TYPE_S) {
            servos[numServos++] = pwmOutConfig(port, 1000000 / init->servoPwmRate, PULSE_1MS);
        }

servos[] array will be setup if port mask is TYPE_S (servo). Based on params passed to initPWM, a map (multiPPM, multiPWM, etc) is loaded, and then looped through to initialize motor and servo outputs. when certain gimbal_flags are set (see where initPWM is called), additional servos are added if in PPM mode.