Thanks very much to our Partners for their support!
By the way, the copter shown is iforce2d’s decacopter (i.e. 10 motors). This is an unusual vehicle that is not supported in “master” but that’s not really as important as iforce2d’s documentation of how any developer can modify ArduPilot’s motor library) to support this type of vehicle. Thanks iforce2d!
The boat shown is ERL77’s omni boat (i.e. a boat that can move laterally). This is one of the first demonstrations of this new frame type that’s been added to Rover-3.5.
I am interested in the way that the ardupilot code gets its gyro/accel information. I was wondering if the imus are only providing the quaternion data and the angular rate and acceleration are all calculated on cpu filtered data, or if the imu’s built-in calculations provide all that. Just recently there has been a departure from getting the fastest updates from the imu by betaflight, and the invensense marketing seems to indicate that they are internally filtering and calculating all that ( https://www.rcgroups.com/forums/showthread.php?t=showthread.php?3240395-Flight-Controller-Software-Future&referrerid=590657)
I was wondering if someone in development could shed some light on this and if there is a possibility of reducing cpu code in the future based on this.
AP gets the raw accelerometer and gyro info from the IMUs (raw x,y,z sensor values not quaternions) and then we calculate everything after that. Many years ago we played around with using the Invensense’s built in EKF but at that time at least it wasn’t great. The major problem was that it didn’t allow fusing in other sensor data that we wanted to use (GPS, optical flow, external position estimates) so it was very limiting to use. It did save on CPU however.
