NASA competition - suitability of AQ6 or M4

[flomartel]

Greetings!

My company is involved in a NASA competition, and for the moment, my team of engineers is using a military-grade autopilot suite to operate a large quadcopter equipped with U8s. The flight performances and lack of required tuning for the AQ has impressed us and we are interested in knowing whether the AQ would be suitable for the project.

The most important requirement is the ability to control to quad autonomously via a flight computer onboard the quad. The flight computer assesses the situation based on sensor information (some of which comes from the autopilot), calculates a 4D (space and time) trajectory for the quad, and sends out a command (composed of three command parameters: heading, horizontal groundspeed or airspeed, and vertical speed) to control the quad. This setup works very well using the military-grade autopilot, which has this built-in feature. Does the AQ6 or M4 similarly feature the capability to read data from the autopilot (e.g., GPS/INS position and attitude) and send commands to the autopilot (not in the form of new/modified waypoints but rather as command parameters enabling 3D control) through RS-232, CAN, or otherwise?

Another critical requirement is the ability for the autopilot to use information from an external GPS receiver provided specifically by the organizers for the competition (to test dead-reckoning capabilities in GPS denied environments). In our current implementation, the military-grade autopilot features a ublox chip but its antenna remains disconnected. The autopilot instead receives the GPS information from the external receiver by having the flight computer parse ublox binary data and sending the GPS info to the autopilot as CAN messages. Does the AQ6 or M4 similarly feature the capability of having the internal GPS receiver disabled at all times (even when the external GPS receiver is not transmitting) and instead accepting GPS information through an external receiver via a CAN, RS-232, or other interface?

I also wanted to mentioned another useful (but not critical) feature of the autopilot we are using which is the ability to use some of the bandwidth of the telemetry link with the ground station for communication between the flight computer onboard and some other equipment on the ground (custom-programmed command and control interface; used for geospatial situational awareness, health monitoring, activation and deactivation of some of the flight computer features).

Finally, I would invite you to consider the promotional impacts of having the AQ fielded in a prestigious NASA competition. In addition to media coverage, a select few US universities, which are very active with their UAS research programs, will be competing, and the NASA folks who are currently using PixHawk could get convinced to use the AQ instead as their research platform if the right features and capabilities are in place (mainly related to modularity to provide the ability to interface any type of sensor or equipment). If anything, I hope this post is helpful in suggesting certain features professional developers would like to see...

[Kisssys]

Welcome to the Forum.

Their is nothing in your post that the AQ can not already do or be adapted to do. It has all the same flight control resources that the PixHawk has plus a control system that is more precise than the typical PID. It uses Mavlink telemetry which I believe is common to the PixHawk also and is open source and adaptable. The AQ logs most critical parameters of the FC board at 200 times per second, so evaluation of the system is much easier and more precise.

The current code does not have the ability to receive the 4D commands but work on simulation code is being done by several members, maybe they can comment whether that would provide what you need. The GPS receiver disabling
is pretty straight forward. The telemetry is adaptable and the the limitation would probably be the TX bandwith more so than what data the AQ can handle.

I would suggest that your team look at the source code and see if it is something that is suitable for their task. They can post specific questions here about code segments in question and someone will try and clarify it's use.

Quatos uses a closed loop speed control and the U8 engines would require the ESC32v3 which is in early beta and should be available soon. I believe it has been tested on the U8 with success. Quatos has licensing fee's depending on the weight of the craft.

Quatos makes the tuning very simple and the craft almost always lifts off and performs better than a tuned PID machine with the numbers generated from the Quatos tool.

A note of caution, I would not expect the AQ to fix a Motor, Prop Frame combination that just isn't stable with your current controller after many hours of tuning. Their are controllers that are more tolerant of vibration than the AQ
but if you want very precise control then the AQ will do a outstanding job.

Thanks for coming to the AQ forum and showing interest in our project.

Cheers
Steve

[flomartel]

Hi Steve,

Thanks for your prompt response and clarifications. It looks like most of the required capabilities are not built-in and would have to be implemented...

Nonetheless, we'll look into the code to see if the controller can be provided 3D commands (akin to heading, horizontal groundspeed or airspeed, and vertical speed) to control the quad. Could you provide any ideas or suggestions as to which physical interface to use to connect a flight computer to the AQ, whereas the flight computer would receive, for example, GPS/INS position from AQ (looks like MAVLink could be a good option) and transmit the 3D commands to AQ?

There's not a lot of functions provided by the MAVLink protocol (although there is the option to program custom messages), and it seems that 3D control of heading, groundspeed, and vertical speed, through MAVLink could be performed at a higher controller level through the use of lat/lon/alt commands (e.g., MAV_CMD_NAV_SPLINE_WAYPOINT), although there is a direct command to control air or ground speed (MAV_CMD_DO_CHANGE_SPEED). Unfortunately, MAVLink does not seem to provide out of the box the type of lower level controller access that direct 3D control necessitates.

You mention the GPS receiver disabling is pretty straightforward. In addition to disabling the internal GPS receiver (on the autopilot we're using, we simply do not connect the GPS antenna), we need to interface AQ with an external GPS receiver.

Quatos is probably the main reason for my interest in AQ. From our flight tests of the U8s in a 6kg AUW quad configuration (29" props), the quad would become dangerously unstable at a descent rate greater than 3.5 to 4 m/s, whereas closed-loop has the potential for better performance...

[Kisssys]

The GPS onboard is a ublox and it is communicated through one of the several available serial ports. To use and external GPS would require only matching the protocol and changing to that serial port.

Descending through ones prop wash is always a problem and has caused many a crash in real rotorcraft. I've not measured my descent rate but it's fast enough to be scarry with no problem recovering. Others have mentioned having the props come almost to a stop with a safe recovery.

With the ESC32v3's the prop will go to the speed commanded. I could envision that autorotation could spin the props up which would basically be a loss of controll, something the v3's could prevent.

[flomartel]

I've identified the variables I need within the source code:
control.c
navData.holdSpeedAlt -> desired vertical velocity (must be in alt hold mode?)
navData.holdHeading -> desired heading (actually more of a yaw angle - orientation - rather than a parameter directly affecting the direction of the craft - see NE speed variables below)

nav.c
navData.holdSpeedN -> desired groundspeed along North axis
navData.holdSpeedE -> desired groundspeed along East axis (if direction and orientation are to be matched, this should probably be set to 0)

Looks like feeding values into those variables would control the craft whether using quatos or not. Now, I need to find out how to send and receive values to/from a flight computer and the autopilot. MavLink seems like a possibility. Any other suggestions?

Is the onboard GPS receiver using ublox binary?

[bn999]

Quick work in identifying the system variables involved. I'm not sure, but I might detect that you have slightly misinterpreted them. They are rooted in the world frame of view, not a craft frame of view. The system rotates them to the craft frame of reference before implementing them. So for instance the holdHeading is the desired compass direction that the craft's nose should be pointing. Remember, a multirotor is free to travel in any direction it desires without regard to its actual yaw orientation.

In AQ parlance, position or altitude hold modes are simply the mode where the user does not have any direct RC control of the craft. In these modes, your variables of interests become active in the control of the craft instead of the RC operator.

For communications, the quickest from you point of view might be to hack up the mavlink protocol. If you used custom messages, you would not have to break things too much. You would also need to put some switches in nav.c so that it is told to keep its hands off these variables while you were in control.


Yes, we are using the uBlox binary protocol.

[Kisssys]

Yes, you can use PID or Quatos and they are fed from the same sources.

Prior to adding mavlink Bill used and probably still does use his own telemetry. Look in telemetry.c.

The onboard gps is probably a ublox Lea-6T, it searches for the correct baud rate and when found it initializes it appropriate to it's use in binary format. I believe the baud rate get's set to 230kb. Look in gps.c and ublox.c.

Look at the board_6_1a.h to see the assignment of processor pins.

I think Mavlink is a mess but follow me has been implemented by several people on the forum I believe using Mavlink as the communication protocol. It should be easy enough to limit what mavlink messages you need.

You need to be able to compile the code and without a doubt have an active debugger. Get a ST-Link V2 and download the 30 day evaluation of Rowley Crossworks fro Arm and we will get you going.

[flomartel]

Thanks for the feedback thus far. I have finally browsed through an extensive amount of information to educate myself on the AutoQuad setup, including checking other posts on the forum in an attempt not to repeat in this thread some questions already posted on other threads. I will be referring to both the AQ6.1 and the M4 because I have access to an AQ6.1 board for testing, but ultimately would like to use the M4, if possible...

I've been looking at the source code and the specs of the STM32F407 to understand how the USART/UART interfaces are currently setup, which interfaces are physically accessible, and what changes are necessary to accommodate the needs for the NASA project.

From reading the source code, the onboard GPS receiver is apparently hardwired to the following pins of the STM32F407:
- for AQ6.1: GPIO port D, GPIO pin 8 for TX and pin 9 for RX (actually, physically, those are pins 55 and 56 on the LQFP100 package); mapped to USART3
- for M4: GPIO port A, GPIO pin 0 for TX and pin 1 for RX (pins 23 and 24 on the LQFP100 package); mapped to UART4

On AQ6.1, there is an external GPS connector (J9), which, according to AQ6_Header-description.pdf provides physical access to USART3_TX and USART3_RX. I assume this means that the pins on the J9 connector are also hardwired to pins 55 and 56 on the LQFP100 package. Is my assumption correct?

I have a feeling that I could not connect an external GPS on J9 (and keep using USART3 for the GPS receiver interface) without first physically disabling or removing the surface mounted ublox Lea-6T... Would I be better off using a different USART/UART for the GPS receiver interface?

In addition to having an external GPS, I think I will make additions to the mavlink protocol to interface a flight computer with the autopilot. For both the AQ6.1 and the M4, which USARTs/UARTs do you recommend to be assigned to both the external GPS and the flight computer?

[Kisssys]

You could use the GPS connector by removing the ferrite bead that feeds the gps output to the processor and not use the LED and TP pins or remove those beads also. You would need a mating connector for this connector SH-male-6 455-1792-1 I would recommend leaving the GPS ready to go if needed.

AQ6gpsUart3.JPG (33.6 KiB) Viewed 23635 times

A better choice would be to use UART2 that is provided on the expansion header J2.

J2 pinout.JPG (51.18 KiB) Viewed 23635 times

The M4 has UART1 AND UART6 available on the expansion header, I would use UART6 on PC6 and PC7 as the code already uses UART1 for mavlink communication as does the AQ6 on the J8 the ftdi port. This port on the AQ6 has flow control which can greatly improve communication rate with some modems that have a small buffer.

[flomartel]

Thanks for your suggestions. Since I need to hook up both an external GPS and a flight computer, I need TX and RX access on two USARTs/UARTs.

So, on the AQ6.1, USART2 is accessible through the expansion header (J2), and on the M4, USART6 is accessible through the expansion header (J1 and J2). That gives me access to one USART/UART. For the second USART/UART:

On both the AQ6.1 and M4, USART1 is used by default for communications with a radio modem, so as you suggest, I'll leave it that way because I want to use QGC. UART5 is not an option since there is no TX per the function mapping (Port D; AF8).

On AQ6.1, USART3 is hardwired to the internal GPS, so I won't use it. Looks like UART4 (the RC link) only has the RX pin physically accessible (J7-3). What about the TX and RX of USART6? Is it physically accessible (without resorting to soldering directly onto the pins of the STM32F407)?

On the M4, USART2 and USART3 appear from the source code as RX only, so I assume that only the RX pins are physically accessible through connectors. UART4 is hardwired to the internal GPS. Am I out of options for a second USART/UART on the M4?

I could consider rearranging the function mapping for the GPIOs, but that may create more issues than it may solve...

I've attached a table summarizing my findings about the USART/UART (including the chosen function mapping for the GPIOs):