I’d like the log too. Maybe you could put it on a google drive or similar?
@tridge here is the log file
Luis said you are aware that the ChibiOS boards are not putting a date stamp (other than Dec 31, 1979) on the log files. I am now testing the board in a gas helicopter so I can fly it longer. Very impressed with how well the IMU’s agree with each other with the Pixhack V5. Copter 3.6 seems to be a little overly sensitive for GPS glitches and IMU’s not agreeing even in pre-arm state on the ground before anything is started on the heli with my other boards. I have not had that problem with the Pixhack V5 at all, but it’s hit and miss with my Pixhawks.
Another tester we are working with on heli beta testing noted that his Pixhawk 2.1 that flew fine on AC3.5 fails to arm on 3.6-rc2 due to inconsistent accel’s and bad GPS health messages. Even after a recalibration of the accels it refuses to arm.
Will you make a version of this CUAV V5 but in a “pixhawk1” form factor ? (This Pixhawk2.1 inspired form factor is quite unpractical for integration in small spaces like most drones are).
For the sake of discussion I can confirm chopy gps flights on the mRo x2.1 px4-v3 chibiOS rc-2. I can get it to arm but the FC is not happy. I also reset the FC configs to be sure… Nuttx 3.6-rc1 seems to fly well.
The one that won’t arm is running Nuttx. The board in this thread, the Pixhack V5, flies perfectly with ChibiOS and I have not seen a single EKF or GPS error with it.
Good deal that it’s working well. My Cube/Spektreworks custom board is also flying well in chibiOS rc-2 but not on the older build. Sorry for off topic. I was thinking about testing the Pix hack v5 but I need to have external leds and usb so it’s on hold for me.
I don’t think the drivers have been built on NuttX; a big reason for the push to ChibiOS was in part because it was so easy and quick to get new boards running (IIRC).
yes, that is fixed in master now
that could be just luck as well. Individual IMUs do vary in their temperature sensitivity.
That is odd, as the drivers are identical. All I can suggest is to get comparitive DF logs with LOG_DISARMED=1 to see what the difference is.
The links above seem to be to websites in Chinese. Can someone please tell me where to see an English version, or how to change what I am seeing to English if that’s an option.
Sorry, we are trying to create English instructions
Can you give me your email?
Yes, sent it to you via PM.
Hi I reported that the mRo v21. is not flyable when in loiter mode. rc-2 chibiOS but flies realy nice in RC-1 nuttx. If you get a chance can you look at this for me. " I donate when i can" in the video below shows the craft working well in Nuttx sorry for the OT “https://www.facebook.com/485789568436939/videos/651634608519100/”
For a direct comparison, could you post dataflash logs of flying rc2 with ChibiOS and rc2 with NuttX, preferably one after the other?
We expect them to fly the same, apart from ChibiOS having improving timing accuracy
Thank you, odd, looks like i getting a timeout when uploading any new firmware I been reflashing a lot. Here is the link to the Chibios log as of a few days ago: https://www.dropbox.com/s/7jv55kb4wa9g7yf/2018-06-18%2020-06-06.log?dl=0
and here is the link to the nutxx 3.6-rc1: https://www.dropbox.com/sh/skikgjwijznattz/AADYBu8jkZ6ceFn0JBf9WgbAa?dl=0
@quadsours Those two logs use quite different parameters, different PIDs, different accel-cal, different compass-cal and detects different sensors. Are you sure its the same frame?
For a comparison test like this I need two logs flown back-to-back with exactly the same parameters. Don’t do any calibration between them.
Bummer I thought i was sending back to back logs can be hard keep track! I will remake them for RC-3
For everyone who has a development test PixHackV5, please be careful to check compass orientation with the latest firmware. I have made changes to which I2C bus is considered internal to match the production hardware, and that means the development boards are now incorrect.
Please check that COMPASS_EXTERN2 is set to 0. You may find it gets detected as 1 with the new firmware. This will affect boards that are not oriented in the normal orientation.
Also, I have now added separate builds for the CUAVv5 board type. They will appear in the download directory shortly.
Why we always need IO Processor? Main Processor has enough IO port , I think it’s redundant for us.
For folks doing dev builds the waf configure command is now:
./waf configure --board CUAVv5