BasicMicro - Forums

Should it be necessary to use the reset button on the 5a? I have tried both self powered and external powered logic. Also, the status LED 1 goes out, contrary to the manual.

But after a reset, packet mode is spinning wheels just fine!

Alan KM6VV

You should not have to send a reset. Status 1 going off in packet mode would inidicate that serial data(good or bad, doesn't matter) is being sent to the RoboClaw. Status 2 whould indicate the motors are active. When you reset the RoboClaw do you reset the BasicAtomPro? What is your setup exactly(which module/devboard) and are you using software serial or hardware serial to talk to the RoboClaw? Are you powering the BasicAtomPro from the RoboClaw or seperately. What Mian voltage are you running?

If using software serial the initial state of the I/Os could be in a break condition which would cause the RoboClaw to constantly see incoming data.

I recommend that when you power up you immediately put the serial pins in the correct state(if using software serial). Then wait about 1 second. It takes about that long for the roboclaw to boot. Then you should be able to send commands immediately.

Worse case you can wire the Reset fromt he RoboClaw to the module to allow software control of the RoboClaw reset. Thats one of the reasons we put the reset header on the board. The other was to allow a remotely wired reset button.

The Datasheet says this: "Status LED 1 = On continuous, blink on serial receive." I guess we'll have to update that to say it goes low when receiving data. So for example, if you are polling the buffer status in a loop with no delays, Status 1 would always be off.

I have found when using serial first thing in a program, it fails to work just after programming and a reset is needed. I now add a PAUSE 500 (or more) to the program's start. This has worked for this situation just fine so far. I can only think that the processor needs time to initialize all the registers.
Take care.

Thanks! I'll try that.

Alan KM6VV

Hi Nathan,



Status 1 going off then is like a SSC-32. No problem.

I have a 5A Roboclaw (new) connected to a BasicAtomPro BB2 connected via pins 10 & 11 (software). Logic power currently supplied in common from good wall wart. I pressed the reset button on the RoboClaw to reset. Mian voltage? Logic power is 9V from a uP wall wart. I've also had them run separately, with the RoboClaw internally powered. Took me a while to realize the RoboClaw wasn't getting reset.





I can add that. Interesting that Kurt didn't encounter the problem, but I think he is probably running the 10A or 25A. I can get a 25A later for another project, and see if there are any differences. I'm assuming the code for all three is very close.



I figured that. I can do that; if I must.



It's fine however it works, just not what I read, thought I'd mention.

Thanks!

Alan KM6VV

The Status 1 LED isn't quite the same as the SSC-32s serial LED. The Status 1 LED goes low when receiving data but will go back to high once the data is received. I beleive on the SSC-32 when receiving data the LED goes low and won't go high again until more data is received. The reason the Status 1 LED remains low can only happen if it is constantly receiving data. If there is no delay between data being received the led will remain low. So if your LED is remaining low it is telling you that it is constantly receiving data from you. That data may be invalid, as in the case of using software serial not setting the intiial state of the I/O for the correct state before first using a serout command. This is becuase if the inital I/O state of the serout pin is in the MARK state the RoboClaw will be constantly seeing start bits (eg data) being sent to it.

I believe Kurt is using hardware serial like I did in my examples. Note that there is NO difference in the 3 versions other than max currnet draw. The code is identical so the problem is not anythign to do with it being a 5a versus a 10a or 25a board.

Just remember that reseting the BB2 isn't going to reset the RoboClaw (unless you wire it up to do so). The RoboClaw is an indepentent processor. If you send it commands and then reset the BB2 it will continue to execute those sent commands until they finish, new commands are sent, or it is reset too.

Hi Nathan,



I'm guessing the demo program was sending data rather fast. I'll observe Status 1 more with other code. I'll add a pause to the start of the BB2 program too.



Switching to hardware could certainly help, although I'm inclined to interface the hardware USART to a Lantronix/BlackFin Camera board. Of course, with a Blackfin around, I probably don't need a BB2, I can run the RoboClaw directly from the Blackfin.

How compatible is the new ARC32 board with the BB2/SSC-32 pair? I haven't looked at it yet.

Good to know the code is the same in all three products, as I suspected. But I wanted to rule out the possibility of a code difference.

Is there a "read status" or software reset command on the RoboClaw? I don't recall seeing one.



I haven't been resetting the BB2, just the RoboClaw, maybe I wasn't clear. but I have a few things to try now.

Thanks!

Alan KM6VV

Feature wise the ARC-32 is a good replacement for the BB2/SSC32. You get a faster processor with the same servo driving capabilities and more A/D caabilities. The only thing missing compared to the BB2 are the three buttons/Leds and speaker you get on the BB2 board. There just wasn't enough room. You get 2 controllable LEDs and a 4 I/O header with builtin pullups designed for buttons to be plugged in so it's easy to add buttons. So you end up with a BB2/SSC32 replacement minus the speaker. You can of course add a speaker using any of the I\O pins.

There isn't any software reset, but any non-buffered command will cancel previous commands(even buffered commands) for the specified motor. So to reset the machine you can send a stop motors command(eg a mixed mode command with 0 speed). The only status information is the buffer state(how many commands are in the buffer to be executed).

The ARC-32 sounds good. Does it have a separate processor for the R/C servo control, or does the main (only?) uP have to do it?

Now would be a good time to try it. I'm currently building up a "MicroMOOSE" (too big to be a Micromouse) 'bot using the BB2 and the RoboClaw. Basically a stack of 5" aluminum and FR4 disks, with a pair of GHM-16 motors w/ encoders.

I got the 'bot running on the floor yesterday. Some adjustments necessary, the two casters (differential drive) are a little tall. But I was able to run it with PS2 control, and basically Eric's code. A start. I plan is to add sensors for a "Table Top" challenge. Ultimately I'll put my Blackfin camera on top.

The same basic control and construction will be used in my Micromouse (I dropped back from that build to the earlier MicroMOOSE build because of time constraints). Although the Micromouse design tucks the two motors and wheels inside of the 5" disk profile by mounting them side-by side, and using a pair of miter gear drives. MicroMOOSE (initial effort) puts the two motors and encoders end-to-end, resulting in a 'bot that was just a little too big to fit into the then-just-announced HBRobotics club Micromouse project.



I'll check into the ARC-32 and try out an initial stop motors command.

Thanks!

Alan KM6VV

The ARC-32 runs the servos using the main processor, however the processor runs 25% faster than an AtomPro24 or 28 and the servo control uses a maximum of 1.7% of the processor time, and that is only when it's driving all 32 servos and actively moving them (eg not just holding position). So in general you will have more processing power left over than you get entirely with the BB2/SSC combo.

I usually do what you suggest at the bottom of your reply. I just send a 0 speed command to stop the motors on reset.

Is that just because of the faster clock?

I seem to recall that the SCC-32 required almost all of it's process time, at least for the first version. Different chip/speed, no doubt.

Alan KM6VV

One caveat that I have found with an Arc32 versus a Bap28/SSC-32 combination.

That is if I have a setup like my tri-track, that I wish to control the motors with a Roboclaw using packet serial at something like 38400 and and I would like to control it using an XBee using serial communications at a baud rate of something like 62500 and I enable HSERVO to handle some servos, I find that I run into problems. That is HSerial2 is dedicated to S_IN/S_OUT and I am not going to reconfigure the board before and after programming it each time (So can not use it for XBee or SSC-32). So that leaves me one hardware serial port, which I can use for the XBee. But I run into the problem that the packets I send by serout to the roboclaw get corrupted. (Note: I have not done this setup on the Arc32 yet - but I have done similar).

Now using Bap28 with SSC-32, I hook up XBee to HSERIAL (p14/P15), I use HSERIAL but I cheat by bringing out a RTS line to XBEE. So when I am needing to communicate with SSC-32 or in the case above the robo-claw, I disable the XBEE be setting the appropriate line, that way I get no hserial interrupts and the normal serouts works fine. (Or I use my own assembly language function and can output/input to SSC32 at 115200)

I have not figured out any hacks yet to get serout to work reliably above maybe 9600 baud and sometimes not even at that speed, when HSERVO is enabled. Even when there are no servos active (either not set or all set to -30000).

Suggestions?

Kurt

P.S. - Sorry for minor hijack.

Kurt,

I don't mind at all! It's all good information for my project (and probably others' as well). Perhaps I can use RTS handshake for the Lantronix as well!

Thanks!

Alan KM6VV

Hservo code uses the hardware pulse generation function of the 3687. So the only interrupt is the one to start each pulse. The interrupt triggers 300 times a second but each execution is only couple thousand instruction cycles to calculate the new servo positions and setup the pulse generators for that group of servos. The SSC uses shift registers which have to be constantly clocked to produce the necessary signals so it takes most of it's processing time.

The HSERVO system on the ARC32 uses a minimum of 00.4% of the processor when enabled because the 300 interrupts per second are still running even though most of the code is not. This is enough to mess with any high speed bit-banged asyncronous serial. So you need to use the hardware serial port to talk to asyncronous serial devices when using HSERVO unless you lower the baud rate and even then you should have checksums or parity checking to correct for any bad bits. This is a limitation of bitbanged async serial.

Kurt,

Another way to disable hserial interrupts is to use sethserial 0 or sethserial2 0. By setting to 0 the hardware serial interrupt is disabled. Then just sethserial baudrate again to re-enable hserial. Then you don't need the I/O line to the XBee RTS line.

I think I will take this to a different thread as to not hijack...

Kurt