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:
- Compass improvements:
- support added for QMC5883L, LIS3MDL, IST8310
- COMPASS_TYPEMASK parameter allows enabling/disabling individual compass drivers
- 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!
Shouldn’t that be Chris Olson ?
Thanks for another great release.
The i2c fix means that the external i2c bus on the Pixhawk 2.1 is now supported? I mean i can plug the rangefinder and irlock in there and it’ll work?
Oops! fixed Chris Olson’s credits! txs.
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…
Ok great, thank you. Now i understand.
Any word on canbus? is it working?
The serial port 5 thing is great! I’m fresh out of ports on my Solo, and 5 is otherwise wasting space!
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)
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.
Thank you soooo much! I appreciate you adding the LIS3MDL compass support.
And a big shout out to @ChrisOlson who is just plain awesome to newbs.
Hey Randy, thanks for doing this. I am trying to calibrate the mRo uGPS ublox SAM M8Q (GLONASS) + Compass (LIS3MDL) (traditional heli) and two things are happening:
- When calibrating the compass, the green bar just shoots across after a few seconds and the calibration fails.
- I can no longer calibrate the onboard (Pixracer) compass.
About serial 5, now that is available where can it be “spilled” fro a Pixhawk 2.1?
Thanks for the report on the compasses, we are looking into this now.
thanks for all dev member!
it’s look like work 2 external compass in ‘here gnss module’
and i have quetion
Is it px4pro from drotek’s pixhawk3pro ??
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.
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.
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.
Have you tried PREFLIGHT REBOOT SHUTDOWN in Actions menu?
I know nothing of this. Where can I find this?
In MP, Flight Data, actions menu, first scroll down DO ACTION list.
Your suggestion solved the issue.
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.