matlab
Glitch in the system!
I’m in the current process of training my ESN using real data coming from the tuple
('raspberry pi', ',multiWii', 'matlab-simulink', 'MoCap')
But, as usual, there is problems… What can you expect? nothing is perfect.
My current hypothesis is that the rpi is losing wifi connection for a very short period of time, causing the python code to save ‘garbage data’ that then Matlab interprets it a NaN (not a number)… and ergo the glitches.
Thats why I’m asking to the IT guys at my university if they can put a special router only for the MAST Lab… lets see if they deliver.
Pro Tip: Do not use EDURAM for sending/receiving at high rates UDP packages… or the gods of the glitches will punish you.
TEGO position control
This large video is about the project that Murray and me have being doing in the MAST Lab. It’s about doing automatic position control and trajectory tracking of a micro unmanned aerial vehicle, being more specific is our 3D printed quadrotor platform, called TEGO, showed in previous posts here and here.
The video explains almost straightforward what we are doing, but in a simple way, we are replacing the human pilot with a computer controlled one. The “artificial pilot” receives the very precise position of the markers onboard TEGO coming from the motion capture system and it computes the commands necessary to make those markers move to a desired position. Pretty simple and easy right? well… it its not! I’ll continue explaining part by part of the system.
- Motion Capture.
We have a Optitrack system with 18 cameras, we have the Flex 3 ones, so, nothing too fancy, but for now, they are doing the job. The system is tricky to make sure is working perfectly, and usually the cleaning staff knocks one stand and then we have to do the “rain dance” over and over again, kind of stressful, in the pictures you can see using the interface from Natural Point the position of the cameras while tracking markers.
- TEGO quadcopter
Our trustworthy platform, 300 grams with battery, 7-8 minutes of hovering, SK3 3100kv 42 watts motors, 10 amps ESC, 5×3 props, Rotite’s included on the frame.
- Flight controller
Multiwii AIO v2, using MW firmware r1648 with Alex Kroroshko experimental PID algorithm, everything else is standard, rate = 0.9 and expo 0.3 for pitch and roll. I have to mention that I have received lots of help on the MW forums, so, thanks for that guys!!!
- Wireless link
A pair of good old 3DR radios using a special firmware adjusted for the multiwii serial protocol (Andrew Tridgell’s SiK telemetry radio software for MultiWii). Oh and by the way, how cool is Andrew Tridgell!!! he is revolutionising everything, take a look at this awesome video. This radios are working at 115,200 bps, but we think that we might have a bottleneck problem while sending commands, maybe we just need more speed to achieve the trajectory tracking performance that we want…
- Ground Station
Matlab / Simulink, also you can see some pictures of the diagram and you can see it in action on the video. Why Matlab?? because we have a very convenient block for optitrack that makes our lives easier. We know that simulink is not famous with its performance when doing this kind of stuff, but it kinda does the job. Special thanks to my students Krisjanis and Davide for helping in the implementation of the MW serial protocol in simulink 🙂 you rock guys!!
The system is not perfect, we want to have a perfect performance, rock solid. But we don’t have it quite yet, we are closer though. In the making and tuning of this system Murray (my teammate and amigo) and me we have suffered a lot and even bleed lots of times, my thumb especially… Lets say I have less sensibility now :(. Murray was implementing a simple PID control in simulink because his original state space control was not working correctly, but now that we change from the standard MW PID to the Alex Kroroshko PID one; the state space started to work better, and is the one we are using right now.
I would like to have some feedback from everyone and of course some opinions or ideas of how to make this one better… I have to excuse for the video, because is very large, but this is not a video to just show stuff, I want to demonstrate almost everything about our system.
Keep on flying!
TEGO v3 MoCap Control
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.
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.
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 
.
