Im hoping experts here can point me in the right direction with my current project. Indoor quadcopter with position hold and forward obstacle avoidance ability, Onboard it has the cube, two TFmini (one forward facing, one downward facing) and a Px4flow for positioning. It is never intended for outdoor use therefore no GPS. Im running Arducopter ver 3.6. It flies rock solid in stabalised mode anything else things start to get interesting.
Issue 1: very erratic altitude hold. Both with downward TFmini and internal barometer. With throttle at mid stick the craft can shoot up into the ceiling or sink to the ground randomly and rather frequently. Ive tried both hard and soft mount on the cube. The flight controller is also shielded with a dome (not air tight of course). I doubt the mounting and airflow will cause this. Is this a config issue or faulty hardware?
Issue 2: Px4flow. opt_m_x and opt_m_y has sensible outputs when viewing through mission planner. however it seems like the cube isnt using that data. I’ve set the flight mode as position hold with anything to do with GPS disabled. Am i using the correct flight mode? I noted Flowhold as one of the flight mode options but the system dosent allow me to select it.
pictures, flight logs and config file as attached
I would appreciate it if anyone can shed some light on this. Thanks
i just built something that was intended to be safe indoors. it is still a bit too heavy and big, but i saw no way to make it smaller.
it is a 3" Owl frame built arducopter that uses kakute f7 stack. to fly altitude hold correctly indoors you need to setup a lidar with a preference over baro, i also use benewake tfmini.
tfmini has to be setup correctly as well, there is a thread about this.
to make it use lidar you need to set some options in the EKF to set lidar as a preference. baro will never work indoors correctly. it has to be shielded and covered by foam.
EK3_RNG_I_GATE,500
EK3_RNG_M_NSE,0.2
EK3_RNG_USE_HGT,70
EK3_RNG_USE_SPD,6
here are the flight logs, sorry it took longer than expected. i was having trouble uploading these here. i gave up on doing that and used google drive instead.
Thanks for all the replies so far. I have tried both hard mounting and mounting with rubber dampers. both gave very similar results.
Must it be EK3 for the lidar to work? i have two range finder on board, forward facing as rngfnd and downward facing as rngfnd2. ive only set the EK2 params. Could that be the reason why alt hold is always nuts?
I suppose the flow can only come in after i get a stable altitude hold correct?
In most cases, it’s best to stick with EKF2 so maybe disable the EKF3 by setting EK3_ENABLE = 0. Instructions are here on controlling which EKF is used but in this log it looks like both EKF2 and EKF3 are enabled (EK2_ENABLE = 1, EK3_ENABLE = 1) on both IMUs (EK2_IMU_MASK = 3, EK3_IMU_MASK = 3) meaning that a total of 4 EKFs are running. because AHRS_EKF_TYPE = 2 only the 1st two EKF2’s are being used. EKF3 is running but it’s outputs aren’t being used. Under ChibiOS 4 EKFs would probably run fine but under NuttX it’s cause a fair number of main loop overruns (i.e. bad timing of the main loop, see PM message’s.NLon field) which could negatively affect flight performance.
until we get the optical flow working, I think it would be best to turn off object avoidance.
It looks like the downward facing lidar is only working to about 1.2m. I guess both lidar are Benewake TFmini so I would have expected much better than this. By the way, we do have a fix coming soon (3.6.1 or 3.6.2) so the lidar range won’t appear as 655m when it goes out of range. This fix shouldn’t affect flight performance though.
I guess the vehicle is flying at about 30 to 40m? In which case the Benewake TFmini’s max range of 7m to 12m won’t be high enough for optical flow based position estimation to be used.
i will disbale the EK3 and EK3_IMU_MASK and test it out.
-yes both lidar are the Benewake TFmini
Perhaps to add, the forward obstacle avoidance it working fine.
and…im flying mostly around 3m. perhaps at times going up above 5m but certianly not exceeding 7m. I would have hit the ceiling then
I do notice the value going to 655 from time to time. but never above the TFmini’s max range.
meaning to say the optical flow should be able to hold the position? but the aircraft just goes flying away everytime.
hmm… something doesn’t add up then because when I look at the logs, I’m seeing altitudes of about 30m. This is from log2.bin downloaded from the link above.
OK, I think maybe the issue is that EK2_RNG_USE_HGT has been set to 70 although I thought this was only used with the EK2_ALT_SOURCE = 1 (Range finder). Can you try reverting this to the default of -1?
Greetings,
Following your previous advice, i changed the following parameters and went for a test flight.
– rngfnd2_type set to none
disabled forward tfmini
serial2 (telem2) disabled
disabled EK3
EK2 alt source to use only the lidar
rngfnd (originally used for forward obstacle avoidance) and rngfnd2 (originally used for altitude hold) swapped
so now only RNGFND is being used for altitude holding.
This time the flight was done outdoors in fears of it sky rocketing. low wind, very calm conditions.
the flight logs are in the google drive link here.
ive test flown it and there are some improvement. However it seems the sonar value goes to 655 at about 1.3m visually. below that its at least holding though still a little ‘soft’. It Seems like the height readings are updating too slowly and the aircraft is ‘chasing’. when it do eventually stabilize out, the readings freezes. sorta like entering sleep mode during inactivity and the aircraft starts drifting again.
how do i correct this? Changing the RNGFND_GAIN and RNGFND_MAX_CM as well as the altitude hold P values dont seem to do much.
I’ll try putting the EK2_RNG_USE_HGT to -1 and shall update accordingly.
Oh no, I definitely did not intend to recommend setting the EK2_ALT_SOURCE to 1. To be clear, this is what I recommend:
EK2_ALT_SOURCE = 0 (barometer)
EK2_RNG_USE_HGT = -1
The issue with the range finder showing 655m should be fixed in Copter-3.6.1 which I hope we will release tomorrow for beta testing so you might just want to hold off 24hrs until that’s available.
Yes, I don’t think people should be using the range finder as the EKF’s altitude source especially in this case where the lidar’s maximum range seems to be about 1.2m. You’re right that if the copter is being used in a very controlled environment (i.e. indoors) where there is no ground clutter (i.e. nothing on the ground) it might be better to use the range finder rather than the baro. …but I think at this stage for @Janson_Lau it would be better to stick with the baro for now.
Hmm, something there is not right. TFMini lidar unit is good and very reliable up to 12m range. I use it on all models now as it tremendously improves low altitude stability and landing control.I think tfmini was not properly configured in the case above.
I’ve flashed the cube to the beta arducopter v3.6.1.
initial flight with no external sensors went very well. this time the baro held rock solid and the readings are all very sensible.
i went on to set the EK2_ALT_SOURCE to 1 to use the tfmini for altitude hold. this time, no more showing of 655. it also took care of my range previously stuck at 1.2m. now i have good altitude readings all the way. However…it is still erratic. sudden increase and decrease in altitude. Strangely…the altitude on the telemetry display corresponds with the height changes. So…an increase in altitude comes with an increase in sonarrange readout.
I would have imagined it being the lidar giving false readings and the aircraft responding accordingly…seems like thats not the case?
i have the TFmini soft mounted with rubber dampers. could that be the issue here?
did you try to do what i told you to do before? do not set alt_source to 1. keep it pointing to baro.
then set
EK2_RNG_I_GATE,500
EK2_RNG_M_NSE,0.2
EK2_RNG_USE_HGT,70
EK2_RNG_USE_SPD,6
make sure your rangefinder settings are also correct for tfmini - RNGFND_MAX_CM and RNGFND_MIN_CM. i look at mine and for some reason i left RNGFND_MAX_CM set to 600 - it was apparently a reliable range for outside, it looks like. not sure why it is a half of 12m range it should do but, still, it works fine.
arm model and look in the MP screen in the live values ‘status’ window at the value named ‘sonarrange’ - point model around and you should see there correct readings in meters - 0.3 for 30cm, 1 for 1m, etc.
if done as i tell you above it will sit rock solid at required altitude with no deviations. yours is not doing it at all, so, something is wrong.
It looks like the Lidar’s range is still showing a maximum altitude of about 1.3m. Maybe try testing it’s range by pointing it sideways.
I just want to repeat my advice that I don’t think as a first step it would be best to get it flying well with barometer before trying to integrate the lidar into the EKF. From the video it looks like the EKF isn’t happy.
I tried exactly what you said EK2_ALT_SOURCE is back at 0, using baro, along with the TFmini command 42 57 02 00 00 00 00 20 an all other RNG settings. I have good readings from the sonarrange status. while it did hold its altitude, any pilot inputs seem to drive it crazy.
throttle level : reaction
50% : altitude hold
55% : altitude hold
60% : still holding, can see the aircraft bouncing as if it cant decide what to do
65% : rockets into the ceiling
The symptoms are the same for descending. and once it starts shooting off up or down, its very difficult to catch it at the centre again.
adjusting PSC_VELZ_P and PSC_POSZ_P didnt seem to do much.
Also tried different mountings, hard or soft as well as using different serial ports. none works.
trying different commands for the TFmini, with or without pixmode also didnt help.
The barometer on its own consistently holds great and the control inputs feels linear and very gradual.
with baro alone, things are going pretty well. the lidar…its a different story.
anyway since my ultimate goal it just to have an aircraft that can position hold indoors…should i just stick to baro and use that with the optical flow? or is that even possible?
anyway the flowhold flight mode is always rejected by the flight controller even when the flow is connected and providing data. why is that?
i do not know what to say as i never had anything remotely similar… here is my params file from a 3" model that i do fly indoors - with baro and lidar. try to compare it with your settings, may be you will see anything that makes sense. owl11_07.param (19.1 KB)
I think it comes down to the lidar sensor itself. Have you tested it’s range by pointing it sideways at the wall and seeing how far it can actually sense?
I’m happy to have a look at why it’s rocketing up but I’ll need a dataflash log for that I’m afraid.
