Home › Forums › Everything about everything else › dRonin for Tricopters! (TriRonin)
- This topic has 633 replies, 4 voices, and was last updated 3 years, 8 months ago by spezi83.
-
AuthorPosts
-
9 May, 2019 at 17:25 #61794VantassticParticipant
Update on the dRonin for Tricopters and Anti-Virus problem. I was able to set my AV to allow the dgcs.exe program to load without it being put in quarantine. A buddy of mine installed the same dRonin on his computer. It ran once okay. When he ran it again his AV quarantined it for ‘ad ware’. I’m using McAfee AV, he’s using Kapersky AV. I don’t understand why others aren’t having issues with it, but we we are getting the AV problems using two different anti-virus programs.
9 May, 2019 at 18:13 #61795Kevin_ErikModeratorWe’re all having issues as this is a known problem.
Just like you, we’ve set the exception filter within our AV’s to allow dRonin to work. Odds are, there’s a bit of code in the dRonin that “looks” like malware to the AV and thus triggering the quarantine. I’ve personally raised this issue on dRonin forums more than once and have not seen anything come from it.
9 May, 2019 at 18:30 #61796TimParticipant@Vantasstic I dont’t have problems with Windows Defender integrated in Windows 10 (which is a good AV BTW, but slow).
AVs often implement a database call to check if the executable in question was scanned by other users beforehand. If it is a rare file and it deviates only slightly from other more widespread versions of the Software (like the main branch of dRonin) then the AV suspects malware/adware. This is good practice regarding security but also annoying like in our case because it generates a “false positive”. You’ll have to live with it for now or try Windows Defender.
Edit: Spelling
9 May, 2019 at 18:51 #61797VantassticParticipantThanks guys. That makes me more comfortable. I’m new to dRonin and didn’t come across this issue through my research. Mostly it seemed people we just using it with no problem. Now Knowing it’s a known issue with some AV’s, but just a false positive I am less worried about using it.
10 May, 2019 at 17:08 #61809swissfreekParticipantI seem to be having an issue with my magnetometer connecting to dRonin with the KakuteF4v2. I have an M8Q-5883 from Matek, which earlier in this thread someone said was working for them, but mine doesn’t seem to want to play with dRonin. I selected it as ExtMag, but it throws a sensor error in the GCS, and when I try to run a calibration in the Attitude tab, it says “Hold…” and then eventually throws an error and aborts the calibration saying something to the effect of “no information was received”.
I confirmed that it’s wired correctly, and I know it works, because when I switched to iNav, it worked fine. I also saw somewhere that you need to connect the battery before USB in order for it to initialize properly, and that indeed was proven to be correct in iNav, but it doesn’t seem to make a difference in dRonin.
Anyone have thoughts on what I might be missing? From what I can tell, without the magnetometer functioning, none of the Path Planner and Path Follower routines will work, which logically makes sense, but is also a bummer, haha.
14 May, 2019 at 03:30 #61867jihleinParticipant@swissfreek – good news, and bad news.
Good – I have the GPS and external mag wired, selected, and running. I’ve enabled the path planner and vtol path follower. All seems to be running, FWIW. Mag is HMC5983. I have 15 satellites being tracked in my living room, with the VTX running, yeah!! VTX is 5.8 GHz. Have not done any sensor calibrations yet.
Bad – VTX is wired too, but Smart Audio isn’t working.
So some progress in the right direction…..
14 May, 2019 at 03:49 #61868swissfreekParticipantWell that’s good. Still sounds like I’m headed in the direction of getting the same GPS/5983 that you have. I’m also switching to 5.8. 1.3 was wreaking havoc on my GPS. At least that’s my assumption. Losing fix in flight, etc. Again, weirdly I wasn’t having that issue in iNav, at least not that I could detect. I have the number of sats in my OSD on both, I never saw more than 7 on either, but in dRonin since it tells you what kind of fix you have, I could see that it was dropping to 2D with 4 sats, then no fix with — sats, and back to 3D with 7. It’s possible iNav doesn’t keep as robust track once armed. Either way, I’m switching to 5.8 as I can’t get a fix indoors and that’s not what I’m accustomed to seeing on most of my setups.
14 May, 2019 at 12:38 #61871FrederooParticipantI had Matek M8Q-5883 wired and working, but I didn’t manage to arm then, unknown Path Planner/Config errors. :/ I’m using 5.8GHz VTXs and satellite fix seemed very solid.
@jihlein There seems to be a new option in the Hardware settings tab that you have to set (Uart4RxPad = Fdbk2) with the new firmware (hash c4252a0a57a2f5e3a44c9e2a31750898220046ff), otherwise ServoCal will fail as the feedback wire is not assigned (regardless of the Properties for Triflight). Will that settings drop down supersede the old ServoFdbkPin property in the future? And Why is it Fdbk2 and not Fdbk or Fdbk1?
14 May, 2019 at 13:53 #61877FrederooParticipantOn the HMC5883(L) – I hooked a separate I2C board (GY-273) to the I2C on the Kakute F4v2, and the mag does not work. I tried flashing Betaflight, and it’s the same. I did this because I just unsoldered this tiny thing form a Matek F405-CTR, on which it was running flawlessly (with Betaflight). So, I guess the Kakute has a problem with this sensor for some unknown reason. I must have overlooked this because of the other problems I had. Sorry! :/
BTW, the L stands for Low voltage – it needs 3.3V, and 3.6V is absolute maximum according to the specs.
14 May, 2019 at 14:19 #61878jihleinParticipant@Frederoo – Your experience matches mine, some boards with HMC5883L work, some don’t. Not sure why, might be the I2C pull up resistors, or lack thereof on some boards. And last night, I tried my UBlox M8N/HMC5983 with dRonin, and it works fine. On iNav, it won’t read the GPS, but the mag works fine. Go figure….
As far as the FDBK2 goes, that’s literally a 2nd FDBK pin, the first FDBK pin in the RSI input, as it’s always been. The option for a 2nd FDBK pin exists for the bicopter. It’s not used for anything on the bicopter other than monitoring at the moment. Either RSI or R4 will work for a tricopter, as long as it’s setup correctly (R4 set to be ADC, and selected as the FDBK pin for example). RSI is ADC2, R4 is ADC3.
14 May, 2019 at 16:34 #61884billydParticipantswissfreak make the band pass filter I told you about that will fix your GPS issues. If you need help with it let me know. Go to RCG and do advanced search for key words Notch Filter and author ibcrazy
14 May, 2019 at 16:36 #61885billydParticipantAsked in another thread but should have asked here. When you purchase the gps and mag (5983) from amazon does it need programming with ucenter or is it already set up? What protocol does dronin use for gps comms?
14 May, 2019 at 16:38 #61886swissfreekParticipantI actually found that post recently while looking around. It’s from forever ago, right? I’ll give it a look.
14 May, 2019 at 16:39 #61887swissfreekParticipantMine did not need modification. I use Ublox, I think dRonin may also support NMEA? I’m just used to Ublox7 from iNav and BF so I usually go with that and it works (at 5Hz).
14 May, 2019 at 16:40 #61888billydParticipantyes it’s an old thread. The band pass filter is the same as a notch filter only shorted. It requires a little careful soldering work but it’s pretty straightforward. Works amazingly well.
-
AuthorPosts
- The forum ‘Everything about everything else’ is closed to new topics and replies.