MIT's autonomous flight algorithm

[Hamburger]

http://www.youtube.com/watch?v=kYs215TgI7c

[copterrichie]

Absolutely Freaking Amazing! Now lets get writing code for the MultiWii to do the same.

[Hamburger]

Their microstrain sensors do not have tooo special specs.

[copterrichie]

All kidding aside, the day of the machine is close at-hand if not already here.

[penpen77]

they use intel atom as "brain" so i think it requiere a "little bit" more cpu than a 8bit avr can do ^_^ by the way, incoming portage on 32bit ARM with more memory and computation power could bring more cool stuff !

The interesting point is their SLAM (self location and mapping) algorithm, using 2 video stream and live laser range finder to identifiy depth in real time instead of stereo vision and heavy calculation. OpenCV give some implementation, and some opensource SLAM as MonoSLAM or lzrSlam are available, but they aren't gone far as in this video, and not on aircraft !

[copterrichie]

Just thinking out loud here but I believe a good sonar system with multiple heads could accomplish the take on a much smaller scale. I agree, it would require something more powerful then the 8bit Arduino, I was just kidding about that. I would think a Raspberry or one of the embedded Linux devices would meet the task.

[Hamburger]

is there some consensus whether it is advisable to
split the multicopter stability code (current MWii) and sonar/radar/navigation code , possibly on separate processors?
Having a navigation system say 'slow forward', 'fast rising', 'smooth turn left 70 degrees', 'full stop, hold position' etc. may be easier to do than interwoven with basic multicopter stuff like 'spin motor 3 up to compensate unwannted roll' etc. ?

But then again it may just be different levels of abstraction in code?

Any insight on this?

[copterrichie]

This is just my personal opinion and don't wish to create a flaming debate but I do believe it is time to branch off to MWii Version II with a minimum of ATMega256 but preferred 32bit.

[Lapino]

I just had a personal contact with a person of the MIT that was involved with that particular project and the person said that the environment had to be defined prior to the flight...that means every single obstacle had to be simulated before at least the remarkable ones...

[penpen77]

arf, not a relatime SLAM so....

BTW, Hamburger made a good point, MWii should be splitted now, different module with different purpose, abstract/interface with other and a common i/o, com bus. Example:

- Multicopter stability module, (3/6/9 dof, and baro/sonar) responsible of multi/rc
- Navigation module (gps, environnement sensor) responsible of navigation
- FPV/Cam module responsible of pan/tilt, osd/serial output, this kind of thing)

and other thing involving only dev that concern module, invoking only abstract/interface method or I/O of other module (like classic OOP)

Not all module have the same achievement/new-version rate. By splitting and "oo-public-interfacing", dev should go faster. And the nice part could be the flexibility of using several module on several arch, each module could have avr8/stm32 implementation but same interface. Putting all module in same loop into atmega256/stm or splitting on several atmega32's co-processor, like using eos bandi I2C_GPS_NAV not only for wrapping serial gps to i2c, but running the navigation part, or next gen multi core/threading ARM.

[Hamburger]

BTW, Hamburger made a good point, MWii should be splitted now,

sorry, but I feel misunderstood. I intended to pose this as an open question. I am not in favor of splitting like copterrichie seems to be.
For me it is all about learning the pros and cons for splitting vs. keeping it all in one. I really do not know what would be good/better, so I am asking. MIT did the split variant, but we have no info on their reasons? Maybe it was good technical reasons, maybe it was just inter-departmental rivalry or whatever?

Having the current MWii doing flight stabilization plus another gadget doing large scale navigation/direction finding/whatever might just be one possible implementation strategy. On the other hand, if that gadget required all the MWii sensor data to do its job, then why distribute the two tasks and fuss with inter-gadget communication?

I really am just curious. No more, no less.

[copterrichie]

BTW, Hamburger made a good point, MWii should be splitted now,

sorry, but I feel misunderstood. I intended to pose this as an open question. I am not in favor of splitting like copterrichie seems to be.

Hamburger, I assume this is because I have worked with the Atmega1280 (same as the 2560), the Pro Mini and the ST32 and it is time. there is just no way in my opinion to continue this all in one concept.

[Hamburger]

Hamburger, I assume this is because I have worked with the Atmega1280 (same as the 2560), the Pro Mini and the ST32 and it is time. there is just no way in my opinion to continue this all in one concept.

We can easily agree on the promini being too limited in terms of shere cpu&memory to do advanced navigation stuff besides stabilization and other basic sensor stuff (put the fabulous work on GPS by eosbandi and others aside for ease of argument).
But from there which way to go? I have no clue, that's why I was asking. If for example, our next main mcu was a workhorse like a quadcore desktop cpu, then would you still vote in favour of a split?
If not for the processing power, what do you think would make splitting worthwhile?
I support the KISS approach, but there's more than one way to apply it.
Would you rather have a real operating system, run the different tasks (stability, navigation, etc.) as separate processes; doing some kind of IPC eg. message bus? Or have separate cpus and do networking via i2c, serial,...?

Anyway, as I am not currently pursuing this target, I will continue watching what others come up with.

[copterrichie]

Well, we agree more than we disagree. I also believe in the KIS principle but here is my opinion. It is not so much processing power, the Promini has that (Again in my opinion), the problem is IO's (PWM and sensory ports) and memory. So the Mega can do the job but for how long? My Opinion again, the ST32 introduces a totally new set of variables but offers a much better debugging platform which is needed for more complicate tasks.

[copterrichie]

P.S. Continue to support the Promini but if Navigation, Auto-Landing, Object avoidance and other features are desired, would require an upgraded CPU.