Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.
Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.
Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).
Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station. Video description is here. The bug is fixed in Copter-3.3.1 so we recommend upgrading.
Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting. HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features
Copter-3.3.1 is available through the mission planner. The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.
Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.
Changes from 3.3:
1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff
2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)
Changes from 3.3-rc11:
1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent
Changes from 3.3-rc10:
1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF
Changes from 3.3-rc9
1) EKF improvements:
a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
a) fix INS3_USE parameter eeprom location
b) fix SToRM32 serial protocol driver to work with recent versions
c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
d) Firmware version sent to GCS in AUTOPILOT_VERSION message
3) Safety:
a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)
Thanks for your testing!
Replies
You are correct Kurt.
The Teensy/Arduino solution was born as a easy way to have telemetry on the OpenTX Taranis radios. It's sole purpose was to translate Mavlink messages to FrSky compatible data.
The radio scripts are a completely different issue, and script issues should be asked in other forae.
I speak against myself because I was one of the first to document a complete solution using a Teensy and a script.
My solution was broken with the release of OpenTX 2.1.x and partially with Copter 3.3.
Ok thanks- Yes I can only speak somewhat on this topic since my knowledge is limited to what I've been able to find on the net, and from some of my own poking around with getting this to try and display on the taranis. any references to scripts are solely in light of a possible end to end solution. It's kind of a shame because we can get the correct S/D port wrapped mav data to the taranis directly without the teensy- but there's nothing actually inside OpenTX to parse / display it in a meaningful manner. The only person I've seen able to do this is in the drone.eu article, was hoping the copy of his bin file would shed some light.
Some discussion here and in the links mentioned
http://diydrones.com/forum/topics/amp-to-frsky-x8r-sport-converter?...
LUA scripts have been the preferred method it seems for displaying the Mavlink data on the Taranis screen. I use two with a Teensy and OTX 2.0.17. AFAIK they are not yet updated for 2.1.x.
See here
http://www.rcgroups.com/forums/showthread.php?t=2274401&highlig...
and here
http://www.rcgroups.com/forums/showthread.php?t=2180477&highlig...
Thanks- However the goal of this is different.
With native mavlink coming out of 3.3 and sent in both S port and D port protocols there should no longer be any reason to use a teensy as the "interpreter". From my research all that is missing is a robust parser / interpreter inside OpenTX for the received raw data, so we can display proper mavlink messages directly on the taranis screen.
If this ever gets completed you can toss that teensy in the can or use it for something else, and you should end up with better performance of the received data. :D
It's not so much that the teensy has been the preferred solution, it has been the only solution for display of extended mavlink data in OpenTX- That is, if you have an S port rx. There's not much at all for D port rx's even though they are an excellent rx. But it really should no longer be necessary to use a teensy if we can just close the gap on the radio side. so close!
I still prefer the Teensy/Arduino solution. If for nothing else as to offload as much "work" off of my flight controller's CPU as possible so it only has to do "flight" stuff. On my up coming new Hex build it will have 2 teensys on it. One for LED control [Teensy 3.2] and one for Mavlink to Sport for my Taranis.
You know you can have 2 in 1 ? i.e. the same Teensy doing the LED's and the SPort :)
Yah but it slows the loops. Plus the new teensy 3.2 has been updated to deal with high power draws of the ws2812b's :) and since I already have a teensy 3.1 on there for my Telemetry I'll just add the 2nd :) I am just finishing up another kit for my hex
Another reason I am going with 2 is because [at least on the 3.1] there have been times that one of my light shows, with the brightness set to 100%, has rebooted the teensy and I'd rather not lose telemetry if that happens :)
Sorry for the dog at the start lol. Forgot to edit that out.
I've been working on lighting as well. I've kept everything together on one Teensy because I want to pull the telem stream to create status-interactive lighting (e.g. pulse red at low batt, reflect flight mode, etc). I've also added PWM input so I can control things from the tx light brightness and light pattern.
I created a PCB for the level shifter and resistors for WS2812 that a Teensy drop onto and has place for headers for all connections: https://oshpark.com/projects/acMDnbtp
I'm still hacking up my lighting code inside the original Arduino sketch, but if anyone is interested I can clean it up and put it on GitHub.
I have 2 sets on copters, this is for my new build :) And yes it takes a hit [over a minute] on flight time, but it looks oh so cool when it is flying :)
I only run a signal and ground to the teensy, the rest is handled by a buck converter [they are 5v leds] straight from the distribution board.
The front end I made is run from my laptop to control them .
The weight isn't so bad as long as I remove the silicone shroud :)
-
163
-
164
-
165
-
166
-
167
of 558 Next