Forgive me if I'm asking to cheat a bit and take some of the DIY out of DIY drones.
You need to be a member of diydrones to add comments!
Forgive me if I'm asking to cheat a bit and take some of the DIY out of DIY drones.
This reply was deleted.
Discussions
Forgive me if I'm asking to cheat a bit and take some of the DIY out of DIY drones.
Replies
NewSoftSerial works too. I got it working on an arduino nano via soft serial at 115200
just make sure to set the output to roll pitch yaw, and z_accel only. Also set the broadcast to 73 (aka 100 hz)
so the uno should probably work...
Don't know if it'll work on a UNO since it's only got one hardware UART... Maybe if you convert some of the CHR code to use SoftSerial? But I have not tried that.
Simplest will be to just use a Mega...
Or wait, if you're not using the one hardware UART on the UNO, you can use that to read the CHR and log onto a SD card, so that'll work. Only thing is that you'll have to remove the RX/TX wires while programming it/connecting it to the PC with the FTDI chip.
Look in lokling's repo for the latest stuff, the CHR6DM.h file https://github.com/lokling and also there's a standalone java application for it.. I've never touched that one but it's supposed to work too.
I am using the 6dm unit with an Arduino UNO, just wondering if the code would be the same or much changes? Im hoping to just retreive the data from the unit once per second rather than continuously let the data flow since all I am doing is logging the data rather than using it for a drone situation. My SD card will get full rather quickly if I let it get every ounce of data from the 6dm.
Thanks
It's a quad made off of this sensor board. And it works AMAZING!
So, now I sit here with a working Arduino Mega/Nintendo Wii sensor IMU setup working (but not as good as in that video of course!!!). And my question is, how would we most easy way get the needed data out of the CHR-6DM as fast and good as possible? I read on CHR homepage forum that there were problems with doing this data transfer over UART, and the Mega's got 4 UART's but it also got I2C bus and one SPI bus.
Which way would be the simplest?
My ultimate goal is to incorporate this sensor into AeroQuad software because of the routines already made in that project that I wanna benefit from and also the simpleness to add my liking of sensors to it such as barometers. And there's nothing wrong with the Arduino Mega doing the simple tasks as PID and taking barometer readings for example.
So, any hints tips or further linkings you would want to share would be highly appreciated. I do have some experience with C and C++ in these native systems, but I prefer as little as possible work done in the source for the CHR AHRS unit.
Also, the hardware I got is:
*Arduino 5V Mega (with 3V3 reg.)
*Arduino 5v Duemilanove (with 3V3 reg.)
*Arduino 5v Pro Mini
*Basic 5V FTDI breakout board
*CHR-6DM
My first step is to look at the CHR-6DM with the FTDI breakout board to just convert UART to USB to look at the computer.
You are, of course, correct... an AHRS does not need to output lat/lon. My comment was for the purpose of demonstrating that there's no dead-reckoning of errors (to GPS) in these products, stand-alone. As a result, errors are inevitable over a cumulative period of time. Though, I must say, some of the products out there do an amazing job (for the money).
In particular, the 6dm represents state-of-the-art hardware and design as well as exceptional value. The fact that it uses a cortex-m3 micro (with plenty of left-over program space) means it won't be obsolete tomorrow. I'd love to port over William Premerlani's implementation onto it, as well as enable direct GPS support (via the available USART). I didn't look up the specs of your MEMS, but if they had built-in temperature sensors, I'd use those (each one) to compensate the individual MEMS. I might also add a "tilt" sensor (actually, a planar sensor) to detect L/R/U/D/N/I (normal/inverted) via some of the spare I/O pins you have. Yes, I'm aware that by seeing if one of the co-products is negative, I can detect an upside-down state without the need for another sensor. But there are some other neat things you can do with a planar sensor, to compensate for centripetal forces via interpolation (and imposition) of recent roll/pitch values.
1) When the aircraft makes longer turns, in which case the pitch and roll estimates will tend to zero, due to the lack of centripetal compensation.
2) Unpredictable magnetic field distortions from outside sources (which, in all fairness, also applies to any magnetometer).
There's a third condition which causes the device to yield meaningless measurements, and that's when you reach a pitch angle of +/- 90 degrees. This is a firmware limitation resulting from the use of Euler angles as opposed to quaternions. Add to that the fact that, ideally, the EKF (extended Kalman filter) should be tuned so that convergence takes place reasonably fast and without oscillation, and you end up with the realization that this is an IMU, not an AHRS. Ever see an AHRS tell you that your pitch and roll is zero during an extended turn, or give you some invalid figure for your pitch angle when you reach +/- 90 degrees? I haven't.
The fact that the unit currently does not incorporate a GPS in its solution should be enough of a clue to let you realize that it's not an AHRS. If you were to turn it on and read its outputs, it certainly would not know your lat/lon. Some would argue that the same holds true for other IMU's out there... and though they would be right, they'd also be missing the point (and not addressing your actual question). I suggest you take a look at MatrixPilot, which overcomes some of the limitations stated.
ArduIMU will give you three axis of absolute angles (roll, pitch, yaw). However, there is a limitation. GPS is used for centripetal acceleration correction. This approach is valid if the IMU always is moving more or less in the direction of one of its axis (in this case the x axis). This works great in airplanes where the movement is always more or less in the direction of the fuselage and where the IMU is always in motion (at least when you care about attitude estimation). It does not work in helicopters which may be hovering and yawing without linear motion along a known axis.
ArduIMU is stand alone.
Your original question included "the main micro controller wouldn't have to continuously integrate the gyros and crunch through Kalman filters". You can do attitude estimation with just accelerometers, but they are super noisy. They are useful for averages, but not for instantaneous values. If you are using gyros you have to use some method of integrating and filtering. Kalman and DCM are two competing approaches. There are others as well. In any case you do have to have a processor continually "crunching the numbers".
It says it runs a DCM algorithm. Its that a direction cosine matrix code to fuse the accelerometer-gyro data? Do you need the audrino autopilot board to go along with this, or can you use it as a stand alone IMU?