I have also noticed that if I reupload the parameter file, outputs remain in pwm, I have to rewrite the manual mask and reboot in order to make it working
that is an awesome design with great potential,what size motors are you running on it please
Hi martin, it’s designed to use 2000 kv or 1800 kv will work with a x or quad just add the bottom unit. this is a 1/4 scale version above.
I could have fun with that,put a nice rotating lidar on it set at say 1meter and well set up could fly all day flying at wall’s hedges etc
I really, really recommend you don’t try with stock tuning. Every copter is different and stock tuning is more likely to disappoint than not. Auto tune is your friend.
Sorry Andy I been using stock tuning for 5 years with a lot of builds. 90% of the time they fly prefect so no worries my friend. if i do have an issue i manually tune. My test air space is full of trees. However by all means Autotest is very cool and thank you guys for what you do mind blowing.
Is only 1 down facing rangefinder allowed? Say one lidar is good from 40m to 1m, and a second is good down to 0.1m (but maxes at 6m outdoors). Is it possible to set them up so it uses one then the other?
I found my jitter. I ended up turning down the PID " possibly more as i hear something after looking at the video " and added 45 degrees tubes. GPS stick control seems a little slow and BHL32 bit motor test is not working. however i was able edit the esc settings. Beta-4 is feeling good.
Yes, it is possible to use two downward facing lidar but it will only use one at a time. The is the logic on how it chooses which of the lidar to use:
- use the first lidar by default (e.g. RNGFND1 will be used before RNGNFD2)
- if the first lidar goes out of range the 2nd one will be used. Note the 1st lidar driver reports whether it is out of range by checking the distance vs RNGFNDx_MIN_CM and _MAX_CM
I must say that I’ve never tested this feature personally but Tridge has so I hope it works! Please tell us how it goes.
That got me thinking, I just received a few Thoneflow 3901uy optical flow sensors, and they are quite small. I’m a little worried about a piece of grass or dirt sticking to the lens and losing the sensor data. Is it possible to use 2 optical flow sensors, 1 per lane ekf3? I see the current setup is 1 lane per imu, but what about 2 copies of each imu and alternate the optical flow sensor? So if you have 2 imus, there would be 4 ekf lanes (or x number of lanes per IMU) Sounds like a lot of work to code tho. The sensors are inexpensive and it would be nice to add a backup for reliability
We don’t support multiple optical flow sensors yet I’m afraid. It has come up a few times although normally the request was to have them pointing in different directions. What you’re describing is “sensor affinity” for optical flow which is also a good idea.
Trying to think out how I want my multirotor set up. I seem to be running low on serial ports. I’ve got a pixhawk 1 (both a 1m and a 2.4.8, I could use either). Got the 4.1.0-beta4 firmware. Currently the GPS, telemetry radio, and the OSD use serial UART, the mag is on i2c and so is a small LCD screen. Multirotor is mostly done building just want to add some additional sensors (it has successfully flown). I’d like to use 2 lidars (TF mini plus) which are set up as UART but I think can be switched over to i2c, but that raises a question how much can I add to the i2c bus before problems arise? I’d also like to use an optical flow, Thoneflow3901uy which can only run on serial UART iirc. Am I overloading doing the following?
4 i2c- Mag, LCD screen, (2) TF Mini plus lidars (1 down, 1 front).
4 serial- GPS, telemetry radio, OSD, optical flow
I’ll probably want to set up the EKF3 lane switching right away, right? Going to be flying over corn and landing in grass. I’ve read the corn messes with the lidar.
I don’t have much advice except that the oscillation issue flying over a corn field (aka “Dolphin flying”) has been somewhat resolved - at least the performance in -beta5 should be as good as it was in Copter-4.0.
Hi @rmackay9, please advice how could I find the reason of the unexpected climbing / estimated altitude loss. I’m using GSF (no compass)
My steps were:
- Wait for good GPS fix, home point set.
- arm in AltHold, takeoff smoothly to 2-3 meters alt
- then the copter did fast climb for about +2-3 meters.
In the log I see that ArduCopter thinks the altitude started to decrease (that wasn’t the case really):
so it does increase desired climb rate.
But I didn’t found any reason of why it thinks so. There was no Alt decrease nor in Baro nor in GPS logs. No decreasing as per Accel too.
2021-07-23 20-37-29.bin (865.5 KB)