Vertical Trajectory System, Mk2 Evolution

[OverTheTop]

Vertical Trajectory System, Mk2 Evolution

Since the Mk1 version of the VTS has proved it would function I was thinking about how to further improve things. Its major problem was that having to have the autopilot module mounted upside down on the rocket meant its autotune mechanism started shifting the calibrated vertical position as soon as the AP was switched on. If the time till launch was longer then the resulting flight vector was further from vertical. Not optimal but I did manage to use commercial hardware to get the rocket to follow a vector suitably.

Here is the link to the Mk1 version thread: viewtopic.php?f=56&t=5324

Since then (I started that thread five years ago!) hardware and firmware in these flight computers have evolved massively. I have selected the latest Mateksys F765-WING flight controller for the new incarnation. It is powered by a 32bit STM32F765 microcontroller running at 216MHz and has 2MB of Flash memory for firmware. It also has lots of other functionality right out of the box.

Here is the landing page for that product: http://www.mateksys.com/?portfolio=f765-wing

Since I need some working firmware to go with that, and an interface for programming and setup, I have chosen Ardupilot and the Mission Planner associated with it. This software/firmware used to run on arduino-based systems but these days it is arduino in name only. It currently runs on much faster platforms and is compiled in a regular high-level language. It is open source, so you can tweak and bend the code as needed if necessary. Functionality is breathtakingly wide, straight out of the box. There is also a version targeting the F765-WING specifically .
https://ardupilot.org/
https://ardupilot.org/planner/

Current Status
I have a breadboard of the system concept suitable for bench testing prepared:

VTS2resize.jpg (247.65 KiB) Viewed 806 times

I have started with the programming and have the fins behaving as required. The vast functionality of Ardupilot makes all this possible, without any modifications. There are multitudes of parameters to set which define the behaviour, so if you are looking at this be prepared for a bit of reading!

I am still trying to get the compass to calibrate, which is giving me curry for some reason. Not sure how this will pan out yet. Might be able to do without this but it would be nice to be able to specify which direction the rocket is facing. I will solve this sometime along the way.

I also have an airspeed sensor hooked in, so I should be able to measure airspeed during flight. The intent is to use this to control the gain of the control loops to allow for more control authority at all speeds, without stability issues.

The hardware/firmware functionality is allowing me to internalise all the required functions and not have to add any additional hardware. A good example of this is that the FC has black-box logging (to SD card) already built in to the code.

There are many other features that I can't wait to have a go with

Stay tuned!

[OverTheTop]

I have just changed the USB cable out for a Bluetooth telemetry link back to the PC. That is letting me have the entire unit as a separate entity. I might even change this link to an RF link for the flight hardware. I have now just been tidying up some hardware (removing what is not used currently) and have also placed the unit on a lazy susan for testing the roll control.

I have also disassembled the previous incarnation of this and will reuse the frames that comprised that unit to commence integrating the Mk2 version into the airframe assembly.

Also need to start thinking about gains for the control loops. I have them dialed up at the moment so it is obvious I have all the directions correct. The gains need to be dialed back for flight, and I need to see if I can get some gain scheduling happening with the airspeed as input.

I am still trying to get one piece of functionality happening without having to add any external PCBs.

Progress!

[OverTheTop]

Hardware Selection Completed
I have settled on a final set of modules for the VTS. This should get me all the functionality I want.

HardwareRes.jpg (248.25 KiB) Viewed 442 times

The servos on the flight unit will be larger and digital for better performance (speed and torque), and what I have used on the Mk1 version. The flight battery will be significantly smaller too, but will need an umbilical to keep it topped up on the pad.

I will possibly have to change the Ardupilot firmware to add the function to be able to trigger stabilise mode from a local input. It is currently available on the copter version of the firmware, but not in the plane version which I am using. Should be relatively easy to transplant that code if the developers don't pick up on my request to get the function added. As it stands (v4.1.0) I can switch to manual with a button input, but not to stabilise.

Also note that when working with telemetry transmitters that are of reasonable power (say >10mW or so) it is a good idea to have either an antenna or a dummy load connected to the transmitter when playing around with it. If it transmits and there is no valid load the power gets reflected back into the transmitter and can overheat the final stage, potentially killing the module.

So I am starting to transplant this hardware over to the airframe module. During the process I will be tidying the wiring and making sure there is enough power supply decoupling where it is needed. I don't want any internal EMC issues.

While transplanting the hardware I am also working in parallel to make sure I have reasonable values for the hundreds of parameters that Ardupilot has for determining how it behaves and controls the craft. It is a very powerful, and thus voluminous piece of firmware. So much reading has been done so far and still to do .

[OverTheTop]

Been progressing this a little.

Parameters and Documentatiom
Firstly, in order to make sure all the relevant parameters are set correctly for the Ardupilot firmware, I have exported the parameter list to an Excel spreadsheet. This way I can have each parameter and the value assigned to it documented. I am also using a traffic light system, with colors to represent whether I have selected the final value for the parameter, it is a don't care, or needs to be dealt with. It also allows me to record any relevant comments. I guess it is the railway work ethic in me that wants me to make sure I have everything set as necessary. Many parameters need to be researched, considered and/or calculated then applied and tested. Very time consuming.

Hardware
I have stripped the old hardware from the flight VTS module. I also had to make a new disc for mounting the flight computer as the other one had started to look like Swiss cheese. Good for the lathe and mill to get a bit of work from time to time.

The FC was mounted on a platform that is vibration isolated by rubber grommets, and the servos have been connected in. I used nylon screws for the mounts as they are lower mass than stainless steel, and I figure if they break I will have bigger problems to deal with .

Still lots to hook up, but the new module will be a lot tidier than the first incarnation.

[SpaceManMat]

I missed this, looks really good OTT.

They sure pack a lot into that flight computer don’t they.

[OverTheTop]

Hardware is Beginning to Coalesce

The Bluetooth module was mounted by epoxying two pieces of G10 to the bulkhead near one end of the FC, and then fixed in position with some hotmelt glue at each end.

The HD camera was mounted onto another bulkhead using two M2 screws tapped into the G10.

Similarly the 0.96" OLED display was mounted on another bulkhead. Two stanchions were made out of some G10, then drilled and tapped to suit the M2 mounting screws.

Both display and camera will need to have relevant visual ports cut in the outer airframe.

A few more modules to mount then I can start making the wiring looms.

I am still deciding if I want to add two battery charger PCAs so I only need to provide one voltage feed to charge both the 2S and the 3s LiPo batteries, via an umbilical when still on the ground.

[SpaceManMat]

What info are you planning on displaying on the lcd?

[OverTheTop]

Not planning on changing the default info at this stage. Here is a good image pulled from the interweb:

The main things it will show is the current mode, GPS status and battery voltage. Other messages scroll across the top from time to time to report conditions.

[OverTheTop]

Just following the Script...
As part of the functionality of this VTS I need to be able to switch between Manual and Stabilize modes using effectively switch closures. There is functionality in Ardupilot to switch to Manual easily, but less so to be able to switch to Stabilize. For some reason the feature is available in Copter, but not in the Plane variant of Ardupilot. So, I had to come up with another way. I didn’t want to have to use two additional PCAs to generate the required command. The hardware solution needs to be elegant.

I could add Stabilize to the button functionality in Ardupilot but that would require me delving into the firmware and recompiling with the additional function. That is fairly straightforward, but time-consuming, as I install the required software and learn the toolchain.

Further diving into Ardupilot shows that what I need can be accomplished using the LUA scripting language built into the code. This allows scripts to reside on the SD card and they are executed when the FC starts and at user-specified intervals. Quite complex tasks can be accomplished by scripting. For example, it is relatively straight forward to fly a quad copter in a vertical circle in one of the sample scripts. In my case it is only reading a button input and then switching flight mode.

Here is some background on the scripting:
https://ardupilot.org/copter/docs/commo ... ripts.html
https://github.com/ArduPilot/ardupilot/ ... g/examples
Here is the script I have come up with to add the required functionality:

Code: Select all

-- This script is to set FC mode to STABILIZE when the button is pushed
--  SRC 12JAN2020

local button_number = 2 -- the button number we want to read, as defined in AP_Button
local button_active_state = true    --  the 'pressed' state of the button
local last_button_state
-- flight mode numbers for Plane
local MODE_STAB = 2

function switchstabon()
  local button_new_state = button:get_button_state(button_number) == button_active_state

  if button_new_state ~= last_button_state then
    last_button_state = button_new_state  -- update latched state for edge detection
    if button_new_state then
      gcs:send_text(0, "LUA: Button Released")  -- switching back to manual is otherwise accomplished
    else
      vehicle:set_mode(MODE_STAB)
      gcs:send_text(0, "LUA: Button 2 Pressed")
    end     
  end

  return switchstabon, 20  -- rescheduled loop every 20ms
end

return switchstabon()  -- run immediately before starting to reschedule

That should be a whole lot easier than recompiling firmware .

Trying it Out
So the script was loaded to the relevant directory on the SD card, through Mission Planner PC interface, the FC rebooted and IT WORKED FIRST TIME!!! Winner, winner, chicken dinner. Modes can be switched at the FC by the push of a button, or two!

Scripting is seriously powerful. Now that I have dipped my toe into that water it may come in handy later in the project!

Still to do…
I am still in the process of adding the peripherals to the flight assembly. Currently mounting the 1.3GHz telemetry transmitter, and then I have the GNSS/Compass and the pressure sensor for the pitot-static tube. Once those are done it is just the power distribution (batteries, switches, BEC) and the interwiring of everything to complete.

[OverTheTop]

Ardupilot Control Systems

Here is a very basic overview of what the control systems are like internally within the AP firmware. It is quite a sophisticated piece of engineering. It has features such as potential and kinetic energy management, sensor fusion and redundancy, programmable control mixing, fully-automated mission capability and can even avoid aircraft based on their ADS-B transmission, if the relevant receiver is fitted to Ardupilot. This is all open-source so features can be added if necessary.

plane_controllers.png (25.64 KiB) Viewed 138 times

All the relevant parameters need to be selected to make the control system suitable for my use. Note that there is already provision for feeding the airspeed in and providing effectively gain scheduling of control surfaces based on airspeed.

If you have any interest in drones or other forms of remote operating vehicles (helis, quad/hex/octo, planes, rovers, submarines etc) I suggest you visit ardupilot.org

BTW, I am not getting paid to spruik this

[SpaceManMat]

Not sure what I think about use of a script, may be ok for development phase. Obviously the required feature is installed, otherwise the script would not work, I would think that this is just a configuration issue?

Problem with running a script as I see it the need to confirm it has been initiated, plus how much cpu overhead does it take?

[OverTheTop]

Scripting is a valid way of getting the functionality. The implementation of the scripting has been quite well done and will not drag the performance of the FC down. It basically exists in its own sandbox and should not be able to cause a FC failure.

There is also a mechanism to write the script into the FC flash memory, thus making it more permanent than existing on the SD card.

Note that if the script causes an error the FC will exit all scripts and automatically reload them from the SD card. Remember also that the mechanism to set the flight mode to MANUAL (fins neutral, rocket as a standard rocket!) is part of the core firmware functionality. The feature to switch to STABILIZE mode, as mentioned before, is only available via scripting currently.

Remember this FC has a 216MHz 32bit processor on board with lots of processing horsepower. Simple scripts will not even cause it to blink an eye. I have no hesitation in using scripts as they have been implemented.

[OverTheTop]

Mounting the GPS and Magentometer

A 3D printed frame was sketched and then printed up in the resin printer. This was printed in "rigid" resin, which includes a glass-fiber component. Overkill, but it was what was available and I am not going to complain. It is dimensionally accurate, quite rigid and strong. It is held down by two M3 screws tapped into the deck.

For mounting the GPS and magnetometer I needed to select a location that had plenty of view of the sky for the GPS, and minimal interference for the 3DoF magnetometer. That means it should be close to the side of the rocket and away from anything magnetic and any wires that have high DC currents. I have taken a stab and mounted it here as a first attempt. The module gets fixed into the frame by a couple of small blobs of hot-melt glue. The result is a robust mounting but it can be backed out again if needed.

If there is too much interference from the motor in the adjacent servo I might consider moving it up another deck higher, just under the NC. I won't know if that will need to be done until I get it all wired up again and attempt to run the compass calibration algorithm.