I just realized I have no resistors between the RX and Activity Board...
facepalm.jpg
I didn't realize that you were using a PAB (Prop Activity Board) until I checked and checked again the first one, and saw that you struck out the BOE and replaced it with the Activity term instead.
Now that I think about it, I do not believe the BASIC Stamp is capable of flying. Scooting along on the ground sure, but not flying. The Prop 1, certainly.
However my later ideas after seeing Ken's amazing idea still stand.
The OP pulled a bait and switch! I will at some point make the BS2 board fly. With the BS2 it was never intended for the MCU to control the copter. The BS2 could do stuff like remote controlling the wheels, sensors, control an autopilot, flight mode or auto-throttle for landing.
The same goes for the Propeller, even though the Propeller is directly connected it is transparent and control signals come from the radio transmitter and most of the work is done via the flight controller.
Also I haven't done anything with the Activity Bot, and so far I really like the PAB. It would be a shame to not re-use all of my past projects into this one. We still have pins, and cogs, ADC, audio, and breadboard space to be used up!
0. In drive mode FC is OFF
1. Switch to Flight Mode
2. Prop passes PWM between RC and FC
3. Pause
4. Prop pin/2N2222 controls FC power ON
5. Pause
6. FC boots/inits gyros (looks for arming signal)
7. Fly
8. Switch to drive mode
9. Prop pin/2N2222 controls FC power OFF
Right now the flight controller can see and feel things it will not understand. That usually results in an error and it will not arm. Controlling the FC power seems the only approach to reliability.
0. In drive mode FC is OFF
1. Switch to Flight Mode
2. Prop passes PWM between RC and FC
3. Pause
4. Prop pin/2N2222 controls FC power ON
5. Pause
6. FC boots/inits gyros (looks for arming signal)
7. Fly
8. Switch to drive mode
9. Prop pin/2N2222 controls FC power OFF
Right now the flight controller can see and feel things it will not understand. That usually results in an error and it will not arm. Controlling the FC power seems the only approach to reliability.
This project is going to be amazing. I was thinking that an RC transmitter was limited by the number of channels on the receiver. I want to experiment with a couple of nrf240L01 breakout boards which would allow me to send data.
Vanmunch built a mobile robot with an arm and a camera. That was a great project. I think he controlled it with a keyboard. One challenge will be to modify an RC radio to send commands.
(I won't start until it's too cold to fly my quadcopter)
One would think controlling the power to the FC would be very easy. It turns out to be not so easy. My initial thought of an NPN doesn't work. In the absence of a ground connection, the FC leaches ground from the signal wire connections to the Propeller. There are no other connections other than the PWM signal wires. When you connect the FC +5v (and no grnd) you get a dim power light. The Propeller pins they're attached to are all set as outputs too. After an hour of taking the entire thing apart and putting it back together I can replicate the same scenario with just RC gear. I suppose I could ask about it in the OpenPilot forum.
Anyway after wasting an hour or so on that I ended up using an NTE2383 P-Channel MOSFET to control the power instead of ground. It works like a charm. The mode selector switch powers up the FC when in fly mode, and turns it off in drive mode!
@xanadu, Can you cut power to the power distribution board? Is the power consumed by the esc's an issue?
I guess a relay could control the power to the distro board, but in the last test the ESCs and FC behaved very well! The ESCs beep when the FC turns off, other than that they don't mind being on when the FC is off. They also re-arm when the FC turns on, so you get a lot of cool confirmation beeping.
The first test drive and fly video is uploading now. There was a little issue, but it's a small one. This thing is working very well!
I'm putting an FPV camera on it, and we're going to setup some obstacles for it.
Oh wow.
That does make my entire idea work. Do you recall that video that was on the main store-site where they showed a Boebot wearing tracks of course, and probably those grabbers, scoot out and rescue a fallen down fellow mechanical?
That's what I was thinking of when I saw Ken's creation. The Boebot would simply be flown to its destination, and the transporter would land and the Boebot would crawl off and find the target and grab it and scoot back to the transporter, from there they'd fly back to the, ah, base.
Only catch is the code for both. I haven't a clew as to how the heck to program a bird like the one shown in the photo, the bot certainly, but not the bird.
I don't remember the video. I will keep looking for it. If you're remote controlling the copter and the bot individually I don't think there is any code that needs to be written. If either were to be autonomous, there would be a lot of code!
It would be really wild if you made the Elev-8 downlink the commands to the BOE Bot. If the Elev-8 can loiter over the robot you might not need a camera on the robot. Imagine remote controlling a ground robot using a camera on a copter 15' above it from a remote location! That would be mind blowing fun for me lol.
I was originally thinking of the first generation of Martian landers, the Viking pair, (which sadly have been finally shut down as their ability to think clearly had run out.) they would basically follow instructions that flew there from down here, not far from where you live probably, the orbiter would read them, realize that they weren't for any of her issues, and send them down to the lander, that lady would in turn act upon them, and either poke around more in the ground. Or take a few more photos.
Now we've got rovers exploring Mars, and (and annoying the Martians!), and there is an orbiter there, but her job is more mundane, just watching the planet; stuff is sent directly. Then the rovers do their thing.
It especially interesting in that Curiosity's last messages back stopped containing a complaint that she felt she never really left earth, because the patch where she landed, looked very much like the desert plot in the Mojave where they would test every single instruction first with the one who stayed here, and then it would get sent up after they were convinced it would work.
What your doing is much like the gang at JPL (which is in Pasadena at Cal Tech) or the group here at Goddard who's in Maryland. In which your creations are exploring the world, but acting like they just arrived.
Buck, thanks. I see where you're coming from. It would be a lot like a space probe and rover. I think I need to add another device to it, maybe a ground station.
Erco, thanks! The FAB is no fad haha. Driving the flying FPV robot is a lot of fun.
I want to go work on it some more. I think it's too hot out to not work on robots today lol.
I added some basic data logging functionality. As an example I'm starting out with a PING. I have always wanted to evaluate a PING on a copter. There are some obvious drawbacks but that is okay too. Experimentation is the key, regardless of the sensor used.
The code and log file are attached.
Here's an Excel graph of the PING distance in centimeters. It (and other sensors) have a way to go, I just wanted to be able to write to SD using another cog for now, and it works great!
Using the PING for absolute altitude is interesting. It seemed to handle the vibration well, and give accurate readings, at least indoors. I've read a lot of conflicting results from others. On top of the sheer awesomeness of having another copter, I'm also excited to program my own data logging.
If you look at the graph above, you should also know that I was flying around and the angle of the PING and the ground changed throughout the flight. The PING is only pointed straight down when the copter is level. The copter was not level most of the flight.
There are a few ways to make it more accurate.
1. Put the PING on a gimbal, if you had a copter with a camera gimbal.
2. Use an IMU and only take measurements when level.
3. Use an IMU to compute the angle, but only for perfectly flat terrain.
I think #2 is the best bet. The Flight Controller has outputs for a two channel gimbal. If we can take those PWM signals and use them to tell the Propeller the copter's attitude the Propeller can omit not read the erroneous readings.
Buck, thanks. I see where you're coming from. It would be a lot like a space probe and rover. I think I need to add another device to it, maybe a ground station.
Erco, thanks! The FAB is no fad haha. Driving the flying FPV robot is a lot of fun.
I want to go work on it some more. I think it's too hot out to not work on robots today lol.
Great then. As it happens my work with practically everything that Parallax sells that lives here, was largely influenced by what's currently at work out there. The BOE-BOT rescue video that I saw also influenced another idea, but I'll darned if I can find it to present in this venue.
Depending on how far away you are, perhaps the best place to test the completed gadget, might even be the same basic region in the Mojave that they use.....
Erco next time your taking your twins grocery shopping be sure to snag two bags of Oreos you've earned them.
How about I up the ante with the gripper everyone is talking about?
The lighting is bad, but the video is gripping. I'm also playing around with Audacity and voice effects to simulate real life scenarios. Courses become missions around here!
I've maxed out the servo outputs of JM's 8 servo Object. That allows for 5 channels for flight control, and 3 for servo motors. I think I can get away with this for the time being.
Comments
The OP pulled a bait and switch! I will at some point make the BS2 board fly. With the BS2 it was never intended for the MCU to control the copter. The BS2 could do stuff like remote controlling the wheels, sensors, control an autopilot, flight mode or auto-throttle for landing.
The same goes for the Propeller, even though the Propeller is directly connected it is transparent and control signals come from the radio transmitter and most of the work is done via the flight controller.
Also I haven't done anything with the Activity Bot, and so far I really like the PAB. It would be a shame to not re-use all of my past projects into this one. We still have pins, and cogs, ADC, audio, and breadboard space to be used up!
0. In drive mode FC is OFF
1. Switch to Flight Mode
2. Prop passes PWM between RC and FC
3. Pause
4. Prop pin/2N2222 controls FC power ON
5. Pause
6. FC boots/inits gyros (looks for arming signal)
7. Fly
8. Switch to drive mode
9. Prop pin/2N2222 controls FC power OFF
Right now the flight controller can see and feel things it will not understand. That usually results in an error and it will not arm. Controlling the FC power seems the only approach to reliability.
Vanmunch built a mobile robot with an arm and a camera. That was a great project. I think he controlled it with a keyboard. One challenge will be to modify an RC radio to send commands.
(I won't start until it's too cold to fly my quadcopter)
One would think controlling the power to the FC would be very easy. It turns out to be not so easy. My initial thought of an NPN doesn't work. In the absence of a ground connection, the FC leaches ground from the signal wire connections to the Propeller. There are no other connections other than the PWM signal wires. When you connect the FC +5v (and no grnd) you get a dim power light. The Propeller pins they're attached to are all set as outputs too. After an hour of taking the entire thing apart and putting it back together I can replicate the same scenario with just RC gear. I suppose I could ask about it in the OpenPilot forum.
Anyway after wasting an hour or so on that I ended up using an NTE2383 P-Channel MOSFET to control the power instead of ground. It works like a charm. The mode selector switch powers up the FC when in fly mode, and turns it off in drive mode!
I guess a relay could control the power to the distro board, but in the last test the ESCs and FC behaved very well! The ESCs beep when the FC turns off, other than that they don't mind being on when the FC is off. They also re-arm when the FC turns on, so you get a lot of cool confirmation beeping.
The first test drive and fly video is uploading now. There was a little issue, but it's a small one. This thing is working very well!
I'm putting an FPV camera on it, and we're going to setup some obstacles for it.
What when wrong?
I figured out the problem in the time it took to upload the video. I still wanted to share the maiden flight/drive voyage though! Very exciting.
FPV camera is on, obstacle course is being assembled.
Now is the time to clean up code, and wiring.
Here's the SPIN code as of now.
That does make my entire idea work. Do you recall that video that was on the main store-site where they showed a Boebot wearing tracks of course, and probably those grabbers, scoot out and rescue a fallen down fellow mechanical?
That's what I was thinking of when I saw Ken's creation. The Boebot would simply be flown to its destination, and the transporter would land and the Boebot would crawl off and find the target and grab it and scoot back to the transporter, from there they'd fly back to the, ah, base.
Only catch is the code for both. I haven't a clew as to how the heck to program a bird like the one shown in the photo, the bot certainly, but not the bird.
It would be really wild if you made the Elev-8 downlink the commands to the BOE Bot. If the Elev-8 can loiter over the robot you might not need a camera on the robot. Imagine remote controlling a ground robot using a camera on a copter 15' above it from a remote location! That would be mind blowing fun for me lol.
Now we've got rovers exploring Mars, and (and annoying the Martians!), and there is an orbiter there, but her job is more mundane, just watching the planet; stuff is sent directly. Then the rovers do their thing.
It especially interesting in that Curiosity's last messages back stopped containing a complaint that she felt she never really left earth, because the patch where she landed, looked very much like the desert plot in the Mojave where they would test every single instruction first with the one who stayed here, and then it would get sent up after they were convinced it would work.
What your doing is much like the gang at JPL (which is in Pasadena at Cal Tech) or the group here at Goddard who's in Maryland. In which your creations are exploring the world, but acting like they just arrived.
Now you see where I'm coming from, I do hope.
Erco, thanks! The FAB is no fad haha. Driving the flying FPV robot is a lot of fun.
I want to go work on it some more. I think it's too hot out to not work on robots today lol.
I say you go for a hot air ballon using your flame thrower!
xanadu - this is a wonderful project! Makes me smile too!
I added some basic data logging functionality. As an example I'm starting out with a PING. I have always wanted to evaluate a PING on a copter. There are some obvious drawbacks but that is okay too. Experimentation is the key, regardless of the sensor used.
The code and log file are attached.
Here's an Excel graph of the PING distance in centimeters. It (and other sensors) have a way to go, I just wanted to be able to write to SD using another cog for now, and it works great!
If you look at the graph above, you should also know that I was flying around and the angle of the PING and the ground changed throughout the flight. The PING is only pointed straight down when the copter is level. The copter was not level most of the flight.
There are a few ways to make it more accurate.
1. Put the PING on a gimbal, if you had a copter with a camera gimbal.
2. Use an IMU and only take measurements when level.
3. Use an IMU to compute the angle, but only for perfectly flat terrain.
I think #2 is the best bet. The Flight Controller has outputs for a two channel gimbal. If we can take those PWM signals and use them to tell the Propeller the copter's attitude the Propeller can omit not read the erroneous readings.
Great then. As it happens my work with practically everything that Parallax sells that lives here, was largely influenced by what's currently at work out there. The BOE-BOT rescue video that I saw also influenced another idea, but I'll darned if I can find it to present in this venue.
Depending on how far away you are, perhaps the best place to test the completed gadget, might even be the same basic region in the Mojave that they use.....
Erco next time your taking your twins grocery shopping be sure to snag two bags of Oreos you've earned them.
I can't help but imagine a bot with a gripper that tilts.
Kinder and gentler encouragement is offered to Carol, Amanda, and the ladies.
Toddler as a hanging weight may be easier.
You mean like this old one-man chopper?
Literally... see also http://www.damninteresting.com/hovering-in-history/
http://airandspace.si.edu/collections/artifact.cfm?object=nasm_A19610070000
And you can still buy plans from the 1950's... http://alternative-technologies.org/aircraft.php
https://en.wikipedia.org/wiki/Sikorsky_Cypher
The lighting is bad, but the video is gripping. I'm also playing around with Audacity and voice effects to simulate real life scenarios. Courses become missions around here!
Video Link
I've maxed out the servo outputs of JM's 8 servo Object. That allows for 5 channels for flight control, and 3 for servo motors. I think I can get away with this for the time being.
https://www.youtube.com/watch?v=ks_M2pvOpF0
Another ELEV-8 Super carrying robots. In China.
Ken Gracey
Buck did you try the link?