"What other (free) compilers have you tried for FPU support? Have you compared the ARM compiler (code size and performance) with other toolsets (such as Code Sourcery) - besides the h/w floating point performance, of course.
"@Yangbo,Sorry, I am not familiar enough with the Ardu code to tell you where those functions live, but I should think a simple search would be able to find them.@Igor (sorry so late with my reply)My experience is with full-size vehicles, not with…"
"Don't worry about how long it takes for this class to start, this guy was my ECE 3085 professor and he is nothing short of awesome. He is enthusiastic and knows his stuff. That is a parrot ar drone. His focus isn't so much about the…"
I thought some of you might be interested in this: Control of Mobile Robots https://www.coursera.org/course/conrob Magnus Egerstedt (Georgia Tech) About the Course This course investigates how to make mobile robots move in effective, safe, and predictable ways. The basic tool for achieving this is "control theory", which deals with the question of how dynamical systems, i.e., systems whose behaviors change over time, can be effectively…See More
This is a demonstration of complementary filters onpitch and rollattitude using 3
gyroscopes and 3 accelerometers running on a custom Quadrotor controller board. Filters are coded in Python on the laptop with VPython rendering of spinning 3D cubes. Sensor processing code is running on the ATMega644p-based controller and is written in C. For Python code, see:…Continue
Its means to be interfaced to a PC over USB, but it appears to provide 9 DOF (accelermeters, gyros, and magnetometers). The device apparently can output the raw sensor values and/or Kalman filtered quaternions
A recent idea from Ben Levitt has caused me to reconsider an answer that I gave for one of your questions.
Ben has suggested that one of the spare pins on the UAV DevBoard, RE8, could serve as an extra PWM input. It just might work! Ben is going to try it. If it does work, then the spare pins on the UAV DevBoard could be used to expand it from 4 PWM inputs and 3 PWM outputs to 5 PWM inputs and 6 PWM outputs.
The 6 PWM outputs total would split up as 3 PWM hardware outputs and 3 PWM software outputs. Obviously, the hardware outputs would work the same way they do now: you write to duty cycle registers.
The software outputs could be implemented without too much trouble using a couple of spare timers and their interrupts, using a technique that I used on the first PIC board that I built a long time ago. The first timer generates interrupts every 2 milliseconds, creating ten 2 millisecond "time slots" for the software PWMs within which pulses are generated. Ten times slots are more than enough, only three of them would be used. A simple scheduler would decide which pulse was being generated, and start the front edge of the pulse. An interrupt generated by a second timer would control the falling edge of the pulse.
The entire process could be packaged up in such a way as to be transparent to the programmer, who would see a simple duty-cycle interface to the three additional software PWMs.
Its on my list of things to do soon, if someone else doesn't get to it first.
Regarding "DCM lite", I will give you the short version now, the longer version when I have some time.
The bottom row of the direction cosine matrix contains all the information you need about pitch and roll. It is possible to update the bottom row without using any of the other rows, if you take a look at the details of the computation. Updating the bottom row involves multiplying the update matrix times a vector equal to the bottom row. Then, the roll-pitch drift compensation can be computed from the bottom row, and the accelerometer values.
If all you want is pitch and roll, you can stop there.
If you also want yaw, there are several ways that I can think of that you could use to do that. One way is to integrate the yaw rate, which you can compute from the elements of the bottom row plus the gyro rate values.