How to start programming the ELEV-8 V2 flight controller?

WolvesOfTheNight

I have an ELEV-8 V2 that I would like to use for a project in my controls class [college senior level]. While the V3 looks like it is a lot better I am on a tight budget, both for time and cost.

I have a lot of programming experience, though not much with the Parallax system. I would like to be able to access the code for the flight controller, figure out how the system works, and demonstrate how simple modifications affect performance. (Yes, I know how easy it will be to come up with impossible to fly settings). Since it is open source I assume that this should be possible.

My problem is that all of my searches are coming up with information on the V3. The source code on gethub is for the V3 and the links on parallax.com are coming up with only stuff for the V3. Can anybody point me where to get started on programming for the V2? What I really need is:
1) Where to download the latest source code
2) Documentation related to how it works (if it is not included above)
3) Instructions on compiling and installing the code on my quad (if they differ from compiling and installing other stuff with the propeller tool).

Any help is appreciated!

Publison

Welcome to the forums!

While the HoverflyOpen claims to be open, it is the hardware design that is open. The software is closed and has never been shared.

Having said that, Jason, who wrote the code for the Parallax V3 controller, took a stab at some code for the HoverflyOpen.

I have attached the files.

JasonDorie

The HoverFly was not a Parallax product, and HoverFly wasn't interested in releasing their code. If you do a forum search for QuadX Open you should find the thread that the code above came from.

Note that the HoverFly will never be self-leveling without additional sensors and code. It might be possible to add the sensors used on the V3, or just add an accelerometer, then port the code to gain the new flight modes, but it would be a significant amount of effort.

Publison

Here's a link to the thread:

http://forums.parallax.com/discussion/148190/quadx-source-code-for-hoverfly-open-elev-8/p1

WolvesOfTheNight

Thank you for the information; it really helps put me on the right track. The goal of my project is to demonstrate some of the concepts we are studying in class, not to write everything from scratch. There is a good chance that the QuadX code will do what I need. I try to install it today, making sure to fix the dbg.decd issue on line 571...

I will let you know how it goes. And, longer term, I will see if I can budget for a V3, or some other more up to date multi-rotor...

Publison

With the HoverflyOpen at $125 off, maybe more people will download Jason's code and try it out.

https://www.parallax.com/product/31500

May even produce a new thread.

WolvesOfTheNight

I have made a good bit of progress adapting Jason's code base to allow me to write my own single axis proportional controller. It uses 2 props and has the other 2 arms held such that they can rotate freely.

However, I have been unable to get a stable position using the ITG-3200 from Jason's Quadx. The position drifts up or down too much to be useful. Once it starts drifting it tends to consistently drift in the same direction, but it is somewhat unpredictable what direction it will drift in.

I am setting it up the same way as he is, except that I leave out the high/pass filter or gain option. (I tried using the filter but it didn't help). I integrate the position once, just as he does. I did a temperature calibration using his code and ground station, and I put those value in for the temperature drift. However, while the graph on the ground station comes up with nice consistent lines, the numbers tend to vary by +/- 50, so I don't know if this is part of the problem.

A few thoughts:
- There could be something wrong with the temperature drift. Any idea how many degrees/min these things will drift if they are not calibrated? And how consistent are your drift readings from the ground station?

- It looks to me like Gyro.GetRy & Gyro.GetRx are returning velocity not acceleration. Is this actually the case?

- My control loop does not currently have any synchronization; it just runs as fast as it can. It reads and integrates the gyros every time around. This is an undesirable way to handle gyro integration; you really want proper management of the integration time. However, it should work if the loop always takes the same amount of time to run (which is a big if).


Any thoughts on where I should focus? And is there some working gyro code out there that will just give me the current angle of the system?

Thank you!

JasonDorie

You will never have stable angle values from a gyro only solution. It's simply not possible. A gyro reads angular velocity. In order to get an angular position you need to integrate those values, so knowing the amount of time between samples is important, but even so you'll always be subject to numerical imprecision and accumulated error, which is why every system of this sort needs an external frame of reference of some kind, usually an accelerometer.

Drift compensation does help, and everything tuned well I've been able to hold a set orientation for up to 30 seconds, but that's rare.

An accelerometer is subject to the force of gravity, so you can use that vector as a "down" reference and correct your orientation estimate slowly to counter the gyro drift.

WolvesOfTheNight

OK, that is good to know. Judging form what I have figured out of ITG-3200-Open-pasm it must be using both the ITG-3200 and a ADXL-345 accelerometer. But I don't understand all the details of the assembly code....

So, what exactly do GetRX/Y/Z, GetRawX/Y/Z, and GetAX/Y/Z do? Will one of those give me the current orientation of the quad? If not, do you have any tips on how to approach the problem?

When I first looked at your code I was assuming that you were getting the velocity from the gyro and then integrating it to get the orientation. Now it sounds like that is not the case; maybe you are getting the orientation. So, what is GetRX doing? Giving you the acceleration, velocity, or position? And, depending on that answer, why are you integrating it.

I really appreciate your help!

JasonDorie

The Hoverfly board doesn't have the sensors required for full orientation. The driver code I used came from my own quad where I had the ADXL-345 installed, so I just left the code there. The GetRX/Y/Z functions simply return the gyro readings, if I'm not mistaken, and the integration happens in the main loop.

The QuadX-Open code behaves a lot like a heading-hold gyro on all 3 axis. It tries to hold a specific orientation based on the integrated values from the gyro, but it requires a pilot and will never do auto-level or heading hold without additional sensors and code.

If you're interested in doing a full orientation solution, take a look at the code and descriptions (readme files) in here:
https://github.com/parallaxinc/Flight-Controller/tree/master/Firmware-C

There's a rich-text doc here that explains how the internals work and provides formulas for a lot of the IMU code too:
https://github.com/parallaxinc/Flight-Controller/tree/master/Helpers

WolvesOfTheNight

Any idea how HoverFly open firmware does so well at maintaining orientation? It isn't perfect, but it does pretty well...

JasonDorie

Probably more like what the Elev8-V3 code is doing. I wouldn't be surprised at all if they were doing an incremental quaternion based solution. I'd bet the Sport / Open code is based on the code for their more expensive boards, just with the extra sensor bits removed, but the code isn't open so no one but them can say for sure.

WolvesOfTheNight

Just a quick update: I managed to write a simple single axis stabilization program. It was based on the QuadX code and demonstrated how a simple proportional controller can stabilize a system - though not nearly as well as a full PID controller. Especially on something as underdamped as a quad copter. I barley got it working by the due date, but it did work. It ended up being a good extra credit project, if a bit of a pain to get everything working on time.

Over the summer I hope to work on some more interesting projects with the Propeller chip. But I don't know if I will find the time or not...