Hello Mandela,

I am Maitreyee from MathWorks! Happy to see you choosing this project.

We have noted the missing references and update the page with them soon. Keep watching the project space for the update.

Also, please feel free to comment here to share your thoughts and ask questions!

-Maitreyee

Hello @ouafi98

Great to know you will be working on this project!

Thanks for letting us know about the references, we have now updated the project description including those.

Best,
Roberto

Hello @ouafi98,

Could you explain a little more on why you think two Kalman filter method would be needed? You can probably provide a brief about the workflow you are considering. I am assuming this is for a situation when the vehicle comes across a sudden change in altitude due to objects in the field of view on the floor.

Also, considering the estimated states to follow values from sonar as input in a default case sounds like a good approach.

Regards,
Maitreyee

Hi @mordekarmaitreyee

I've tried to use one kalman With a logic that switch on a more reliable sensor to update prediction, it worked for a few time and then diverge (on the real drone) mostly when logic back to the sonar after Some Time. I've also tried to switch manually between the two sensors, it works in simulation but diverge on the real drone after some time.

From a theoretical point of view I guess switching between to sensor with different noise and bias maybe somehow accumulate the error (I don't know, it's just a hypothesis, need further thinking...)

I could choose to switch to a filtered version of the pressure sensor (in that case I don't have the right velocity), this also introduce a delay.

Doing some reading on fault tolerant détection and correction using kalman filter, in the simple case the redondant sensors are treated by separate kalman filter and then there is a final fusion filter that aggregate all states estimated.

Another justification of the second kalman filter is for velocity estimation, Because if the estimated altitude from sonar is wrong, maybe velocity are also wrong. Therefore we can compensate by switching to the estimated states from sonar 😅

Best regards,
Mandela

Thanks, @ouafi98, for the explanation. The approach certainly sounds interesting!

Another way to explore could be to maybe not switch between the two sensors and use the data to detect a change of height readings from both sensors (since switching may eventually cause issues like you mentioned). When a sudden change of height has been detected due to a floor obstacle, take the action to retain the height.

Possibly the following article can help shed some light. It isn't exactly the same, but maybe useful:
Sabatini AM, Genovese V. A sensor fusion method for tracking vertical velocity and height based on inertial and barometric altimeter measurements. Sensors (Basel). 2014 Jul 24;14(8):13324-47. doi: 10.3390/s140813324. PMID: 25061835; PMCID: PMC4179067.

Also, you could check something that has been tried using Parrot and Simulink:
Veedhi, C. C., & Yeedi, V. S. D. (2020). Estimation of Altitude : using ultrasonic and pressure sensors (Dissertation). Retrieved from http://urn.kb.se/resolve?urn=urn:nbn:se:bth-19950

These are just some thoughts. But, please feel free to try the approaches that you feel would work best, and let us know if you have any further questions!

Regards,
Maitreyee

Interesting approach, @ouafi98. Looking forward to the submission.

Feel free to share any learnings or videos as you work through the project.

Thanks,
Maitreyee

Great to know that fusion is working fine on the drone! I was actually a bit skeptical about the use of pressure sensor for low altitude estimation, but if it works that's awesome.

Going back to the idea of two KFs, I was thinking about using a first simple KF that fuses sonar and pressure sensor data for altitude estimation. The state of this filter can be altitude and obstacle height. The obstacle height could be used to maintain a minimum distance (let's say 50cm) from the obstacles along the vertical axis to reduce ground effect.
Then another filter would fuse IMU with the estimated altitude from the previous filter. This filter can actually be combined with the other sensors to obtain the overall position. Again, this is just an idea.

> I took the output of the estimator and convert into euler angle and the feed it to the ship controller. everything works perfectly in simulation and on real drone.

That is what I suspected. Unfortunately, that brings back the singularity problem and makes no difference from using Euler angles estimates directly. The controller should operate on quaternions directly if you want to make aggressive maneuvers with pitch values that approach 90 deg. I think you can still make flips but only with rotations around the x axis (roll).

The problem I've with "Quadrotor trajectory generation and tracking for aggressive maneuvers with attitude constraints" is that they rely on the position of the drone to achieve the result. I can't afford that because the position of the drone comes from the optical flow + IMU.

That is what I suspected. Unfortunately, that brings back the singularity problem and makes no difference from using Euler angles estimates directly. The controller should operate on quaternions directly if you want to make aggressive maneuvers with pitch values that approach 90 deg. I think you can still make flips but only with rotations around the x axis (roll).

Yeah because the singularity of the Euler angler is on the pitch (y axis).

I've tried to implement the control in [2] that operates only in quaternion but I have a problem with simulation

Very true! For a flip we should perhaps disable the position control until attitude and angular velocities are back to a small value. That should be fine if the flip is executed quickly enough and at a certain height. In our trajectory we should only consider attitude and angular velocity from the IMU.

it's what I had in mind.
We can also perform a flip in open-loop (like an FPV drone pilot) and then try to catch the drone when it re-pass to 0 (This is not deterministic, it can sometimes fail)

Hello @ouafi98,

This is awesome :-) Great job!

I am really looking forward to seeing the implementation deployed on the hardware and approach you used in designing the Simulink model.

Keep sharing your progress. Superb job again!

Regards,
Maitreyee

Wow, it was great to see the video! Yes, really awesome job.

The method rely only on IMU

Hello @ouafi98 ,

The work is certainly great but I would say it would be amazing if you can try the flip maneuver on the hardware. You can take your time as you work through it :-)

If you need any help while deploying on the hardware, please do ask us.

Thanks,
Maitreyee

Hi @ouafi98,

Do you already have a GitHub repository with the 'flipping model' that you can share?

Hi @robertogl
yes I do, but my Simulink is not clean but are understandable. I'm trying to find time to clean it a bit and write a short doc.

Sure, take your time. You can always clean it up later if you wanted to submit the solution and get the rewards now. Short doc will be appreciated.
Thanks!

@robertogl
Thank you for your reply.

I've just submit the repo as it is (https://github.com/ouafi98/project-230). I'll clean it later after writing my master thesis.

Awesome, thanks so much @ouafi98! Let us take a look and send you the rewards.

Hi @Hemant3122000
Do you get started?

just applied.
Now onlly reading

Hello @Hemant3122000,

We are very happy to know that you are working on this project. We are excited to see your approach to this problem statement.

It is also great to see you and @ouafi98 interacting :-)

Please feel free to ask questions, queries, or clarifications here. We will be happy to share our thoughts!

Regards,
Maitreyee

Did you try registering through the form provided here?
"Fill out this form to register your intent to complete this project."

What problem are you having?