Extremely basic questions regarding Activity Bot, treads and arduino
Hello everyone!
First of all, an overly wordy and long introduction, but please feel free to skip straight to the numbered questions!
I'm a software programmer by trade, with near zero electronic or robotic knowledge and with no confidence in my 'connecting' abilities. I never even looked at anything robotic, until a few days ago when a gaming website did a short article on NASA's Valkyrie robot. Reading that brought me to the DARPA challenge, which I watched part of the stream. I was very intrigued by it, and then some people in the chat mentionned that cheap robots were now available, like the UBR1 (35k). Somehow, that brought me to learning about little programmable robots, but the whole soldering thing was a definitive no go for me at this point... And then I came across it. A perfect tool to dip into a new hobby out of curiosity.The holy grail. A robot that blew my mind with possibilities and that would fill my newly discovered itch.
The S2 Scribbler!
Actually programmable, pre-assembled, mobile, cheap, infrared sensors! Amazing! I was about press the "Buy" button, but then I checked the other offerings... The Activity Bot is more versatile with more sensor types (Although it is missing line-reading hardware out of the box), but it requires assembling and circuitry. So I decided against it, put the Scribbler in my cart, and... I went to read the tutorial sections for the S2, and noticed that there was an extremely detailed tutorial for the Activity Bot. Detailed enough that even me might be able to build without frying the board in the first minute... So in the end I placed an order for the Activity Bot a few days ago. I feel as if I've done a terrible mistake and that I should have went with the Scribbler instead, but too late for that now since I placed my order two days ago. So here's my current plans:
Short Term: Patiently wait for my Activity Bot, and somehow manage to assemble it without frying off the board or breaking anything.
Middle Term: Follow the entire Activity Bot tutorials careful. Learn. Experiment. See the differences between real-world hardware instead of the "perfect virtual world" I'm used to. Develop some basic algorithms and try them out.
Loooong Term: Develop my ultimate goal: The Plowbot. A tiny robot with a small plow in front for when there's 1cm of snow outside and that can "clean" in a reasonable pattern. I have some idea how to program it and some ideas of the difficulties I will encounter while doing so, but it sounds like a nice, actually doable project (99% useless robot, but a fun challenge and learning experience).
Basically, what I'm looking for is some general direction tips regarding the hardware regarding the long-term project: I'm definitively not at a knowledge stage where I can make informed decisions, or understand too technical information at this point in time. Just something to keep in the back of my mind while slowly working through the short and middle term parts. So here's my extremely basic questions, sorry for the newbieness!
1- Propeller activity board vs Arduino board
Everywhere I look at, it's always "Arduino this, Arduino that". What I'm wondering is "why"? The single processor seems to be a huge disadvantage (I've read things like "my robot needs to stop scanning so that it can play a sound" for example). Both have a relatively comparable IDE at first glance. The only thing I can see is price (Basic arduinos seems to be around 25$ instead of 45$ although some arduinos go way beyond that), but is there any reasons why I would not use an activity board for my project?
2- BOE Bot treads on an Activity Bot
For my loooong term project, I would like to have treads for two reasons: A) I think it would be more effective for it's intended purpose and
... I really like treads for some unexplainable reasons. In the Activity Bot introduction video, there's a mention that all BOE-BOT attachments are compatible with the Activity Bot. I can understand for the grippers or similar attachments, but I'm really not so sure about the BOE tank threads (The same applies to the crawler kit). There's mentions that code is mostly "transparent" for the BOE bot for deplacements, but the Activity Bot is different with it's wheel encoders. And plus, the BOE is in Spin and the Activity board is in C so I assume that putting the BOE treads on the Activity Bot would be foregoing all the handy built-in movement functions of the Activity Bot. Correct?
3- 4WD Rover 5 chassis on an Propeller Activity Board
Let's say option #2 is not too viable or that I'd end up wanting a second robot for the Plowbot purpose, and that I'd want something stronger and bigger for it's chassis than a treaded activity bot. Like the 4 wheel drive Rover 5 chasis for example (Okay, it's only sliiightly bigger, but still). I know the 2 wheel drive version would work with a PAB, but I'm unsure about the 4wd version. From what I read, you cannot use a basic arduino board: Since there's 4 motors and that there's a need for two connectors for each (direction and speed), there's a lack of available pins. With my currently extremely limited electronic knowledge (I quickly read through the Activity Bot tutorials and that's nearly the extend of it as of now) and looking at the activity board screenshots, it looks like as if there would be enough connections, with enough left-over for the necessary sensors... But I might be looking at the wrong things entirely. So question is, would a PAB be able to control the 4wd Rover 5 alongside with some sensors?
Thank you very much for your time and sorry for the extremely newbie questions (especially since they are for a looong term project and not current ones). I'm not sure how I went from no interest in robotics at all to NASA's Valkyrie to the Scribbler and the Activity Bot in the span of two days, but here I am
First of all, an overly wordy and long introduction, but please feel free to skip straight to the numbered questions!
I'm a software programmer by trade, with near zero electronic or robotic knowledge and with no confidence in my 'connecting' abilities. I never even looked at anything robotic, until a few days ago when a gaming website did a short article on NASA's Valkyrie robot. Reading that brought me to the DARPA challenge, which I watched part of the stream. I was very intrigued by it, and then some people in the chat mentionned that cheap robots were now available, like the UBR1 (35k). Somehow, that brought me to learning about little programmable robots, but the whole soldering thing was a definitive no go for me at this point... And then I came across it. A perfect tool to dip into a new hobby out of curiosity.The holy grail. A robot that blew my mind with possibilities and that would fill my newly discovered itch.
The S2 Scribbler!
Actually programmable, pre-assembled, mobile, cheap, infrared sensors! Amazing! I was about press the "Buy" button, but then I checked the other offerings... The Activity Bot is more versatile with more sensor types (Although it is missing line-reading hardware out of the box), but it requires assembling and circuitry. So I decided against it, put the Scribbler in my cart, and... I went to read the tutorial sections for the S2, and noticed that there was an extremely detailed tutorial for the Activity Bot. Detailed enough that even me might be able to build without frying the board in the first minute... So in the end I placed an order for the Activity Bot a few days ago. I feel as if I've done a terrible mistake and that I should have went with the Scribbler instead, but too late for that now since I placed my order two days ago. So here's my current plans:
Short Term: Patiently wait for my Activity Bot, and somehow manage to assemble it without frying off the board or breaking anything.
Middle Term: Follow the entire Activity Bot tutorials careful. Learn. Experiment. See the differences between real-world hardware instead of the "perfect virtual world" I'm used to. Develop some basic algorithms and try them out.
Loooong Term: Develop my ultimate goal: The Plowbot. A tiny robot with a small plow in front for when there's 1cm of snow outside and that can "clean" in a reasonable pattern. I have some idea how to program it and some ideas of the difficulties I will encounter while doing so, but it sounds like a nice, actually doable project (99% useless robot, but a fun challenge and learning experience).
Basically, what I'm looking for is some general direction tips regarding the hardware regarding the long-term project: I'm definitively not at a knowledge stage where I can make informed decisions, or understand too technical information at this point in time. Just something to keep in the back of my mind while slowly working through the short and middle term parts. So here's my extremely basic questions, sorry for the newbieness!
1- Propeller activity board vs Arduino board
Everywhere I look at, it's always "Arduino this, Arduino that". What I'm wondering is "why"? The single processor seems to be a huge disadvantage (I've read things like "my robot needs to stop scanning so that it can play a sound" for example). Both have a relatively comparable IDE at first glance. The only thing I can see is price (Basic arduinos seems to be around 25$ instead of 45$ although some arduinos go way beyond that), but is there any reasons why I would not use an activity board for my project?
2- BOE Bot treads on an Activity Bot
For my loooong term project, I would like to have treads for two reasons: A) I think it would be more effective for it's intended purpose and
... I really like treads for some unexplainable reasons. In the Activity Bot introduction video, there's a mention that all BOE-BOT attachments are compatible with the Activity Bot. I can understand for the grippers or similar attachments, but I'm really not so sure about the BOE tank threads (The same applies to the crawler kit). There's mentions that code is mostly "transparent" for the BOE bot for deplacements, but the Activity Bot is different with it's wheel encoders. And plus, the BOE is in Spin and the Activity board is in C so I assume that putting the BOE treads on the Activity Bot would be foregoing all the handy built-in movement functions of the Activity Bot. Correct?3- 4WD Rover 5 chassis on an Propeller Activity Board
Let's say option #2 is not too viable or that I'd end up wanting a second robot for the Plowbot purpose, and that I'd want something stronger and bigger for it's chassis than a treaded activity bot. Like the 4 wheel drive Rover 5 chasis for example (Okay, it's only sliiightly bigger, but still). I know the 2 wheel drive version would work with a PAB, but I'm unsure about the 4wd version. From what I read, you cannot use a basic arduino board: Since there's 4 motors and that there's a need for two connectors for each (direction and speed), there's a lack of available pins. With my currently extremely limited electronic knowledge (I quickly read through the Activity Bot tutorials and that's nearly the extend of it as of now) and looking at the activity board screenshots, it looks like as if there would be enough connections, with enough left-over for the necessary sensors... But I might be looking at the wrong things entirely. So question is, would a PAB be able to control the 4wd Rover 5 alongside with some sensors?
Thank you very much for your time and sorry for the extremely newbie questions (especially since they are for a looong term project and not current ones). I'm not sure how I went from no interest in robotics at all to NASA's Valkyrie to the Scribbler and the Activity Bot in the span of two days, but here I am
Comments
2) I don't think the BoeBot treads will work on the Activity Bot. I had enough problems getting them to work well on the Stamp BoeBot. With a different motor and the wheel encoders, I'm not sure they'll even fit.
3) A Rover chassis sounds much better for your PlowBot. You can set it up with the ground clearance needed and it's big enough and powerful enough for the work. You can carry a big enough battery pack for ballast and for run-time. A PAB should be fine. Remember that you'll need motor controllers for each motor. The Dagu quad motor controller looks like a good fit. You'll need 8 I/O pins for motor control, 4 analog inputs for motor current, and 4 I/O pins for the encoders. That still leaves 6 I/O pins for sensors. Remember that the Dagu board is designed to run off +5V while the Propeller is designed for +3.3V. You'll need resistors (3.3K) in series with the encoder outputs to the Propeller and probably the motor outputs from the Propeller. The ADC inputs on the Activity Board can handle 5V signals.
The AA battery pack shown with the Rover looks kind of puny. You'll want something with a higher current capacity, maybe an R/C 7.2V or 7.5V battery pack.
Do you need 4WD? If you're going to use treads, that won't work very well. If you're going to use treads, 2WD and a dual motor controller would work fine.
Regarding the Scribbler vs Activity Bot, I'll stick with the Activity Bot. The Scribbler is extremely interesting since there's absolutely no chance to mess-up, is durable, has both front and downward facing IR out of the box, and it's 50% cheaper. The coding parts are clear enough and I see the fun that lies with building and expanding algorithms all while interfacing with the robot's hardware.
The thing is, I stand to learn more with the Activity Bot. The coding element is very similar, but I have nearly zero knowledge of electronics or even any confidence in my assembly skills. However, the Activity Bot tutorials are EXTREMELY detailed and is something that maybe even me should be able to build correctly. It's more "risky" than the Scribbler (There's the possibility I mess up and it's twice the price for relatively similar coding capabilities), but hopefully I should be fine with the awesome tutorial's guidance and end up getting some basic electronic knowledge and manipulation experience at the same time.
Regarding the Plowbot, thank you very much! It's exactly the information I was looking for! A proof of concept about what would work and what would not. Hardware suggestions to make me think and understand why that would work for that project some day in the future.
Regarding the 4wd drive, it was not a necessity. I figured that the 4wd model made sense considering that there is going to be a bit of mass to push, and I could normalize the speed of the wheel with the encoder's data... Of course that doesn't take into account the effect of 4wd on a treaded vehicule which I never even considered (or aware of). 2WD would be easier I admit (plus, the 2WD model is sold on the Parallax site so it's even simpler). Either way, more things to read about!
On reading about the motor driver, my first reaction was "Why would I need one?" After reading what it was, my reaction became "That make sense, but why doesn't the Activity Bot need one then?" And then I finally understood that the Activity Bot is not using DC motors for it's wheels... So yeah, there's a lot of learning to do before I even consider starting this project, but at least now I have viable hardware options to investigate and learn about (... plus basic electronics of course). A big thank you for the great information!
On the contrary, 4WD with treads work great.
@Zywack, The PAB might not be the best board to run the Rover 5. You'll need all the I/O pins you can get and the PAB has too many dedicated to things you don't need. I'd suggest the Propeller Project board. Here's a link to my Rover 5 project which uses treads.
I like the Motor control board Mike linked to. I have several of those myself. If you get one just don't follow the suggestions to use two control pins. I have no idea why Pololu would make the error (which Parallax copied). If you use one of those motor controllers ask me how to connect it.
I'm using cheap L298N motor controllers on both my Rover 5 projects right now. The L298N has a deservedly bad rap since it drops the motor voltage by a couple of volts. I'm using them since they're cheap.
I hope you take a look at both my Rover 5 threads. There should be a lot of information that would be useful to you.
BTW, I used to have a lot of trouble with the treads coming off the Rover 5. Since I've made the modifications mentioned in the thread, I can't loose a tread no matter how aggressively I try.
The ActivityBot is using DC motors it just the CR servo has a built in driver. The built in driver is one of the reasons CR servos are so popular in small robot, they're very easy to control with a microcontroller.
I haven't read through all your questions nor all the answers but it case no one mentioned it, the Propeller can run circles around the Arduino. If you look around the internet, you'll see a lot of 4WD Rover 5 projects. I've been keeping my eyes open for a 4WD Rover 5 which uses all four quadrature encoders. I haven't found any besides mine that use all four QEs. Part of the reason for this is the Propeller makes it much easier to do these multiple tasks than the commonly used Arduino.
I hope you take a look at post #2 of my index (see my signature). I've have links to many of my Propeller projects listed there. I think many of the projects would have been made much harder if I had to use an Arduino as the controller.
The main reason I was looking at the Activity Board was for the following reasons: 1) the breadboard connections: At this point I definitively prefers to keep soldering at a minimum. 2) The SD card is a nice plus (I'm planning on using it for debugging and mapping purposes). 3) My basic learning experience is going to be through the Activity Bot, so having some familiarity in a more open project makes sense.
I think that 6 free inputs should actually be enough for my project, but I'll be mapping out everything I need exactly after I do some experiments with the Activity Bot and see if it's enough or not and decide from that point (2wd model or different board).
Was there ever a consensus if the 2wd design is actually less prone to lose it's treads? There's been multiple mentions in your threads that the 4wd in general (or treads with 4wd in general) are far more prone to losing it's treads. I know that you managed to get the treads to work great even with the 4wd models with the wheel modifications, but it's never been confirmed or denied that the 4wd makes it harder to keep the treads on.
IMO, 4WD does not make it harder to keep the treads on.
BTW, I've done a lot of testing I never posted. Tried a lot of different combinations with gearbox angles, wheel mods and gearbox braces. The modified wheels help keep the treads on when the other factors aren't optimal but if the gearboxes are aligned at the proper angle and gearboxes are pulled inward (they tend to bow out) then the stock wheels work very well. I wasn't able to throw a tread with the stock wheels if the other items were taken care of.
I used encoder feedback in all my tests but I don't think even without the feedback using two motors per tread would be a problem. If one motor has a tendency to move faster than the other, the difference will be quickly eliminated by the tread helping the slow one along and slowing the faster motor.
The price difference between a 4WD version and 2WD version doesn't seem to be very much and you get twice the power with the 4WD version.
I suggest you make a list of all the pins you'll need to control the robot. It's possible to reduce the number of pins required to drive the motor by using an inverter on the direction pins. The encoders take two I/O pins each motor. I think the encoder pulses are slow enough on the Rover 5 that it may be possible to use a 74HC165 parallel to serial chip to read the encoders. This would reduce the pins needed to monitor the encoders from 8 to 3. This mod is on my todo list.
I've been working on an improved version of my encoder reading software. I previously counted transitions to measure speed but my lasted object computes the speed from the time between transitions. This allows low speeds to be measure much more accurately. I haven't yet incorporated these changes into my Rover 5 projects. I do intend to update my Rover 5 with these changes soon. I plan to use the improved code to allow the Rover 5 to autonomously travel through the snow this winter.
Stupid question about the Activity Bot: Can it run using Nimh batteries instead of alkaline? The product page for the Activity Bot refers to requiring five 1.5v batteries (7.5v). I'd rather be using nimh batteries if possible (more economical), which would make 6v if I use the included 5-slot battery pack. The Activity Board page states that the board is 6v to 9v, and I'm not seeing anything that requires 7.5v in the activity bot kit. Would the Activity Bot work fine with 5 nimh batteries?
While I don't believe "there's no such thing as a stupid question", your question doesn't come close to being stupid.
Yes, NiMH would work great in the AB. In fact they would work much better than alkaline. There are many robot kits that suggest NiMH and not alkaline since NiMH can provide higher currents than alkalines.
IMO, five AA NiMH is a great match for the AB. Most servos can be powered directly from five NiMH cells (it's a very common pack size with RC gear). Even though the servos can be powered directly from "Vin" (raw battery power) you might want to power them with regulated 5V since you'll get more consistent speed from the motors (CR servos).
When I tried driving my cheap bot in a figure 8, I couldn't get it to work with unregulated power to the servos. The speed kept changing as the battery pack's charge state would change. You can read the details in post #3 of the cheap bot thread. I used Li-Ion cells to boost the voltage since I had a four cell battery holder. Your 5 cell NiMH will also work well.
The AB has encoders which can go a long way to overcoming the problem of changing voltages. You might want to try using the AB with servos powered from both Vin and 5V to see which you like more.
I think the ASC+ is a great board but I'd only suggest getting it if you already have Arduino shields you want to use on it. IMO Arduino shields can be a big pain to deal with. It's often hard to use multiple shields since both shields will want to use the same pins on the control board.
IMO, if you want to get into robotic (and why wouldn't you?) you'll need to learn to solder. There are lots of great videos to show you how. You'll save a lot of money by being able to configure your own boards.
There are lots of inexpensive but good soldering irons. Get good old fashioned lead & tin solder (it's much easier to use than lead-free stuff IMO). Get some solder wick so you can do surface mount stuff. Buy a Propeller Project Board (PPB) and a MCP3208 chip (an 8 channel analog to digital converter (ADC)). You ought to also get the little uSD card holder while you're getting the PPB.
Before I continue with a shopping list I'll stop to say wait until you've had a chance to use your AB a while. After you've used it for a while you'll get a better understanding of what type of things you'll want to do in the future. There's an awful lot of stuff to learn and the AB seems like a great place to get started.
It's certainly possible to do a lot of interesting robotic projects without ever soldering. IMO, robotics is much more rewarding if you can wire up your own boards using a soldering iron. But for now, the soldering iron can wait.
1) Do you have 64k for your application on the Activity Board, or 32k?
Product detail says 64k,but when I try to load my application in EEPROM, I receive an "application too large for your selected project" error as soon as I pass 32k.
Right now, I have my Activity Bot setup with the following: Ping with the turret, two ir leds and receivers angled toward the sides, one ir receiver facing upward to receive remote commands to select which music to play (or stop) alongside with the VEIO speaker. Everything works exactly as programmed: It roams pretty decently with the ping turret and ir working together rather well (at least for 10 hours of effort) and the music selection works just fine. I'm pretty proud of my little Activity Bot and I thought it'd take me much longer to reach this point.
Problem is, my application is at 31 800 bytes right now... My application itself is not that big, but the required libraries (wav, abdrive, servo, ping, math, ect) fills a huge amount of memory, especially the wav library. I have multiple upgrades I want to make: Dedicate one processor to handle the music routines so that the bot can also accept a music change while scanning a path, add a volume control, considerably improve my roaming routines and makes it so that it scans for a path while it moves instead of stopping and then scan when one of the sensors find an obstacle too close, ect... But I can't add anything at all right now: A few lines of code and I bust the 32k limit.
But isn't it a 64k board based on the product details? 64k would be more than enough to do everything I want with it: Currently, roughly 75% of my memory is used by imported libraries, so even 40k would likely be enough for all my plans for this application.
I know that if I strip out the wav libraries I would have more than enough to fit all my upgraded navigation in 32k, but it's a fun feature I'd rather keep if possible.
Regarding the soldering, I'm not going to touch that for the time being, but I'm certainly not saying no somewhere down the line
The Propeller chip has 32K of RAM in the hub. This is the same for every Propeller chip. Most Propeller boards (this includes the Activity Board) have EEPROMs with 64K of memory.
I believe there are settings within the C compiler to allow it to use the additional EEPROM memory for programs larger than 32K. I have not used C much myself so I can't help more with this.
The CMM (compact memory model) the learn site examples use stores code in the Propeller chip's 32 KB Main RAM, and then one or more cogs (each with their own 2 K) fetch and execute machine codes from Main RAM. The 64 KB EEPROM allows you to save 32 KB of program and and additional 32 KB of data, all nonvolatile (survives resets and power cycling).
There's also a number of extended memory model options. For example, XMMC is one that allows you to run code from an external flash and some other devices. If you run a program in XMMC mode, you can only run that cog plus a number of programs that reside in each cog's 2 K of memory. These are typically written with COGC or PASM (propeller assembly language). Although your program could grow into the megabyte range, the catch is that you cannot currently launch a CMM code with cogstart. So for the time being, using XMM would require that libraries that launch other cogs like abdrive, servo, and wavplayer would have to be translated from CMM to either COGC or PASM to get your application back to its current level of functionality.
Notice that I said "...cannot currently..." Parallax and the PropGCC team have been working together to create a version of XMM that allows the user to launch multiple XMM cogs, and from what I understand, they have a working prototype in one of the PropGCC development branches. When that becomes the branch used by SimpleIDE, we'll have the option of using a flash chip (up to a couple MB I think) or the Propeller Memory Card http://www.parallax.com/product/40004 for program storage with the option of launching multiple XMM cogs.
I'm not sure when these new features will be ready. They will run through some significant testing first. So in the meantime, like I said, let's take a look at your code. Hopefully we'll see some opportunities for program size reduction, and that'll get you back on the road for now.
Andy
Here's a copy of my code. It's not really in a state to be shared with the world (It's underdocumented, unclear, lacking functions and definitively not optimized)... But since I'm moderately proud of the end result (I can usually leave the Activity Bot unattended for over 15 minutes before it gets stuck anywhere while it's going randomly through multiple rooms in the house and it can avoid chair/table legs like a pro), I'll post it anyway.
I know that there's multiple improvements that can be made regarding code size, but they all feel like small improvements. Doing those would leave me with a small amount of free memoery, but I can't see it giving any significant amount. Just mounting the SD card, playing a Wav, and using the sirc.h library takes about 16k. When you add the servo, abdrive and simple libraries, I assume that my actual code is roughly 30% of the used space. Optimizing that 30% would obviously result in some available space (it's on the to-do list), but I assume it's going to be quite limited.
I'll admit I'm not too familiar with all those extended memory models you wrote about, but I'll go do some reading about those subjects. Thank you!
ZywackABNavigateMusic.zip
Note: If you want to compile the zipped code: Unzip to a folder, then use SimpleIDE to open SywackABNavigateMusic.side from the folder (not from the zip). Click SimpleIDE's bottom-left Show Project Manager button, and delete all the libraries in the project manager. This will cause it to correctly look to the library subfolder for the libraries.
One suggestion to make the warnings go away -add two lines above your main function:
int musicCheck();
int panCheck();
Those forward declarations will make the warnings go way when you compile because they give the compiler a heads-up that it will find those functions later.
Looks like you're right, SD, wavplayer and abdrive have the biggest memory footprints. Are you still thinking about going to tank treads? If so, abdrive could be substituted with a much smaller library. Distance would always be a function of servo signals and run time at that point.
Andy