msp

TEGO v3 MoCap Control

TEGO v3 MoCap Control

By Aldux

First automatic position control test’s with the series of quadrotors TEGO, 3D printed multicopters built to be the workhorse of Aldux’s research.

In previous posts I have already showed the TEGO series of quadrotors…

This quadrotors are built with the porpoise of being easily repaired / replaced / redesign and will work as the workhorse of my research, the first version was very basic and a little bit heavy, the next generation started to use the mechanical connectors “Rotites” that are saving the frame lots of weight, reducing the number of screws and nuts involved in the build.

TEGOv3-2

The usual specifications of the TEGO series is:

  • BLDC motors, small size, with a kv range: 1600 – 2100
  • Standard props 5in length and 6in pitch
  • Lipo battery, 950mah, 25-50C
  • ESC 6-10amps
  • Flight controller with ATMega 2560, MPU6050 6 axis gyro/accelerometer, HMC5883L magnetometer
  • MW 2.3 firmware
  • 3D printed frame
  • Rotites

Why 3D printed??

Does 3D printed stuff need a why?? no!!! hahaha, well, basically, this quadrotors are going to see lots of action, crashes… so, if a arm breaks, I print another one… Do I need another quad?? ok, print it… 3D printing is AWESOME.

Why rotites?

Its a highly intelligent solution to fasten the arms of the quad to the main body, with out the need to screws and nuts, also Rotites are really awesome, helps in reducing the body weight, so, increase flight time and make overall a cooler design.

Why MW?

MultiWii is a open-source software project for multicopter flying platforms, its very easy to put extra code and modify the existing one… and also the boards avaiable on HK that support the MW firmware are very cheap.

This test involve a motion capture system, Optitrack, that is hooked to Simulink via a QUARC block to get the attitude (6DOF) of the quadrotor, then we perform some calculations to estimate the position of the quadrotor and output the desired position, and we proceed to sent the commands, roll and pitch, via Bluetooth to the MW board, usign the RCSERIAL commands.

simulink

The first step is to make the quad remain in one position in space, in this case the center already setup of the motion capture system.

We had several crashes, one due to me, hehehe, and the other just for being very brave and test a flying quad for the first time (with no safety whatsoever). The 3D printed frame has proved to be very useful and easy to repair.

In the last test of the video (showed below) TEGOv3 does not lift off, to avoid unnecessary crashes, it will just hover enough for the quad to be able to perform ROLL and PITCH maneuvers. Its showed that the quad goes to the center marked on the floor, of course, we need to tune the gains for control and input the exact constants of this frame and motors combination.

 

Many thanks to my buddy and work colleague Murray and my sweet horde of undergrads cheeky.

Flying a quadcopter from the computer

Flying a quadcopter from the computer

By Aldux

The next part of my quad-rotors project is to control them via the computer. Having that sorted, I can play with nice swarm algorithms and of course motion tracking using Optitrack cameras that are available at the SAS lab in the University.

So… I have tested two FC (flight controllers), the APM (Arducopter) and the MultiWii.

I still need to make the post for a micro quad-rotor build I did for testing the MW, hopefully later in the day.

I find that the code is a little easier to read and modify and also the hardware for MW is quite more cheaper, the NanoWii cost me like 20 bucks… So, I think that if I want to build swarms of small UAV’s the way to go is MW.

I been reading the code of the config GUI for the MW, its really quite impressive, they implemented a nice serial protocol for us to play with it, the only problem is that we have to figure out how it works by ourselves :S

But after some days I was able to perform my first flight using a joystick connected to my computer, and 3DR modems (UART), and it was not so bad… Still need a lot of work, but I can say that for right now its “flyable”, sort of.

The problem is that the GUI demands lots and lots of data coming from the MW, and of course when its plug in into a USB port, there is no problem at all, but when you try to use it with a serial modem at 115200 bps, that can be a huge problem, and that problem is lag.

So, I strip the MW protocol to the minimum, I’m only sending the RC data and receiving the ATTITUDE from the MW, and in that way, it works well 🙂

Next step… translating that code to MatLab.

Note. The first video is lagged for some reason, my GoPro was misbehaving that day 🙁