MultiWii

btw, my bluetooth module is connected to the middle of the naze board, but if it work I will do a Y cable. this should work.

sn0west wrote:btw, my bluetooth module is connected to the middle of the naze board, but if it work I will do a Y cable. this should work.

It's a funny thing, sometimes I get to select the telemetry type in the Telemetry page of the Taranis ... and sometimes the selection is not there ...
I suppose your Rx is binded (D16) and that all your radio channels work ? Did you try your copter as well ?
You don't need the Lua script to test your telemetry. Go to the Telemetry page and select vfas (voltage) and ACCX, ACCY and ACCZ. That's an easy way to see if you're getting telem data.

Hei it's working! I get now telemetry informations! Yes!!

Now I have to setup the right values for battery monitoring, wich is not easy I think. I have to read a lot to understand it now , but this is part of the game.

Thanks for your help!!

According to the OSD, one of the telemetry info is the number of satellites locked in.

I've yet to find how to display it on Taranis.

Actually, I'm after some sort of indicator for GPS position deviation because solid GPS hold req'd good converged deviation, which doesn't happen until some 20sec or more after the 6 th sat is acquired. If I was to fly just after the 6th sat, it would move around much more while in PH. If it gets to 7 to 9 sats, the deviation (3D accuracy shown on u-center) would converge very quickly. Sometimes, especially during winter, in my suburban area, it will stuck at the 6th sat for 1-2 minutes.

Right now, the only clue is to watch the least significant digit in coordinate numbers.

sn0west wrote:Hei it's working! I get now telemetry informations! Yes!!

Now I have to setup the right values for battery monitoring, wich is not easy I think. I have to read a lot to understand it now , but this is part of the game.

Thanks for your help!!

If you plug your lipo to the 'batt' header of the Naze, you will get the voltage via 'vfas' on the Taranis. If you want to use an external sensor and 'daisy chain' the sensor with your Teensy, the voltage will show as Cell and Cells. In this case it displays what is measured by the sensor : no adjustment necessary.

leocopter wrote:If you plug your lipo to the 'batt' header of the Naze, you will get the voltage via 'vfas' on the Taranis. If you want to use an external sensor and 'daisy chain' the sensor with your Teensy, the voltage will show as Cell and Cells. In this case it displays what is measured by the sensor : no adjustment necessary.

My Naze32 is powerd over the esc. So how can I plug it to the vbat port? And if I understand what you wrote, this will automaticly show me the cells of my 3s lipo?

I tried this today, but with no succsess unfortunaly.
https://github.com/wolkstein/MavLink_Fr ... ge-monitor
If anyone knows how to monitor the cells on my taranis, pleases feel free to tell me how to do it.

sn0west wrote:

leocopter wrote:If you plug your lipo to the 'batt' header of the Naze, you will get the voltage via 'vfas' on the Taranis. If you want to use an external sensor and 'daisy chain' the sensor with your Teensy, the voltage will show as Cell and Cells. In this case it displays what is measured by the sensor : no adjustment necessary.

My Naze32 is powerd over the esc. So how can I plug it to the vbat port? And if I understand what you wrote, this will automaticly show me the cells of my 3s lipo?

I tried this today, but with no succsess unfortunaly.
https://github.com/wolkstein/MavLink_Fr ... ge-monitor
If anyone knows how to monitor the cells on my taranis, pleases feel free to tell me how to do it.

OK, I'll try to be more precise ...

1- Plug a lead to your lipo (up to at least 4 S ... so your 3S is OK) to the 'bat' header of the Naze. Check the polarity of the plug to avoid frying your board ... Your board is powered by your ESC. No problem. In that scenario, you will monitor the voltage with the Vfas variable in the telemetry panel of the Taranis (if that does not work check the 'Batt' variable). In this case you plug the lipo directly to the Naze32 (I can handle it ... go and see the manual at Abusemark).

Or

2- Use the http://www.getfpv.com/frsky-flvss-lipo- ... tport.html FRSKY voltage sensor with Smart Port : plug it to the balance plug of your lipo and get the voltage of each individual cell ... You can display 'Cell' in your Taranis (that will give you the LOWEST cell voltage of the pack) and also 'Cells' (that will show the TOTAL voltage of the lipo). In this case you don't plug the lipo to the board. The voltage measured by the sensor is sent to the board as telemetry data.

I have all these scenarios setup in different copters. They all work very well.

I hope this helps !

Chris

Spotter6 wrote:According to the OSD, one of the telemetry info is the number of satellites locked in.

I've yet to find how to display it on Taranis.

Actually, I'm after some sort of indicator for GPS position deviation because solid GPS hold req'd good converged deviation, which doesn't happen until some 20sec or more after the 6 th sat is acquired. If I was to fly just after the 6th sat, it would move around much more while in PH. If it gets to 7 to 9 sats, the deviation (3D accuracy shown on u-center) would converge very quickly. Sometimes, especially during winter, in my suburban area, it will stuck at the 6th sat for 1-2 minutes.

Right now, the only clue is to watch the least significant digit in coordinate numbers.

I guess this isn't what you are looking for : http://www.hobbyking.com/hobbyking/stor ... _1pc_.html
... but It could be handy to find a lost quad ...

Crashpilot1000 wrote:Sorry, dudes for not doing any copterstuff at all in the last couple of months... GPS is always optional and loosing faith in GPS is actually a good thing, because no FC in the world (I know they advertise it the other way) can compensate for flaky GPS signals over time without further sensorsets (airspeed, optical devices etc..). If trash GPS signals are detected (bad reception, most likely in urban areas etc and def. expected with no gps groundplate) Harakiri will disable the current GPS flightmode and you are stuck with what you have defined when that GPS function is turned off. If the flightmode is gyro/acro it will drop down to that so it is highly recommended to tick the auxbox levelmode along with your gps functions so it will fall back to level mode - that is actually necessary in multiwii all the time and you will see no gps functions at all working without ticked level mode - however harakiri automatically activates levelmode along with gps functions to make them happen, but a fallback can bring you back to gyro only if not defined otherwise in the gui. A general word on the magnetometer. When powered up the magnetometer gathers the strength of the magnetic field of each axis. This procedure is done on every powerup cycle and must not be influenced (like putting the copter on your car/metal plate during powerup)! Once this is done the so called GAINS are stored and then corrected with the OFFSETS you gather up during the mag calibration process. OK. The magnetometer can be set to different SENSITIVITIES. Harakiri uses the HMC devices with their highest sensitivity to get the most precision out of it for gps functions. However that sensitivity is not needed for the "Headfree" mode so you can change the magnetometer sensitivity in the CLI:

Code: Select all

Default (1.9 GAUSS): 
set mag_gain = 0
or
set mag_gain = 1 (2.5 GAUSS for problematic copters)

So you have a chance on mag-troubled-setups, I would not recommed the 2.5 GAUSS setting for GPS use. You must recalibrate the mag when changing the sensitivity.
Cheers Rob

Hey Rob,
great to see you posting again! Do you plan to continue the Harakiri project? There are some great ideas and features here and the idea of being discontinued is sad sad news.

Cheers!

leocopter wrote:

Spotter6 wrote:According to the OSD, one of the telemetry info is the number of satellites locked in.

I've yet to find how to display it on Taranis.

Actually, I'm after some sort of indicator for GPS position deviation because solid GPS hold req'd good converged deviation, which doesn't happen until some 20sec or more after the 6 th sat is acquired. If I was to fly just after the 6th sat, it would move around much more while in PH. If it gets to 7 to 9 sats, the deviation (3D accuracy shown on u-center) would converge very quickly. Sometimes, especially during winter, in my suburban area, it will stuck at the 6th sat for 1-2 minutes.

Right now, the only clue is to watch the least significant digit in coordinate numbers.

I guess this isn't what you are looking for : http://www.hobbyking.com/hobbyking/stor ... _1pc_.html
... but It could be handy to find a lost quad ...

Thanks. I do have that, all FrSky units to X8R, on one of my Quads. It only feed basic info (location coord., speed, altitude, etc.) but no SV count that I can find. Perhaps, it's possible if you'd get deeper into FrSky codes or LUA scripts. I will try posting at FrSky threads to see if it can get into their radar screen.

My purpose to post here is to point out that just because you've met SV count requirement of 6 only moments ago, you shouldn't expect immediate solid GPS Hold, simply because the remnant of deviation on exact location is still trying to converge. It would take sometime for it to converge, an issue all GPS receivers face.

@Spotter : I get it. Mavlink does provide the number of sats doesn't it ? If FRSKY telem does not, wouldn't it be possible to replace a FRSKY telem variable you don't need with the number of sats variable ? You might find more info on how to do this in the LUA scripts and the Arduino files of the different Mavlink to FRSKY converter (for APM) projects (one is for the Pro Mini and the other is for the Teensy board).

What's the status on spectrum satellite rx?
IS PPM the way to get more than 6 channels and gps?

No softserial in Harakiri so sumsignal is needed for gps functions.

Does missions work?
I have loaded waypoints whit MissionPlanner but noting happens when I select GPSAUTO.

I am sorry to say missions don't work and I see no way for me to do so. I've done some amount of work on that subject (the PDF that shows how the logic should work etc) and there is also a considerable amount of code behing that (communicating with missionplaner, plausibility checks of uploaded missions/correcting mission design user errors, developing a "ramdisk" for storage/read/write functions) however I am missing the right surroundings here for further development. That means a (club)house (with 220V power) and a field with OK weather for 2 weeks. Driving over by car to some field will not do it, because of the coding.. The place where I live is surrounded by airports so everything here is more or less a "grey" zone. The local RC club gave me a very warm "you are not welcome" because they are a bunch of elderly guys that fly big scale models worth thousands of euros, they even don't like normal 450 sized helicopters. I was told that the club is already full and they have a hard time handling all those ppl that want to fly on the weekends.. ok. So all my flying is done in some "grey zone" here (fly a few lipos, pack together and drive away..). So that doesn't really make me too happy. So I am currently doing some code that I can test in my backyard for fittness and take it to the field. It is baro and gps related, lets see how it works out - but that is mainly based on the topics: gps safety, autotuning and checking out ublx8, not missions.

Ok. God to know. Then i can stop trying to get it to work.
Oh so there is some coding going on. Exiting news. Anyting you what help testing?

Crashpilot1000 wrote:I am sorry to say missions don't work and I see no way for me to do so. I've done some amount of work on that subject (the PDF that shows how the logic should work etc) and there is also a considerable amount of code behing that (communicating with missionplaner, plausibility checks of uploaded missions/correcting mission design user errors, developing a "ramdisk" for storage/read/write functions) however I am missing the right surroundings here for further development. That means a (club)house (with 220V power) and a field with OK weather for 2 weeks. Driving over by car to some field will not do it, because of the coding.. The place where I live is surrounded by airports so everything here is more or less a "grey" zone. The local RC club gave me a very warm "you are not welcome" because they are a bunch of elderly guys that fly big scale models worth thousands of euros, they even don't like normal 450 sized helicopters. I was told that the club is already full and they have a hard time handling all those ppl that want to fly on the weekends.. ok. So all my flying is done in some "grey zone" here (fly a few lipos, pack together and drive away..). So that doesn't really make me too happy. So I am currently doing some code that I can test in my backyard for fittness and take it to the field. It is baro and gps related, lets see how it works out - but that is mainly based on the topics: gps safety, autotuning and checking out ublx8, not missions.

Nice to see you doing some development again Rob. You doing this on your Harakiri FW or are you considering fixing stuff on Cleanflight? I think they could use your help Wow that RC club sound like they're not worth it.

Not sure I'm in the right place for this issue, but here goes...

I've been running Harakiri for some time now. Don't have any big issues with it, except one. (Two, maybe...)

Yaw: when I drop the stick, whether rotating clockwise or counterclockwise, it always stops movement and rotates clockwise just a bit. I've tried tuning the Yaw PID's, but that doesn't seem to change this. Is there something else I should be looking at? Hardware related instead of software? I'm trying to film some aerial footage and it always shows up on video.

Second, my magnetometer doesn't point to true north, as far as I can tell (the above yaw issue is there when Mag is off). I've looked up the inclination for my area, set that. I've also recalibrated it multiple times. I'm wondering if I need to ditch the board mounted unit and go external.

Here's my current setup.

@Hoppsan_84: Currently optimizing some mavlink stuff, but I will keep you posted. I think I will be doing WP stuff BUT it will be most probably not tested. AKA if something goes wrong, you better know how to fly and be quick on the switch to flip back to a normal flightmode... But a BIG warning will surround that hexfile.
@strips: Yep, trying to help with cleanflight as well but I have a hard time finding stuff in all these files and that is timeconsuming. BTW: I don't judge upon that RC club, since they have their own opinions and I wouldn't blend in into that circle anyway.
@Litneon: Well, first of all yaw on multirotors (>3 motors) is the Achilles' heel.
Problems can occur on these levels:
RC: Check if you don't have any trims set in your transmitter for yaw. AKA Stickcenter should be around 1500us
Vibration: As always should be minimized, and always put a few layers of foamtape under the FC.
Motor/Frame: Jammed Motors (failing bearings etc), Flightcontrol too far off the rotational center.
Softwareside: Yaw controller, mixer, minimal throttle too high? (esc_min = 1100 https://github.com/Crashpilot1000/TestC ... fig.c#L225), I-term too high?

Concerning the magnetometer: If you enable it just for heading hold or headfree, the mag declination is irrelevant. The mag declinations' sole purpose is to align the compass (defined by sattelites) of the gps with the compass on your copter.

The software has a few options you can try out to fix or track down the problem:
"rc_oldyw" (https://github.com/Crashpilot1000/TestC ... fig.c#L212) This is set to "0" that means it uses the mwii2.3 yaw algo. By typing "set rc_oldyw = 1" (don't forget "save"..) you can activate the yaw PID controller that was used before.
The mixer is also changed but you can also fall back to the original mwii mixer with "set esc_nwmx = 0" (https://github.com/Crashpilot1000/TestC ... fig.c#L231). Setting "set esc_nwmx = 1" is the default state.
Troubleshooting motors/center of gravity:
Just hover your copter for a minute and land/disarm but don't unpower it. Now connect to your PC and enter CLI. Then type "status". You will be confronted with some data and the last dataset shows the statistics of the motors. They will look something like this: https://github.com/Crashpilot1000/TestC ... rStats.gif. If the session usage of one of the motors is too high - it has a mechanical problem or has to work too much due to weight distribution.
I hope something of this is useful for you!
Cheers Rob

Wow. Great information, thanks! I'll let you know what I find.

I know my stick center is at 1500, my yaw PID's are 5.0,0.040, and 30. I've tried every combination of the three that I could which was making me wonder if I was barking up the wrong tree.

I'll do some searching on the mixer and my rotational center. I imagine that my dead cat setup has some different characteristics than a standard x quad. But my Flip board didn't have the same issue mounted in the same location.

Well, here is my status... This could be the problem.

Motor:
Actual Range: 1050 - 1950 at 400 Hz PWM.
Mot: 1 Session Usage: 26% Abs PWM: 1456 Rel to PWM range: 45%
Mot: 2 Session Usage: 24% Abs PWM: 1430 Rel to PWM range: 42%
Mot: 3 Session Usage: 17% Abs PWM: 1316 Rel to PWM range: 29%
Mot: 4 Session Usage: 31% Abs PWM: 1526 Rel to PWM range: 52%


This was a short hover in the driveway, looks as if Motor 3 could have some extra drag?

On second thought, maybe Motor 3 is compensating for something? Not sure what to make of this status.

Thank you very much for doing that test.
If you put the numbers into the picture of the TC manual you end up with the attached picture.
There are a few things to mention.
You copter is not underpowered/too heavy since it is hovering below 50% (probably at 44% when imbalance removed).
The distribution of the workload during your hoversession should be around 25% per motor since it is a quadcopter .
If the copter was fighting a constant yaw error you would see problems on diagonal motors and that doesn't seem to be the case.
The flightcontrol wants motor 4 (front left) to work much harder and motor 3 much less (the absolute difference between them is 23%!).
You have probably already checked motor 4 if it's running freely/lifting the bell on the shaft etc? Please check the weight distribution (shift the lipo around). It's hard to tell from your photo, but the arms have the same length?

Concerning the Yaw PID: Both (old and new) are just P+I controller the D-term is not used as dampening element. The "new one" (that is default) abuses a D-term value as a limiter for the yaw P-term. So keep yaw D at zero (no limit).
When you have balanced the workload of your motors you can put G-Tune on a switch and see with what P values it comes up (they are not saved, unless you cast an eeprom write)
Cheers Rob

EDIT 27 Feb: Note: The sum of the "Session Usage" should sum up to 100% (since a session is 100%). However the calculation is done and printed out in integer omitting fractional digits without doing correct up/down rounding. As a result the maximal error is give and take 1 per motor. In this example the sum is 98% not 100% but that is ok for a troubleshooting purpose. So don't get mad if you can't get all motors on a quad running at 25%... just saying.

Hmm. Ok, that sheds some light on this.

Here is another angle of the quad from my last FC setup. While the GPS was mounted, it wasn't operational at the time.



All the arms are the same length, but the addition of the gimbal in the front, has made it nose heavy. The CG is still 20-25mm forward of the intersection of the lines from the motor hubs. I actually expect the forward motors to need to run more to account for this, but until now didn't know how to check to see what "normal" was.

I'll check the motors in depth and see what I find. What are the chances a speed controller could cause this issue?

I checked the motors just a bit ago. None seem to have any more drag than the rest. Hmmm.

Dude, it is IMHO def. a problem with your weight distribution (COG) of your copter. Try the softwareoptions I mentioned within Harakiri, or install Baseflight or Cleanflight or whatever but shift the lipo around to even out your motorload (probably put it more on the right and a little backwards). COG problems will always be your enemy if not resolved. The motorstats are a simple tool for checking and adjusting your machine.

Ok, I'll try removing the gimbal and going back to my original setup. I haven't been overly happy with the gimbal setup anyway. I have my battery as far to the rear as I can get it, with the original battery tray/camera mount reversed, but I thought that to some extent the FC would correct for differences in CG.

I think there may be something else going on here. I added weight to the rear (in the form of an extra 3s), which obviously requires more throttle to hover, but the yaw is still acting strange. The motor status looks better, but still not even. I'll check in the Flite Test forum and see if anyone else is having this problem with their quads that are setup similar to this. I did notice some serious twitching going on between 1 and 4 when hovering while it was trying to maintain balance. Maybe there is a problem with one of those two ESC/motors that is causing one of them to correct for the other?

Motor:
Actual Range: 1050 - 1950 at 400 Hz PWM.
Mot: 1 Session Usage: 27% Abs PWM: 1519 Rel to PWM range: 52%
Mot: 2 Session Usage: 22% Abs PWM: 1432 Rel to PWM range: 42%
Mot: 3 Session Usage: 21% Abs PWM: 1414 Rel to PWM range: 40%
Mot: 4 Session Usage: 27% Abs PWM: 1521 Rel to PWM range: 52%

I you look at the picture again with your "no gimbal numbers" you will see that you have differences on diagonal axes, that means a constant yaw error (probably motortilt) that was masked before with the additional gimbal weight. BTW/just for your information: If you want to recalibrate your 4 esc at once you can do that with feature pass (turn it off with "feature -pass").

Upon further inspection, there is indeed a slight twist to one of the booms. Good call Crash!

Crashpilot1000 wrote:@Hoppsan_84: Currently optimizing some mavlink stuff, but I will keep you posted. I think I will be doing WP stuff BUT it will be most probably not tested. AKA if something goes wrong, you better know how to fly and be quick on the switch to flip back to a normal flightmode... But a BIG warning will surround that hexfile.

Hi Crashpilot1000 !
This is very interesting to see that you are still looking forward , I have one test quad to improve your stuff !
i am still loving all this Harakiri great development " it is simply the best " !

Regards
hinkel

OK, I have been distracted for some time, got into building 3D printers...

I have found a really nice way to use mavlink....and its VERY reliable via OpenLRS @ 19200 baud. I have never seen data so reliable via OpenLRS before! The only thing I have not tried, is to flash....LOL.

First I bought some new modules, and followed this site.
http://www.itluxembourg.lu/site/

Then I even installed a bluetooth HC06 inside the TX module so I could connect via my android. After trying different programs on the android, I realized I would have an issue with having to arm, and then the serial stream switched to mavlink....Bluetooth has to be set to 115200. Also, I should mention, in Harakiri, serial speed set to 19200 and mavlink type set to 2 to match baud rate of serial.

so, eventually I tried droidplanner
https://play.google.com/store/apps/deta ... nner&hl=en

I was trying to find a program that would just connect bluetooth, but go directly into mavlink. I needed statically set it to use one specific bluetooth and change the baud as well. It did, but I found another really neat thing, if you go settings, it will list ALL the options from Harakiri (everything available in CLI) , and you can even change them and send it back and it programs perfectly into the FC. I have had no conflicts, yet....if I do I will post.

Perfect.....now I am printing a bracket so i can snap my phone onto my monitor on my RC-TX.......Its very nice looking and has all the information you could ever wish for from the mavlink. I really enjoy the voice prompts, especially for battery warning. I have had NO dis-connects with the bluetooth and it is VERY reliable and now has the same range as my OpenLRS due to sending the packets over the same TX module. Also another advantage is I dont need a dedicated TX for telemetry!

If I crash, my android will display my current position, and last position update at the same time, so I can go directly to where the unit was. Very nice, but lets hope I dont have to test that to often.....LOL.

Just too simple, and works VERY well for me so I had to share. Take care everyone.

That's very cool, Mr-Fiero !
I'm going through the process of configuring UltimateLRS myself. What sketch are you using in Thingiverse for your bracket?
Also you might be interested in Ghetto Station (I'm waiting for mine from the UK). With Guetto Station Proxy (a flashed Mini Micro that converts different telem protocols to a 'light telemetry' protocol : LTM suitable for 1200 and 2400 baud transmissions) you can use the Audio channel of your FPV transmitter to send the telemetry data to the ground station where it is decoded by a FSK modem (using an old TCM3105 TI chip). You can find the FSK modem schematics on kha's Github : kh4 or buy it direct from him (in Finland). Kha is the maintainer of OpenLRSng. Guetto Station is a 3D printed antenna tracker with a built in LCD screen for easy config. With the Guetto Proxy board, you can use only one OSD in the ground station instead of multiple OSDs in your planes/copters. It works with Mavlink, UAVtalk, MSP, Ublox and NMEA protocols (on the To-do list : FRSKY ...) : https://github.com/KipK/Ghettostation

Hi Rob,
can you tell me how well PatrikE's airplane mode (with PH and RTH) is implemented in Harakiri ? (http://fotoflygarn.blogspot.ca/2012/03/ ... -same.html )

@hinkel: Thank you very much! But other firmwares have their ups and downs as well!
@Mr-Fiero: Also big thanks to you for testing mavlink compatibility with that droidplanner! Good to know, maybe I should buy some tablet as well.. I am afraid that those Hobbyking 1000mW modules are way off legality at my place - so def. no option for me, damn. BTW. As long as the baudrates match, you can drive minimosd (mavlink, only hooked onto the TX cable, working in listening mode) and your Telemetry on the same serial port.
@leocopter: Actually I am currently reducing the codesize. So no, airplane is not taken special care of. It may work for basic stabilization. And will be most probably removed completely to shove off some bytes. IMHO it is better to do a different firmware for planes alone (my autoland and autostart logic will not work on planes etc.). viewtopic.php?f=8&t=364&start=500 PatrikE has put in much work into the plane part already, so it would be best to start from his work for a stm port. As far as I know he already merged a lot of his work into Baseflight (viewtopic.php?f=23&t=4934). Since I don't know much about the airplane subject (my plane is still unflown..) check out Baseflight and probably Cleanflight to get further info on that topic. Checking out paparazzi (http://wiki.paparazziuav.org/wiki/Main_Page) for some ideas on airplane core logic might be also fruitful when putting together an airplane firmware.

@Mr-Fiero Cool.

Just to be clear. You have to talk ppm to the TX? Got ppm going out from my trainer port so I guess I will connect the Orange module thru that.
What's the range for the 100mw version? 4km sounds like overkill.

@Rob, Ok then I'll stick to MWI and BF for airplanes for now. I got carried away with the FliteTest models and I'm building like crazy flat nose flying wings (for 5$ of Dollar Store foam ...), twin engine models and warbirds ... It gives me a break from my multirotor obsession !
Harakiri flies really well, last summer for the first time I got true PH (I'd been struggling with it for months). Your telemetry handling is simple and effective and we get Mavlink ! So thanks again for that. I have had great success with Harakiri + Frsky telem. Also, I've been using the trick you mentioned by hijacking the Tx signal (with a Y connector) to get Mavlink telem via a 3DR radio + OSD at the same time. Works great.
Cheers,
Chris

P.S : if you're trimming down the code, is there any chance of moving up the the latest BF or CF code base ? It would be a big plus to have Softserial and ... an up to date GUI. Just a thought

Hoppsan_84 wrote:@Mr-Fiero Cool.

Just to be clear. You have to talk ppm to the TX? Got ppm going out from my trainer port so I guess I will connect the Orange module thru that.
What's the range for the 100mw version? 4km sounds like overkill.

The Ultimate LRS system from IT Luxembourg uses 2 X Orange 1W Tx (to get maximum range telemetry). If you use a 100mw Rx you'll have the full range for RC but not for telemetry. More important than power is a good (matched) antenna. Consider a Yagi (or moxon) antenna for the transmitter and at least a good dipole on the aircraft.You'll find useful links for that on the IT Luxembourg site. For the video, consider an antenna tracker (Ghetto Station ?) or a 'Pepper box' from IBCrazy : http://www.readymaderc.com/store/index. ... s_id=1288' . Now the Orange '1 W' Tx does not output 1 W ... more in the range of 400 mw from my research. If you want a very good LRS system, consider DTF UHF. Their stuff is high quality, well filtered and delivers true 1 w power ... but it does not work with the Ultimate LRS firmware and you'll have to use OpenLRSng.
@Mr-Fiero, what is your video setup for long rang FPV ?

leocopter wrote:P.S : if you're trimming down the code, is there any chance of moving up the the latest BF or CF code base ? It would be a big plus to have Softserial and ... an up to date GUI. Just a thought

I will not change to CF or BF trunc any time soon. There are some pitfalls coupled with them I don't want to have on my copters. As said, Harakiri is just the stuff I fly and the code is published. So it mainly contains stuff I need/want and you are free to use it or not, or take the code you find useful and integrate into something more fancy. Within the integration/BF pullrequest of the Frsky 18ms fix I found some troubled code concerning the failsafe handling in Baseflight that needed a redesign - maybe Cleanflight as well - I don't know. All I want to have is a solid flying machine with a working failsafe that doesn't put me out of control. Since I have limited understanding and no oscilloscope or further advanced debugging stuff I stick with what definitely works. I will not play around with the hardwaretimers or additionally flood the tiny cpu with interrupts every few microseconds to enable some softserial / telemetry that has a good chance in my eyes to wreck the rest. Cleanflight has done some astonishing things concerning portability but if you need more serial ports for some reason you should look at hardware (like Quanton etc) that provides them without some softserial functions that's just my point of view (and it might be completely wrong). Other copter projects use dedicated cpus to handle additional load for some reason I don't want to find out that reason in mid air.

Crashpilot1000 wrote:

leocopter wrote:P.S : if you're trimming down the code, is there any chance of moving up the the latest BF or CF code base ? It would be a big plus to have Softserial and ... an up to date GUI. Just a thought

I will not change to CF or BF trunc any time soon. There are some pitfalls coupled with them I don't want to have on my copters. As said, Harakiri is just the stuff I fly and the code is published. So it mainly contains stuff I need/want and you are free to use it or not, or take the code you find useful and integrate into something more fancy. Within the integration/BF pullrequest of the Frsky 18ms fix I found some troubled code concerning the failsafe handling in Baseflight that needed a redesign - maybe Cleanflight as well - I don't know. All I want to have is a solid flying machine with a working failsafe that doesn't put me out of control. Since I have limited understanding and no oscilloscope or further advanced debugging stuff I stick with what definitely works. I will not play around with the hardwaretimers or additionally flood the tiny cpu with interrupts every few microseconds to enable some softserial / telemetry that has a good chance in my eyes to wreck the rest. Cleanflight has done some astonishing things concerning portability but if you need more serial ports for some reason you should look at hardware (like Quanton etc) that provides them without some softserial functions that's just my point of view (and it might be completely wrong). Other copter projects use dedicated cpus to handle additional load for some reason I don't want to find out that reason in mid air.

All I can say, Rob, is thank you for sharing Harakiri with us. It flies very well. I think everyone appreciates the work you have done, especially for PH and RTH. I do use BF or CF on other stuff (planes, smaller copters usually without GPS ... or to reflash CC3D boards ...).
I did have a question concerning fs_ddplt.Will it kick in if it is enabled and I'm several seconds in PH without any input (on my part) from the Tx ? or is it disabled in PH mode ?
Thanks again,
Chris

No problem! The Deadpilot function will kick in in EVERY flightmode, if feature failsafe is set and a time in seconds is set fs_ddplt = X (0 - 250, "0" disables deadpilot). This function is mainly for RX that have no special failsafe functions and keep sending the same signals while being out of range. These sicks are monitored for being idle/not moved: roll/pitch/yaw/throttle.

Quick question about baro mode.

When I turn baro on the copter drops some height and settles on that lower height. I would say it's in the region of a 1 meter drop.
Is this something to expect or is there a way to make the drop smaller whit change of settings or pid?

How is the RX spouse to behave in baro mode? In baro I get little or non change of height when I pull the throttle higher. Is that the right behavior or am I in the wrong settings department again?

// Richard

@Hoppsan: The throttlestick has a different meaning in Baromode. And it is not comparable to Mwii/BF/CF.Throttle mid: Hold hight. Above middle: rise. Under middle: drop. Throttlestick to lowest Position: Autoland. If an Autostart target hight is set (like 2 meters) with "set as_trgt = 2" the throttlestick will launch your copter automatically if it reaches mid position. These proceedings just apply when in Baromode and you can Autostart and Autoland all day long. From my experience the Autoland touch down is smoother than 80% of my manual landings. Your copter probably has a too low ALT-P term. Note: Alt-I is the dampening, Alt-D is the throttle-angle-correction. So the classical meaning of PID just applies to ALT-P.
@Litneon: I have found and fixed, what causes a little yaw back after a turn with stickrelease. It is based on that codeline here in multiwii: https://code.google.com/p/multiwii/sour ... i.cpp#1441 . What happens is that the yaw-I term is engaged too early when releasing the sticks, resulting in a little yaw back into the direction where it "yawed" from the fix is here: https://github.com/Crashpilot1000/TestC ... /mw.c#L788. That probably aggravated your problem on your imbalanced copter.
I have uploaded more updates in my repo and deleted the old yaw method completely. The only noticeable difference will be the fix on the yaw but there have been *some* changes concerning mavlink and stuff. I will put the hexfile online later today.

@Crasch: Cool. I did not know this feature. Shure I have used RTH and auto landing whit success but this feature I did not know of.
So I guess I set the deadband round mid whit rc_db?
Will try my new knowledge when it gets less windy.

Hoppsan_84 wrote:@Crasch: Cool. I did not know this feature. Shure I have used RTH and auto landing whit success but this feature I did not know of.
So I guess I set the deadband round mid whit rc_db?
Will try my new knowledge when it gets less windy.

No, it's "rc_dbah" that's the special deadband for althold throttlestick center. The default is: "rc_dbah = 50" that should be more than enough... however the range is [1..100]

Just a little update nothing big: "Testcode3_r147"
The presets are unchanged (ppsum enabled, my magnetic declination is preset..)

Noticeable change:
- "rc_oldyw" is removed, the old yaw controller is retired. The new one is active and the little yaw-back effect is gone.

Not noticeable changes:
- Reworked parts of the mavlink implementation.
- Saved > 5Kb of stack during mag calibration.

Nice to see you back vary active on Harakiri ...

Gotta to update my knowledge on Harakiri after long time not following.

If I got correctly , you have now way point navigation ... this is simply great

Tried the new hex today (r147). Worked really god or should I say just as before.
Did also try the autostart and autoland function whit great success.

The height drop when enabling baro is gone and now when I know how baro works it's just lovely to use.

The only thing that didn't work every time was autostart cause the baro some times didn't stop at 0 after the flight. Maybe HW related.

I used r79 before. Seams to be a big step between them. Have I simply used a really old hex before?

Keep up the good work

@Crash: You are awesome. I'm making some pretty big changes on my quad right now. I got new booms, but am adding a bit (lot) of dihedral. Supposedly it aids stability and makes the quad a bit more efficient in forward flight. We'll see.

Thanks for looking into the code for the Yaw issue. That means a lot.

@Crashpilot1000 I have a question regarding this fix and try to understand? The main yaw fix is only active if an dead band is set (default in Harakiri) and there is some yaw input above the set dead band. Why this is not needed without an dead band? iI there is no dead band set the value is only suppressed if the already scaled absolute stick input is bigger than 50?

Crashpilot1000 wrote:@Hoppsan: The throttlestick has a different meaning in Baromode. And it is not comparable to Mwii/BF/CF.Throttle mid: Hold hight. Above middle: rise. Under middle: drop. Throttlestick to lowest Position: Autoland. If an Autostart target hight is set (like 2 meters) with "set as_trgt = 2" the throttlestick will launch your copter automatically if it reaches mid position. These proceedings just apply when in Baromode and you can Autostart and Autoland all day long. From my experience the Autoland touch down is smoother than 80% of my manual landings. Your copter probably has a too low ALT-P term. Note: Alt-I is the dampening, Alt-D is the throttle-angle-correction. So the classical meaning of PID just applies to ALT-P.
@Litneon: I have found and fixed, what causes a little yaw back after a turn with stickrelease. It is based on that codeline here in multiwii: https://code.google.com/p/multiwii/sour ... i.cpp#1441 . What happens is that the yaw-I term is engaged too early when releasing the sticks, resulting in a little yaw back into the direction where it "yawed" from the fix is here: https://github.com/Crashpilot1000/TestC ... /mw.c#L788. That probably aggravated your problem on your imbalanced copter.
I have uploaded more updates in my repo and deleted the old yaw method completely. The only noticeable difference will be the fix on the yaw but there have been *some* changes concerning mavlink and stuff. I will put the hexfile online later today.

BTW: Nice to see you continue to improve Harakiri. Likely I will update my copter soon.