Copter-3.5.4-rc1 has been released for beta testing so you should be able to download it through the Mission Planner (and perhaps other ground stations) from the Install Firmware screen after pressing the “Beta Firmwares” link.
The changes vs Copter-3.5.3 are in the ReleaseNotes.txt and also copied below:
LightWare and MaxBotix range finders supported on both I2C buses
Serial port 5 can be used for telemetry or sensors (previously was only for NuttX console)
px4pro flight controller supported
TradHeli fixes:
motor runup check applies to all flight modes (previously only loiter, poshold, althold)
swashplate behaviour changes when on ground in acro, stabilize and althold
servo test function fixed
direct drive fixed pitch tail fix
Z-axis Accel P gain default lowered to 0.3
EKF origin set using SET_GPS_GLOBAL_ORIGIN mavlink message instead of SET_HOME_POSITION
Intel Aero supports 921600 baud rate between main flight controller and companion computer
Bug fix to I2C race condition on Pixhawk that could occasionally cause I2C device to not be detected
The real push for this release comes from the compass changes. The popular Honeywell compass (HMC) has become nearly impossible to find so the manufacturers of the Pixhawks and GPSs are moving to other brands of compass.
You’ll also see a number of TradHeli issues have been resolved. This is thanks to Chris Olson, Bill Geyer and Tridge over the past month or so. Thanks!
If all goes well with the beta testing we will release this in a week or so as the official version.
So please, beta test this version and provide feedback here in this thread or preferrably in new threads in this Copter-3.5 section if you find problems. Thanks in advance!
Corrado,
I’m afraid the I2C fix doesn’t apply to all sensors. So the IRLock for example still can’t go on the PH2’s second I2C bus. It’s just the Lightware and Maxbotix that can be in either place now. sorry! I suspect we will get all the sensors accessible on all buses eventually - I can’t immediately promise when that will happen…
I agree, Except I’ve just made a fancy cable splitting the signal for the telemetry and OSD. Had I known this was coming…:).
(Using Serial 2 for gimbal control)
Corrado,
CANBUS should be the same as 3.5.3. I’m sure it works for some sensors because I know Tridge tested the Zubax GPS. There are some larger changes that will come with 3.6 that we have not included but I’m not yet sure what those changes are for.
I have just downloaded the new beta firmware.
I was previously using the 3.5.3-rc1.
I am using the Pixhawk 2.1 (The Cube), with the px4flow + lidarlite v3. These 2 items are connected via a i2c hub.
Lidarlite works fine.
The px4flow did not work well with the previous version. I would get no readings.
I used a hack, which was to boot the board via usb. Then plugging in the battery. This would give readings.
I have just tested the firmware in this thread and there is no difference. The issue still exists.
I am just wondering if there is a parameter which could be added, to add a delay to the boot-up of the board. SOLUTION1 So, when the battery is inserted, the copter (including the px4flow) will power up. However, we wait x milliseconds, before the flight controller actually boots up. The value of x, should be changeable in the parameter configuration.
SOLUTION2 Another method might be to create a setting which allows us (via Mission Planner), to soft reboot the flight controller. So, when the battery is connected, the FC will bootup, though the px4flow does not work, so we press a button in Mission Planner, which soft reboots the FC, without disconnecting/reconnecting the battery. This may resolve the issue.
Both solutions would be subject to testing, which I can do for you, if you’d like. It’ll take me less than 5 minutes to run the test.
I’d love to hear back from the developers regarding this.
So, we need to create a parameter. When set to 0, nothing happens. When set to 1, reboots the flight controller, when it is first supplied with battery power.
That will solve this issue once and for all.