I-ve had a look at that board in the past. I hope it outputs the info at a sufficient rate to be usable. For a multikopter you do want sensor data at a rate of 500Hz or so to allow drving the motors at 300-500Hz. Downside of such a fully integrated solution for the sensors might be less ability to control type and level of sensor filtering and adjustment.
With respect to your Rcvr integration, and motor output, you might still want to look at e.g. the AaroQuad/ArduCopter who have a nice little ATMega based 8ch to PPM converter (avoids the need for surgery on the receiver with FM receivers which generally do have PPM on board, and solves the problem of integrating some of the 2.4GHz systems, some of which do not have PPM on board), and also in the AeroQuad forum (and in one or two threads in RcGroups.com under multirotor helis) at the discussion about using a simplified serial interface for control of the motors, as is also strongly supported by the ArmOKopter group in Germany. That serial interface could take different forms:
-- modifying commercial ESCs: for a number of them this only requires reflashing with modified firmware (see the ArmOKopter site),
- creating a simple serial to 1, 4 or 8 channel PPM converter and using simple commercial PPM ESCs which can accept higher frame rates (up to 450Hz). Quite a number of newer low cost ESCs can accept this. A 2nd version of this same interface could also be used for driving e.g. camera mount and control servos. To allow maximum easy of integration even into existing multikopters, I-ll most likely program this to listen to both the simple serial interface and the I2C interface and accept the first which sends valid data as the one is should listen to for the remainder of the session. This way people can also use it on multikopters with I2C motor control to switch to unconverted ESCs.
The simplified serial interface that I-m proposing would slightly reduce your throttle range to allow us use of the top 16 values to be used as sync bytes / addresses, would run at 115200kb and would use different message formats depending upon the sensors or ESCs attached. The message formats would be optimized for speed / bandwidth. It would allow telemetry data to be returned. Besides having 8 data and 8 setup/control addresses, each device / channel on an intermediate device would have a subnumber which initially will range from 1 to 8 (0 being reserved for a call to all devices on the same address), but this could be expanded to allow for more subdevices or channels although even with only 8 subnumbers you would in theory be able to allow 64 devices to be attached to the same serial bus (even if this might need some buffering / pull up/down resistors on the bus to keep the singal good and not overload any ports).
I2C modification of ESCs has been used quite a lot in multikopters but has two serious drawbacks:
- very few I2C ESCs are available, and conversion of commercial ESCs requires quite significant microsurgery and reprogramming with failure rates of the conversion ranging from 1 to 50%.
- a failing device can block the I2C bus and if that happens when flying, all ESCs will stop and the landing tends to be "a bit too fast" so to speak
Both the above downsides could be avoided with use of the simple serial interface while still reducing the need for the main processor to waste lots of time and pins generating separate PPM output signals at high frame rates.
I2C would remain of use for e.g. non-critical sensors or devices of which the chance of failure / blocking of the bus is extremely remote. This approach to developing serial "black boxes" of which multiple can use the same bus, of course would fit very well with the mbed and central processor with its 2 I2C, 3 (4) serial and 2 SPI interfaces (although of course 2 of the I2C and serial interfaces overlap and 1 serial and 1 SPI interface partially overlap. But with 1 SPI, 1 I2C and 2 serial ports availablefor interfacing over serial channels, you still have quite a lot of capability for serial channels. E.g. 1 serial mainly output channel for ESCs and servos, 1 serial mainly input channel for receiver, GPS and sensor data, I2C for additional sensors, SPI for the occassional sensor which requires that and the ability to use the mbed as programmer for other devices, while of course the USB remains the interface to the "groundstation".
Regarding the difficult to read source code, the UAVX uses more or less standard GNU C with only some hardware (PIC processor) based extensions. The Arduino's of course use the more extensive language simplifications offered by the Arduino libraries. Those are not identical to the ones offered by the mbed environment. E.g. I don't find it all that difficult to convert code for an Arduino to the mbed environment. Most of the algorithms have little to do with the hardware and if you understand what the hardware relarted code is suppoed to do you can generally reuse the algorithms. Of course you can choose to use the CooCox environment (essentially the Code Sourcery GNU C++ toolchain + Ecliplse + CMSIS libraries for the LPC1768 hardware, or cook your own environment based on e.g. Yagarto + Eclipse + CMSIS). That does offer the advantage of still using a standard hardware library but be able to develop offline or with others using SVN or GIT.
You've probably caught on to the fact that I-ve also started developing a flight controler using the mbed taking the UAVX code --and I have no PIC experience but can understand the quite well after a bit of reading-- as a starting point but inserting a lot of my own ideas and wishes straight off which does mean a very massive rewrite straight off .... ;=))
Eric Elliott.
17
replies
I am working in small R&D based company making specialised microlithography equipment.
As hobby trying to make my completely own quadrocopter full-featured project.
Quite new to embedded devices.
My targets:
1. Substituting the bunch of old microelectronics and complicated stepper controller by one (preferably) modern uC board, completely under our control.
Needed: MicroStepping motor control in closed loop with QEI linear encoder, communication with PC,
2. Quadrocopter - using Chrobotics AHRS and mbed board want to make full controller.
Tasks:
a) reading the signal from RC receiver
b) reading attitude from AHRS, i future also GPS position,
c) processing by mbed or similar device (have also FEZ domino and mini)
d) writing to motor controllers (servo standard signal).
I have already found here a lot of information, but would be very grateful for some indication (links?)
- communication with PC easiest way from our own application written in Borland C++
- Reading signal (either servo PWM outputs or whole PPM frames) from RC transmitter