Collision Detection

[TheBone]

Hi Guys

I'm reading the news about the AQ project and this forum for at least one year.
Actual I'm planning to build a AQ Drone for a project at my university. If anybody is interested in, I can write some more details about the whole project at a future date. For now I'm just interested in the details to build a collision detection system. If I haven't done anything wrong while searching there is no information about this topic in this forum and at other sites I've looked either not.
I planned to use the AQ FC (with DIMU) and the ESC32. If I'm not going wrong, the DIMU which is optional mounted on the FC can't read sensor data from some direct attached sensors (e.g. Sonar). Therefor I looked for a few other units. At the moment I just found the "FreeIMU" with 10 connectors. I hope that you now know what I'm planning to do.

My question at these point is: How can I avoid any collision while the drone is in (autonomously) flight? As I wrote it was an thought to use Sonar sensors to detect anything around the flying drone an use this data to correct the course of the AUV. Do you think the this is possible? I found a Bachelor Thesis with this topic () but I'm not sure if it's possible to do the same with an AQ board. And if it is not or it is too complicated; Is it possible to realize at least an absolute distance to the ground? Not like a GPS navigation. I'm planning to use way point navigation at a mountainside and for that aim a GPS navigation is not very useful. It would be very good if it is possible to realize a permanent ground distance of two meters.

I hope that I was able to make my questions clear. If I go wrong with any of my thoughts, please feel free to correct me.
Thank you for your answers in advance.

Greetz
TheBone

[kinderkram]

Hi TheBone and welcome to the AQ forum!

Most of what you wrote is possible and has already been done. The ArduPilot has included both sonar sensors for altitude and infrared for obstacle avoidence. Since sonar sensors have a limited range (4-5m) the problem was always the handover from sonar to baro. Sonars are also depending on the structure of the ground surface and it will orientate on the objects on the ground so the craft will move up& down while flying over bushes, cars etc.

The altitude is mostly controlled by the pressure sensor - the actual unit on the DIMU is very precise - you can watch it in several videos from our YT playlist. GPS altitude in general is not precise enough.

The AQ code has a "virtual ceiling" where you can submit the max. altitude for flying. So I don´t see a reason why a min. alt. couldn´t be implemented.
But: for mission flights you can set each waypoint´s altitude so the feature you requested would only be needed for manual flying. Flying in position hold mode (which we call DVH, dynamic velocity) will aid you gaining the altitude unless you move the throttle stick.

Tell us something more about your project, please.

Norbert

[TheBone]

Hi Norbert

thank you for your post. I think it would be a great pity if an way point flight isn't possible in comparison with a fix ground distance.

The whole project has the aim to build a drone which support a mountain rescue, e.g. after an avalanche. So the drone has to flight autonomously and nearby the ground, cause of the rescue electronics which hasn't a very long range. But a mountain isn't a flat meadow and when I want to fly at the complete hillside, I have to change the altitude. Otherwise I will go out of range of the electronic or the drone will crash into the hill.
For the future the drone get enhanced functions, like autonomous switch of the flight mode when the measuring parameter show any value. And after that the drone has to flight to the source of that signal. A further problem is the purpose which requires to fly a 0°c or lower and over snow, perhaps while there is a strong wind and/or it's snowing.

You wrote about the ArduPilot. Am I right in thinking that this platform is compatible with AutoQuad? And what's about the QGroundControl? I thought I have to use it with the AutoQuad FC. Is it necessarily to use both software or just one or the other? I think it is latter. An other problem is to generate a waypoint meander for a given area. I know that I can build one manually but one thing I haven't while rescue is time, so it would be very useful to generate this with pre entered specs automatically. And is it right that the transmission of the Flight-Data requires an Bluetooth-Connection? I'm not sure about the used sensors at the moment. First I thought that I use sonar for the ground distance an infrared for the sides for collision detection, like you said. But later on I saw a few collision detection systems which work only with sonar. In this case I have to check which way is the best for me.
The other point is the DIMU. I know that this Unit is very precise but i think too, that this data are not so relevant for my use case respectively for my problem. Or is it possible to get the height above the ground just with the data from the pressure sensor? I think not.
The function to set the altitudes for each waypoint is nice but nonviable cause of the fact that when you start to search for the distress signal with the drone you can't know which altitude are required for each waypoint and you haven't the time to check it out.

Do you have any ideas to solve the described problems? For now I would be happy to have an absolute distance of about 2 meters above the ground. The rest of the written points I can realize later.

Chris

[TheBone]

[joebar.rc]

There have been some explorations in using the px4 (another flightcontroller platform from eth in Zurich), the px4 optical flow controller.
With that it takes a low res image from the surface and use that for control.
Bill (the main developer) and Peter have both got that flying and got altitude control (and terrain following) without gps.

But, it has been silent since then, our small team is active in the areas of own interest obviously so this kind of technique is great to explore but we usually fly in areas where your specific wishes are not required hence the lower exploration in that area.

[TheBone]

Hey joabar.rc an thank you for your message,

I've to admit that I thought that this isn't a so difficult point. An other idea from me is to bypass the control. In the case when any object is in a defined range it would be great if a third party board correct the navigation (altitude) manually and after that the AutoQuad should go on with the way point fight. Do you think that this intention it possible?
Otherwise I've to give up with AutoQuad! I'm a little bit frustrated. I dreamed to fly with the best board on the market and now it seems to be, that I have to choose a dumb board just for a technically not very high-minded function.
For sure I understand your arguments, but I think a collision detection is a topic in our latitude too. Do you know if there is any plan to integrate these function in the future?
Against all odds I'd would like to use AutoQuad. I like the open source mind behind the project, the very high precision, the opportunity to do what I want (mostly) and all the other facts why AQ is better than the rest.
I hope that we can find any solution for my problem. At a pinch a compromise will do it too.

best wishes
TheBone

[joebar.rc]

[TheBone]

Hi @ all,

I'm a little bit busy this days but I want to report me back. You often talk from the vids of the AQ. Meanwhile I think I have seen every youtube AQ vid. ^^ But I'm right there with you, I overlooked some points at my first watching. E.g. in this vid:

It is very impressive how these quad was managed just from the px4flow. Am I right in thinking that the px4flow was directly attached to the AQ or was there any Board in the middle, perhaps like PX4 pixhawk?
In the description of the pasted vid bn9999999 wrote: "Demonstrating AQ's UKF fused with a px4flow sensor. [...]" Does anybody know what the / a "UKF" is? I don't know this abbreviation and I couldn't find it at google too. If bn999 in this forum (I hope he is the same) perhaps read this thread, I would be very pleased if he could say anything about his project. Or for now it would be a great convenience if he could just post his source code for the px4flow.
At the current state of planning I even think that another FC than the AQ isn't the right way. The apm and above all the PX4 Pixhawk look well, but to my mind it is not as professional as the AQ. Would I be right in assuming that currently I just can chose the AQ+PX4flow combo? True to the motto keep it or leave it. I this case it sounds that I haven't any other choice to do it like this way. But that's fair enough, at least fair enough for me.

Glad to hear from you soon.

Chris

[JussiH]

The PX4 flow solution hijacks parts of the GPS data going to the Unscensted Kalman Filter (UKF) that does all attitude, velocity and position estimations in Autoquad.

It should be supported in recent versions, but I am not sure. Relevant places to look is nav.c and ukf.c. The communication between PX4flow and AQ is serial. The DIMU expansions makes the second serial on AQ6 available on a JST-SH connector.

Last I played with it, one of our developers helped out and did a custom version that allowed to change mode between using GPS and PX4Flow for position and altitude estimations - but it was for an ancient FW (R260). I think we could probably release the relevant changes or make a updated experimental release in some way, but the team is pretty busy at the moment preparing a new release candidate to envelop a lot of major additions that has been done since the last release candidate. So PX4Flow is not high up on our list currently.

No dedicated tuning of the UKF for the PX4Flow was done. I got decent results with it, similar to what is shown in Bills video, but because the UKF was never optimised for using a flow sensor and sonar but "hijacks" the GPS part of the UKF, it doesnt always work 100 percent.

At some point I am sure we will revisit this and tune the UKF for flow sensor and sonar. But at the moment its highly experimental and there is no documentation for it apart from the source code, and only a few people in the team ever flew AQ´s with PX4flow.

[TheBone]

Hmm,
that sounds not really good. I thought that at least the user code was from the latest firmware. And twice I thought that I can handle both in on way. Fly in GPS-Mode an be sure that the px4flow hold the distance to the ground. But if I'm understand it right that isn't possible and wouldn't be in further versions too.
Okay, I think that's a topic whereat I have to think about a few days.
Lets look at another matter altogether. You said it before; the team work at the new AQ release. The new DIMU already release yet. The ESC32 get an update too. To use the CAN-Bus it is necessarily to install the SN65HVD232D on the ESC. Do you know if it exists any plans to sell the ESC with an premounted chip? And last but not least the (hopefully) huge update of the AQ board. I didn't read much about an HW update so I think it's "just" an SW-Update. Am I right?
I have to admit that I'm going to run out of time. So I have to chose my Hardware soon. What would you recommend? At the moment I'm thinking about to use the PX4 pixhawk to realize my project and build some Quad with the requested features with AQ later on. That's a bad call but presently I see no other chance that my plans become reality.