Questions about the BotBoarduino

I have some questions about the BotBoarduino:

  1. can it programmed using the Arduino programming language?,
    and if it can be done in the Arduino software?
  2. if it is quite enough to use that controller to program a Hexapod walker?.
    I have already built one, based on Arduino Mega controller,
    But it seemed not fast enough, there is a delay between all movement.
    I guess that as a result of the reading time of the controller.

thanks…

I can probably answer some of this…

Note: I have ported the Phoenix (3 DOF Hexapod code to run on an Arduino Mega and the Botboarduino). More details in the thread: viewtopic.php?f=20&t=6730

  1. Yes you can use the Arduino IDE to program the board. You select the Arduino Duemilovanove with Atmega328 as the board type…

  2. Difficult to answer. This is an Atmega328 running at 16mhz, likewise the Atmega is also probably running at 16mhz, so probably similar results. Note: the Mega has some additional features which are nice, like more hardware comm ports and the like.

However: Back to the question to the underlying question. Are the different Arduinos capable of running a Hexapod (for now I am assuming a 3DOF with 18 servos). There are lots of factors that play into this.

a) What are you using to control the servos? In my port of the code over to the Arduino, I continue to use an SSC-32 board to control the servos. This helps offload a lot of the overhead from the Arduino and allows it to calculate the next move while the SSC-32 is taking care of the previous move. If you are having the Arduino handle it using the servo library, than the Mega can in theory handle the 18 servos. The Atmega328 in the Botboarduino can handle 16, so you run into a problem here. Also using the standard Servo library, when you issue a new write or writeMicroseconds, the library will instantly move the servo to it’s new position (whereas the SSC-32 will do it over a timed period). This in it self makes it like jerky… I have a modified version of the servo library that does timed moves, that I use in my port of the Lynxmotion biped Brat code. But again the non-Mega version of the Arduinos can only handle 16 servos…

b) What are you using to control the hex? Something like the PS2? If so, yes there will be time while the PS2 read code is happening that you can not issue new servo positions… But again this comes back to how are the servos controlled? Also in the Phoenix code base we have timing stuff in place to issue the next command when the previous one completes. Alternatively with the SSC-32 we have also done it by asking the SSC-32 if it completed the previous command. The asking the SSC-32 version does introduce a delay as we wait a certain number of microseconds between times we ask the SSC-32, plus it takes time to ask, plus for the SSC-32 to reply… So most of the time we rely on simply knowing we told the SSC-32 to take n Microseconds to do a move, and we wait that long before we issue the next move…

Good Luck
Kurt

I using an SSC-32 board to control the servos.
using a serial communication to move servos
example:
Serial.print("#");
Serial.print(S11,DEC); //servo pin 11
Serial.print(" P");
Serial.print(S11MID-AS11180/PI/0.12,DEC); //the position
Serial.print("#");
Serial.print(S10,DEC);
Serial.print(" P");
Serial.print(AS10
180/PI/0.12+750-50,DEC);
Serial.print("#");
Serial.print(S09,DEC);
Serial.print(" P");
Serial.print(750+AS09*180/PI/0.12-200,DEC);

Serial.print(" T");
Serial.print(SPEEDGAIT,DEC);
Serial.println();
delay(DELAY);
i see that in yours project, there is not so much serial communication.

to control the hex i use a IR Receiver.

thanks

Kurte’s point B is an interesting one, the fact that a new command cannot be issued while reading in the PS2 inputs. Obviously the PS2 has been bitbanged over digital inputs, a simple enough job, but wasteful for a board like this with SPI hardware built in. PS2 can be interfaced over the SPI hardware with a couple of board modifications (pull ups mostly) so that the messaging comes in and is handled in parallel with the main execution. You need to use an interrupt to toggle a pin a couple times (acknowledge or attention, I’d have to double check) to keep the remote happy, but doing it this way also frees 3 pins (sck, mosi, miso instead of 3 digital pins) for other uses. I’ve always been depressed by the wasteful usage of pins on the arduino, though it looks like this version has more of them broken out usefully.

On a similar note to lynxmotion, I see warnings all over about reversing plus or minus will fry the boards which is true, I’d recommend mosfet protection as the link below on these boards as they are for beginners, should jump the cost by a few cents tops in bulk.

ti.com/lit/an/slva139/slva139.pdf

Sorry for derailing the thread a bit!

Yep, I understand what you are saying about bitbang wasting time and the like. Maybe someday I will experiment with using the hardware SPI for this. But as for saving IO pins? Maybe not. That is SCL, MISO, MOSI are on digital pins 11-13 I believe. Then the next question when using the hardware port is to make interrupt driven or not. If not, may not save much other than it may not interfere as much with interrupt functions…

As for adding in something like a mosfet, I am not a complete electronics expert, but I believe that these will cause a voltage drop, which when you are trying to use 6V batteries (common for lots of the servos used here) and need to feed it into a 5V voltage regulator, there may be issues of getting a high enough voltage, even when using a LDO regulator.

Kurt

Yeah you’d have to interrupt it for any gains. I hadn’t looked closely enough I guess, I always avoid breaking out the SPI to digital pins, not that It’s really necessary, just habit. I’m a little more paranoid because I always start by stripping out the arduino aspect and powering up avr studio, I’ve had a couple cheap programmers that seemed to interact strangely with components hanging on the SPI line… in particular an airsoft cannon that fired while programming! And it would take a few attempts to download because it would crash half the time.

The drop with a decent mosfet isn’t too bad. They used to recommend using a diode for the application but thats a 0.7 (or 0.3) v drop which as you said, very significant. Mosfet voltage drop is Rds * I so if you aren’t running your servos that’s in the order of 0.05V or so, maybe a lot less. I’d consider just using the protected voltage for your micro and let the servos fry (actually I’m not sure what happens when you power them up in reverse, but I’m not going to go home and try). Most of the time beginners just set up the power to the board once and don’t really play with it again until massive rebuilds, so if they wait until they have a power good led, then hook up servos there shouldn’t be a problem. Anyway just a thought, I’m not sure how often it actually happens. I know I’ve gone through dozens of 741’s with that mistake, but never popped a micro by crossing the streams. It’s just one of those things that I’m surprised no one does. I don’t recall arduinos schematics with reverse protection, but I’m 90% sure I’ve seen it on a few Pololu boards, motor controllers in particular.

Hello!
Excuse me but I don’t understand.
Can I control a Phoenix 3DOF Hexapod using ONLY a BotBoarduino for the electronic?
With this board I can control more than 18 servos, what is the problem?

Another question: Lynxmotion has an official XBee shield for the BotBoarduino or I have to buy an Arduino XBee shield such this: iteadstudio.com/product/xbee-shield-and-btbee/?

Thanks!

Hey you emailed this too. Yay…

The Botboarduino can not control a phoenix by itself. It requires the SSC-32 too. We are almost done with the new tutorials.

I do not understand the second question.

We do not have any shields.

I think he is asking if you sell an XBee shield for the board. I am pretty sure the answer is no. Also I believe the board should work with most of the XBee shields. I personally do not use XBee shields as they typically use IOPINS 0,1 the hardware port, which is the same as the USB connection. Often to reprogram the board you often have to remove the XBEE…

Kurt