RoboBuilder BASIC first experience

[Joe]

Appropriate for Halloween, I'm resurrecting my RoboBuilder which has been lying in its coffin for the last year. Since my own custom firmware had some issues, and the interactivity of l3v3rz's BASIC looks cool, I thought I'd try that.

First impression: works as advertised, and is quite cool.

I have hit one important stumbling block, however. I need to configure a couple of new servos, and I'm not on Windows. I had hoped I could use BASIC to send the necessary configuration commands, but I don't see a way to do that.

I was hoping for something to just send an arbitrary 3-byte command packet (letting BASIC compute the checksum) direct to the servo bus, and get the 2-byte response back. But if it's there, I'm missing it. Any tips before I either start digging into the code, or start writing my own servo config utility?

And here's a question... how would even the standard "wCK Programmer" utility work without the standard firmware? Doesn't the firmware need to act as a relay between the desktop PC, and the servo bus?

Thanks,
- Joe

[Joe]

One more question: I recall when we were working on our custom firmware together, we included some carefully-written code to charge the battery.

I expected to find this code in the BASIC firmware, perhaps as a top-level option (before entering interactive mode). But it doesn't appear to be there. Do you switch back to some other firmware to charge your bot? Or is there now a reasonable way to charge it up without firmware support?

Thanks,
- Joe

[l3v3rz]

Configuration of new servos is not something BASIC provides, you would need to load the standard firmware (or DCMP) which provides a proxy capability for bytes presented on serial bus to the wck bus and visa versa.

Given the ease or loading the firmware and the fact that its not a frequent required feature its not been added. I have been looking at adding a capability to PRINT to wck bus but this is a new and not in the current built hex file (336). Its in the source code if you build yourself but not really tried. it. e.g PRINT #"FFA0012"

The good news on the battery charger is that code s there (main.c) - two ways to invoke - either by holding down PF1 on the RBC on power up or pressing 'X' at command menu.

cheers

[Joe]

Great news about the battery charger; I respectfully suggest adding that to the PDF (perhaps in the "Getting Started" section on page 4).

I can understand why a specific utility to configure servos isn't included, as you're right, that's quite rare. Something to speak directly to the wCK bus might be handy though. (Though now that I'm digging into it again, I see that it's a little hard to do reliably, unless you know how many bytes response to expect.)

I'm currently uploading the homebrewOS, with a freshly restored "w" command in serial-slave mode (sends a command to the wCK bus), which should work with my desktop utility to configure my servos today.

But I hadn't really looked at DCMP... that looks pretty handy. I like the simplicity of it. I'll have to dig into that more later; thanks for pointing it out!

[l3v3rz]

yes the manual needs quite an update! I think its based on build 208, where as current build is 361 !

Extra menu commands:
X - charge mode
$ - demo mode (press a key and get a built in motion)
s - stand (or S if you have hip kit)
o - turn sound meter on (lights on back respond to sound

New commands include
DATA, SET, INSERT, DELETE, SELECT, GEN, NETWORK, SORT

Plus of course lots of bug fixes and Ive been porting to Linux - o it can run on my host pC and then talks remotely to DCMP.

[l3v3rz]

BTW - I've dropped all development on the homebrew OS along time ago. I did some performance test of the protocol vs standard firmware in DC mode and found that round-trip times were 50+ms for Homebrew OS vs <5 ms for DC mode. Looking into it I realised that because DC mode proxies each byte as it arrives the servo respond as soon as last byte is sent, where as the binaries protocols in the homebrew create a packet which has to be decoded sent to wck wait for response and encode before the reply is sent. This drove me to build DCMP which has the same speed as DC mode Plus the ability to access PSD, accelerometer etc..This is then fast enough to write some interesting programs.

[Joe]

Neat! I'd offer to help update the manual, but you're probably writing it in some Windows word processor I don't have.

Incidentally, our old homebrewos software locks up somewhere when you unplug the first 16 servos! So I ended up using DMCP (with a little custom client) to reset my servo IDs. That worked like a champ.

I'm a little surprised that DMCP is fast enough for real-time bot control, but maybe I shouldn't be. I'll have to give that some more consideration.

Cheers,
- Joe

[Joe]

BTW - I've dropped all development on the homebrew OS along time ago. I did some performance test of the protocol vs standard firmware in DC mode and found that round-trip times were 50+ms for Homebrew OS vs <5 ms for DC mode.

Well, yes, but then you're doing all the heavy lifting on a host computer. I'm trying to get away from lugging a laptop around to the competition ring. My intent was always that the firmware would have all the motions built in, along with code to mix them, manage state, eventually add dynamic balancing, etc. The host would only be sending simple control inputs, so speed wouldn't be an issue.

[Joe]

More impressions, now that my servos are configured and I'm trying to actually use the BASIC interpreter... I ran into a few glitches:

1. I had entered a 4-line program, starting with "10 LET S=16". Ran that, worked fine. Now I went back to interactive mode and entered "10 LET S=17". The system locked up, and I had to cycle the power.

2. After I was up and running again, I listed my program, and the old one was still there. I entered "10 LET S=17", and it took it OK this time. I entered "." to exit interactive mode, and it said "1 lines entered". But then both "r" and "l" reported "No program loaded." Doh.

3. So I went back to interactive mode, and re-entered the whole program. Exiting told me "4 lines entered, [125/3072] bytes". Yet "l" and "r" still insisted "No program loaded".

At this point, I seem unable to enter any code, though I can run it interactively. Not sure how to get back to a working state... cycling the power is a little painful, because it breaks my bluetooth connection, which seems fiddly to re-establish. But I'll give it a try.

[Joe]

OK, after doing a "C"lear, I was able to enter a program again. But I ran into another glitch:

I had a program consisting of lines 10, 15, and 20. I needed to add control over another servo, so I added lines 15 and 21. But when I tried to run, one step was missing — so I listed it, and line 20 has disappeared. Here's the session:

Code: Select all

: l
List Program
10 SERVO 13=94
15 WAIT 1000
20 SERVO 13=199
: i
Enter Program '.' to Finish
> 11 SERVO 15=141
> 21 SERVO 15=204
>

2 lines entered, [68/3072] Bytes
: r
Run Program
Elapsed Time 1003ms
: l
List Program
10 SERVO 13=94
11 SERVO 15=141
15 WAIT 1000
21 SERVO 15=204
:


But I'm probably making a pest of myself by this point. I don't mean to complain; I think it's amazing what you've done here, and it's really useful. Just wanted to draw attention to a few glitches I ran into in the course of trying it out. And yes, I know I could go dig in the source if they were really bugging me.

[l3v3rz]

Yes - That's bugs fixed in build 352 - just tried it on my current version and it works fine.
If its a problem use the version in the source tree - its build 361 - so it should work fine.

Code: Select all

 l
List Program
10 SERVO 13=94
15 WAIT 1000
20 SERVO 13=199
: i
Enter Program '.' to Finish
> 11 SERVO 15=141
Insert line
> 21 SERVO 15=204
>

2 lines entered, [63/3072] Bytes
: l
List Program
10 SERVO 13=94
11 SERVO 15=141
15 WAIT 1000
20 SERVO 13=199
21 SERVO 15=204

[Joe]

Cool, I have the source already so it should be easy to update. I'll try it out tonight or tomorrow.

On a more positive note, the OFFSET command is brilliant. The built-in motions were splaying the legs too much (due to the angle introduced by the hip servos), but a

Code: Select all

OFFSET @{18,35,0,0,0,0,-35,0,0,0,0,0,0,0,0,0,0,0,0}

fixes it right up. (But why doesn't the STAND command apply offset too?)

[l3v3rz]

The idea being that STAND already caters for both 16 and 18 servo variants but the built in motions don't. I think the problem here is my default 18 servo stand is different from yours (I've probably assembled mine incorrectly - hip kit instructions weren't that clear). You can fix by modding basic18 variable in wckMotion.c. and rebuilding.

So why not have offset alter STAND ? Well my thinking was if a program goes wrong and set offset incorrectly you still want to be able to stand. You don't really need Stand as you can just use the move command (its still only 1 line) - but that is affected by offset.

[l3v3rz]

Latest version of firmware (v366) now uploaded

Adds ability to have offsets applied stand command Also a lot of new stuff since v336.
Note this won't work with the old BasicClient.exe

[l3v3rz]

You've probably moved on to other things, customer design etc. But there a new version 408 of Basic Firmware . I think this fixes some of the problems you were having. And I've added AND / OR and MOD!

There's also an update to the manual that covers lots of features - again see the the project site