I got started with amateur UAVs by making a Lego Mindstorms autopilot two years ago. It was a total kludge, using a mechanical assembly with Mindstorms motors to move the rudder, with stabilization handled by a FMA Co-Pilot. Originally, I used a compass sensor for steering, but quickly upgraded that to a Bluetooth GPS module. It worked, sort of, but then I decided to go all the way to a 5DOF Lego IMU, using some protoype Hitechnic integrating gyros and a RC MUX. Unfortunately, HiTechnic decided not to release those products, and I stopped development. (Although Sami took a version based on commercially-available gear further than I did--see photo above--he too stopped before getting it totally working).
Now I'm thinking of coming back to Mindstorms. Not a full IMU-based one (the cost, weight and size of the sensors, interface boards and other necessary equipment is several times that of custom hardware like ArduPilot), but rather a navigation-only autopilot that could work with a FMA Co-Pilot to make a very simple UAV for kids.
What we'd need is a custom interface board that performs the following functions:
1) RC MUX, to switch control from RC to Mindstorms and vice-versa
2) Servo driver (at least two channels--rudder and throttle--but ideally more for photos and other triggering). Here's one example.
3) A GPS interface, so we don't have to use Bluetooth
Mindstorms uses a I2C interface. My sense is that if I can just add a Mindstorms connector to ArduPilot and figure out how to handle the I2C communications between it and Mindstorms, it could serve as that interface board. It would send GPS information (already parsed) to Mindstorms, and then Mindstorms would send servo information back to ArduPilot.
What's the point of the Mindstorms, since ArduPilot can already perform all those functions itself? Just that it's a more kid-friendly programming environment. If we could treat the custom ArduPilot board as a plug-and-play preprogrammed device that spits out GPS data and accepts servo commands, students could focus on simple navigation logic and action controls.
What do you think? Is this a good idea and worth the bother? Or should I simplify things even further and just use the Mindsensors board as a servo interface, Bluetooth for the GPS interface and a touch-sensor as the MUX (like this)?
@curt
Have you tried the virtual serial ports on the Arduino? They are ok for small (1-10 byte) commands. You can even use the same pin for send and receive
Solarbotics, here in Canada, makes a nice BS2p knock off that has A/D, I2C, USB and Serial all built-in. Once you have the I2C for the mindstorms sensors and actuators hacked, this may be a viable platform..
-This guy's book describes how port #...I believe 4 on the nxt can be used as a serial com port. he used it to slave two nxt's through nxc. that might help some:
I recently hacked my ardupilot (lots of firmware changes + a couple extra wires soldered across the back) to be a 4 channel RxMux + read 4 channels from the receiver + drive 4 output servos simultaneously. In addition I use the single serial port to communicate to some host computer. The ardupilot spits out the transmitter stick positions as read from the receiver, and the host computer sends back servo commands (which the ardupilot will use to drive the servo locations rather than doing any of that itself.)
One limitation I discovered is that the Atmega328 chip only has one serial port and now I have tied it up talking back and forth to the host computer, so I can't plug a gps receiver directly into the ardupilot any more.
You mentioned I2C, so if you could figure out a way to leverage that to communicate to the mindstorm controller, that frees the serial port back up to do gps. The Atmega328 chip supports SPI (according to the data sheet) but the arduino programming environment doesn't offer any functions to expose this interface, and I'm not sure Jordi made any of those SPI pins available for use anyway ... (?)
Well despite asking for a bunch more functionality myself, one really nice feature of the ardupilot is it's simplicity. Or maybe I should say "simplicity" (in quotes.) *Relative* simplicity. :-) That said, whenever Jordi is ready to migrate to a chip that can do an additional 2 or 3 serial ports, I'll be cheering him on.
Yep.. Xander got it about right. But there's also RobotC for the NXT for example and I have to say that with a proper programming environment like RobotC the task becomes so much easier than it is when you don't have "API" reference at your disposal, for example. So the main reason why it'd be cool is to have a phenomenal programming environment (in the case of both graphical and C programming atleast). I think that this would definitely make programming an autopilot much easier for a novice than it'd be otherwise.
NXT has so much processing power (much more than ArduPilot) that if you could just amplify the IR sensor readings to 0-5 volts NXT could interface directly to them via three sensor ports. Then the last port could be used for the servo MUX connection (ardupilot?). Bluetooth GPS is a good thing in the sense that basically every BT GPS on the market will fit and 5hz BT GPSs are becoming more and more common and cheaper. (I'm not really sure, BTW, if the BT GPS can be interfaced with NXT-G.) The only thing that remains to be solved is if the enduser (a student or a kid?) really even wants to interface with the IR sensors; making stabilization reliable on a graphical programming language isn't probably the easiest of tasks anyways.
Nick, Xander-- I think you're probably right. I'll probably demo it with just the mindsensors servo interface and a BT GPS (with a touch sensor for MUX). If you've already got a NXT kit, that's just an extra $49 for the servo interface and maybe another $30-$40 for the GPS. Plus $70 for a FMA Co-Pilot, of course. About the same cost as ArduPilot (not including the NXT), but perhaps easier or more fun for kids and NXT fans.
Not an ideal autopilot, but possibly cool enough to attract new people to our world.
As much as i love mindstormes (it is how i got into robotics) i dont think a NXT autopilot is such a good idea.
As Xander said, NXT hardware interfaces are expensive than their ardupilot equivalents.
Also, building an autopilot is no easy task. They are complex, expensive and easily damaged.
Realistically, besides the "coolness" factor, an autopilot offers no more advantages for teaching kids/students than a ground based rover which would be cheaper and less likely broken.
My $0.02
Maybe you could make a kit that [I know. I know] didn't use adrupilot the Nxt aught to be powerfull enough; if it's not then it is a waste to have it onboard the only thing it's good at is "microcontrolling" to coin a phrase. Just my thoughts.....
Comments
Have you tried the virtual serial ports on the Arduino? They are ok for small (1-10 byte) commands. You can even use the same pin for send and receive
-This guy's book describes how port #...I believe 4 on the nxt can be used as a serial com port. he used it to slave two nxt's through nxc. that might help some:
http://robotics.benedettelli.com/NXTrobots.htm
This site shows how to create a gps sensor and link sensors by x-bee and some other stuff.....:
http://www.wired.com/geekdad/2009/06/fantasy-lego-mindstorms-sensor...
http://www.mindsensors.com/index.php?module=pagemaster&PAGE_use...
I recently hacked my ardupilot (lots of firmware changes + a couple extra wires soldered across the back) to be a 4 channel RxMux + read 4 channels from the receiver + drive 4 output servos simultaneously. In addition I use the single serial port to communicate to some host computer. The ardupilot spits out the transmitter stick positions as read from the receiver, and the host computer sends back servo commands (which the ardupilot will use to drive the servo locations rather than doing any of that itself.)
One limitation I discovered is that the Atmega328 chip only has one serial port and now I have tied it up talking back and forth to the host computer, so I can't plug a gps receiver directly into the ardupilot any more.
You mentioned I2C, so if you could figure out a way to leverage that to communicate to the mindstorm controller, that frees the serial port back up to do gps. The Atmega328 chip supports SPI (according to the data sheet) but the arduino programming environment doesn't offer any functions to expose this interface, and I'm not sure Jordi made any of those SPI pins available for use anyway ... (?)
Well despite asking for a bunch more functionality myself, one really nice feature of the ardupilot is it's simplicity. Or maybe I should say "simplicity" (in quotes.) *Relative* simplicity. :-) That said, whenever Jordi is ready to migrate to a chip that can do an additional 2 or 3 serial ports, I'll be cheering him on.
NXT has so much processing power (much more than ArduPilot) that if you could just amplify the IR sensor readings to 0-5 volts NXT could interface directly to them via three sensor ports. Then the last port could be used for the servo MUX connection (ardupilot?). Bluetooth GPS is a good thing in the sense that basically every BT GPS on the market will fit and 5hz BT GPSs are becoming more and more common and cheaper. (I'm not really sure, BTW, if the BT GPS can be interfaced with NXT-G.) The only thing that remains to be solved is if the enduser (a student or a kid?) really even wants to interface with the IR sensors; making stabilization reliable on a graphical programming language isn't probably the easiest of tasks anyways.
Not an ideal autopilot, but possibly cool enough to attract new people to our world.
As Xander said, NXT hardware interfaces are expensive than their ardupilot equivalents.
Also, building an autopilot is no easy task. They are complex, expensive and easily damaged.
Realistically, besides the "coolness" factor, an autopilot offers no more advantages for teaching kids/students than a ground based rover which would be cheaper and less likely broken.
My $0.02
-Rd=]
-
1
-
2
of 2 Next