Hello everyone! I am very lost looking for examples of using this device but I did not find anything for three days. Could you advise me some tutorial or page where you can learn to use it? Examples or theory to understand the operation from pdf. Thank you
Hi Daniel, I used this device in combination with F64K Freescale board and FXS-Multi-B board. They are wired via I2C way slower than SPI bus. I guess you can access it both from A9 (Linux) or from M4. On GNU/Linux at least Debian there is a package i2c-tools which allow you to scan addresses on the bus and write/read from them on specified registers. You should read how to read/write to registers using those tools http://elinux.org/Interfacing_with_I2C_Devices Once you know that, you can write a driver that will start up gyro according to datasheet describing registers map for this device. For examples on another platform you can have a look at https://developer.mbed.org/users/JimCarver/code/FXOS8700Q/#5553a64d0762 I don't have Udoo neo board yet, but I hope that helps. What do you want to do with that gyro, may I ask ?
Thank you for your answers. I would like to access the gyroscope through Arduino to get angles of Udoo. I did not find examples. I know it can be done using the Linux console as it described in the documentation, but my intention is to do it using Arduino ide to stabilize a drone in the air. Is there a library available to perform that process? Cheers
Hi Daniel, I also bought Udoo Neo for use in a copter. However, I am not sure if I will onboard sensors. I am planning to use this board for prototyping and playing mostly with the processor. I am not an expert, but can someone verify if those sensors are suitable for flight stabilization ? Sampling rate of Gyro is 800Hz whereas Naze32,CC3D use MPU gyro which has sampling of 8kHz. Also if you connect external sensor, you want to use SPI bus which is more suitable to sample sensor outputting at 8kHz. For 800Hz I guess I2C should be fine. On the other hand, slowest ESC used to work at 500Hz so if your Gyro is 800Hz and you don't do any complicated calculations on the way, you might be able to have motors reacting that fast maybe. There is a whole thread about new flight-controller to ESC protocol, replacement for OneShot with even higher update rates. http://www.rcgroups.com/forums/showthread.php?t=2540753 This is new protocol is probably limited by 8kHz gyro, but that also means people want freshest possible data from gyro to motors to get smoother more responsive flight experience. So if you want something that fly smooth I would suggest Using that awesome Cortex-M4 core in there as real-time processing unit for stabilization and not Linux core Use Linux for less time critical tasks, like improving motion sensing already running on M4 core with GPS or optical stabilization which don't need to run in a main-loop because are slow or computationally expensive. Use SPI 10Mhz for sampling sensor which outputs at rate 8kHz at last (don't know if there are faster gyros) I am currently looking at this sensor https://www.maximintegrated.com/en/products/analog/sensors-and-sensor-interface/MAX21100.html but only because I have it around and so far it looks reasonable, but I might probably use something that flight controllers use like MPU9250 I am still learning about this in spare time as hobby project, so please don't take all of I wrote as definite true, and check yourself.
I will use it inside arduino loop, not using Linux... Is it possible? Maybe it's necessari to use new library for this purpose
I am new to Udoo Neo, and I don't know much about Arduino, but here is the documentation how to program M4 core with Arduino I belive http://www.udoo.org/docs-neo/Arduino_M4_Processor/Overview.html If you want to read Gyro data using Arduino, I don't know if there are libraries that do that. But Arduino must have working I2C library which you can use to communicate with Gyro device. You communicate with Gyro by writing values or reading registers with I2C protocol. The map of register is available in datashet for that device http://www.freescale.com/products/s...scope:FXAS21002C?fpsp=1&tab=Documentation_Tab In the examples, it is shown how to do that for Accel and Mag on Linux using i2c-tools http://www.udoo.org/docs-neo/Hardware_&_Accessories/Motion_sensor.html From that you can see that they send values to register to enable Accel and Mag And then read from other registers. The same way you can do it using I2C library from Arduino I think, but just check registers and values for Gyro.
@Mateusz we don't have Arduino libraries for doing what you aim to do yet. We are working on this too but it won't be ready in days
I got code that works on mbed platform reading those sensors. You can find examples there as well. Not sure how portable that is, but you can get generic idea how to read sensor data using I2C. I guess it will take time for Udoo team to write libraries that expose all features and documentation with examples, but you could write something very simple reading just that Gyro on your own. There are examples how to read I2C with Arduino all over the internet. I assume I2C is working from Arduino part on Udoo Neo ? Right @Andrea ?
Yes. Working on this. As soon as we'll release the possibility to access those sensors from Arduino you'll get examples with I2C as well
I think it will be an uphill struggle to use the on board Gyro for flight stabilization as the sampling rates aren't particularly fast and the data still has to be fused by software before it can be used. Furthermore I don't think there are enough I/O pins available on the M4 to a make decent flight controller which sort of hampers things. A few important constraints of the heterogeneous A9/M4 architecture are: 1. If the A9 hangs, then resetting the A9 causes the M4 to reset which subsequently requires the A9 (after it boots it boot loader) to reload the M4 firmware. 2. If the M4 hangs, it requires the A9 to detect it, reset it and reload the firmware. 3. The clock tree is shared with between both cores, so altering clocks for a peripheral on one core can effect peripherals on the other core. Given points 1,2 then its hard to see how even a simplified flight controller could be developed that doesn't impact safety of the airbourne device
I agree, on-board sensors are 800Hz, ESC need 500Hz, which leaves you with 300Hz for processing, sensor fusion and no latency on I/O. But one can use external sensor and I bought this board as a prototyping platform especially because of interesting processor. I strongly disagree with this one, number of I/O pins, and hardware PWM(8x), SPI(1x), I2C(3x), UART(3) accessible from M4 is an advantage of this board. M4 has additionally 22 GPIO from which 6 are multiplex that depending on configuration can also be used. I don't think anyone serious is using long dead PWM as input nowadays and I believe the PPM will meet the same fate very soon. Any of popular flight-controllers have just one core, which if fails it triggers reset via watchdog, if reset keeps repeating then fail-safe mode kicks in from the receiver due to lack of signal and sets throttle low for less drastic crash. On another hand you have Linux which runs many world-wide servers is crashing it more likely then hardware failure ? Furthermore, both cores have their-own watchdogs and can guard each-other. If A9 hangs, then M4 can detect that and carry smooth landing or go into simpler fail-safe. If M4 fails, then A9 can reset it. If both fail, then receiver fail-safe kicks in like in any other flight-controller, including Navio+ Raspberry Pi which can't do anything else in case of failure. I actually think, two core solution is at least as much safe as any other popular flight controller, if not safer.
As of today on the NEO you only have the following allocated to the M4 side (your missing the fact that some I/O is dedicated to the A9 if you follow the schematics): 2x UART (if you include the debug uart) 1x I2C 1x SPI 8 x PWM The hardware watchdogs on the imx6sx have minimum time out period of 0.5 seconds, in that time the aircraft has already fallen a few (or tens of) meters if you plan to use this feature. Resetting the M4 isn't a straight forward as you think, because you can't reload the firmware from the linux side as the memory is protected from the kernel hence it requires a full reboot. This in turn requires a clean shut-down on the linux side, which mid air can't make sense because there is the potential for loss of power to motors for a 100+ milliseconds. Furthermore your also having to recover in-flight data (ie gryo config + calibration data). I'm not sure how much experience you have developing hard realtime system, however your naively assuming the M4 acts like an existing standalone cortex M4 processor. Which it doesn't and therefore can't always be compared in the same way as it has many quirks. Having developed on the imx6sx, I can tell you that it's fairly easily to crash the M4 and/or the A9 and recovery without a full reboot isn't particularly easy.
I am still learning, so I am glade someone stepped in and explained why using this board for stabilization is not possible. Interesting discussion, thanks for clearing this up to me and perhaps others who might get fooled into thinking that this can be done. Perhaps there are other applications of the sensors, that I am not aware of, but it all of that is true then it looks like it's not the product I should spend my time on. At least for what I am interested in.
I2C might not be the biggest problem, having even faster bus won't improve the sampling rate of the internal sensors which is 800Hz according to datasheet.
Fast mode is support by i2c on the imx6 so this shouldn't be a problem (except if the drivers aren't available).
