Logobot - Firmware

[Robert Longbottom]

(Changing the subject line)

Yes, all sound like good ideas to add more features and make it more whizzy.

I think also it would be good to have some simple examples in git, without command queues, wifi, binary structures, custom stepper acceleration, etc.  So that people who aren't as familiar with Arduino / coding can work out how to do simple behaviors just driving the steppers fairly directly (using a standard library) and checking the bump switches without needing a degree in robotics.  Kind of like the Arduino examples, really basic stuff that you can refer to for how to drive forwards and backwards, etc, maybe process simple logo commands over serial one at a time.

I guess it depends what/if people are interested in getting involved in and if people want time to make a Logobot before we start getting deeply into software so they can see it in action and play around for themselves.  Nothing beats trying to make it work yourself as a way to learn something.

On the subject of queues, pre-compiled, etc, it seems to be coping fairly well as is and at least for now it is still reasonably easy to follow the code (though it did take me a long time to spot that "space" issue last night).  The Arduino IDE reports that we're only using 32% of the RAM for variables (mainly the command queue), which isn't bad.  Though we are up to 63% program space used and that's on an atmega328 as well, the "larger" of the two pro minis.

Drifting away from the "lets make some simple examples first" idea.... :-)

For the Logobot-advanced sketch (and possibly useful for some of the more simple sketches) it would be nice to start splitting it up into a few different files and creating some libraries.  I was thinking for starters we could have:

• LogobotCommandQueue
• methods: insert, push, pop, isFull, IsEmpty
• LogobotDrive - containing the basic drive and move functions (with steps per mm scaling)
• methods: drive, turn, penUp, penDown, run, stop

I suspect at some point as well (when the next Logobot is built) we will find that we might need to have something similar to Marlins Configuration.h to setup pins and allow stepper and servo reversal as people use slightly different hardware, or layout their Logobot slightly differently

On Thursday, 23 July 2015 16:31:25 UTC+1, Damian Axford wrote:

done.  In the previous commit I also updated all the distances/angles to be treated as floats to help avoid rounding errors when doing complex patterns (e.g. writing text).

As a next step, aside from testing todays commits, I'd like to change the command queue to be "pre-compiled" - i.e. commands are parsed and then the parsed arguments are added to the queue.  This will:

• Reduce the memory requirement of the queue and associated routines
• Make complex patterns more efficient to parse/execute
• Enable look-ahead path planning/acceleration
• Enable more efficient macro storage (i.e. by being packed into a more efficient binary structure)

From a fundamental architecture PoV... having each stepper motor independently controlled (and accelerated) is a limiting factor in implementing:

• ARC commands
• Look ahead path planning/acceleration

Because we need carefully synchronised motion between the wheels todo arcs.... the current arrangement only works because the turn commands spin on the spot.

To achieve that, we'll need to rework/remove the AccelStepper library, and directly control the step sequences.  Good news is that a lot of code can be re-used, and we can borrow quite a bit of acceleration planning from reprap firmwares (marlin, etc).  We'll also need some maths to calculate correct wheel motion for arcs - key parameters are wheel circumference and wheel spacing.  We've already calibrated wheel circumference, so just spacing to do.  Given these parameters will vary slightly by bot, we should probably expose these at runtime and store them in EEPROM.

Given this is rapidly growing in complexity...  is everyone managing to follow along with what we're (me/Rob) doing?  and/or should we organise a code walkthrough at some point soon?   could also delve deeper into the various techniques being used.... particularly look ahead planning, which is a little more specialist than circular buffers ;)

[Damian Axford]

simple examples = yes! agreed...  I'm just more interested in writing the whizzy stuff right now, particularly in prep for Bristol :)

memory usage - cool, that's a pleasant surprise although the program space is a bit of a concern...  i doubt all the pre-defined strings are helping, although it would seem moving them to progmem is hardly going to help!

splitting up files = yes, was thinking the same.  Proposed files sound good to me and def split out configuration as well.  It would be good if we can arrange it with some defines to selectively enable/disable the advanced stuff.  such that the core program and main loop are very simple/re-usable.

[Robert Longbottom]

Darn it, lost the hackspace cc again...

There are a few minor tweaks that could be done to the lettering, like R is just P with an extra line, but thats not going to save a great amount of space.  And it might worth trying to remove the repeated variable declarations and assignment at the start of each letter function and pass them in instead, similarly move the final PU and NEXTLETTER calls into the parent function.  I will have a play around.

"I've implemented the rest of the alphabet (may need some tweaks after testing) and the bad news is program memory is now 91% full!

I quickly tried replacing all the "PU" and "PD" with F("PU") but it actually used more memory :-(

Will have to look into other possible optimisations without doing too much obfuscation, but there is nothing screaming out at the minute that I can see"

On 24 July 2015 09:55:03 Damian Axford 

On 24 July 2015 12:39:01 Damian Axford <dam...@axford.me.uk> wrote:

Yay and smeg :( 

Just grabbing some lunch and then will take a look... Nothing clever springs to mind

On Friday, July 24, 2015, Robert Longbottom <Robe...@iname.com> wrote:

I've implemented the rest of the alphabet (may need some tweaks after testing) and the bad news is program memory is now 91% full!

I quickly tried replacing all the "PU" and "PD" with F("PU") but it actually used more memory :-(

Will have to look into other possible optimisations without doing too much obfuscation, but there is nothing screaming out at the minute that I can see

[Damian Axford]

just looked through the code...  can't see any obvious optimisations

the only way I can think to dramatically save prog mem is to move the letter definitions into EEPROM.... however, there's only 1k of it!  Fag packet suggests this isn't enough, unless we can somehow pack the letter definitions into much less space.  

as strings:

26 letters x 7 commands per letter x 10 bytes per command = 1820 bytes

storing in a binary structure like this would help a little

{

  byte opCode;

  float param1;

  float param2;

}

but still takes 9 bytes.

Pen up/down could be merged into the opCode as a bit flag.  that would save quite a bit.  A typical letter would be about 4 moveTo commands, or approx 36 bytes

26 x 36 = 936 bytes

we could also drop back from floats to ints...  that would drop a command block to 5 bytes.

26 * 20 = 520 bytes

OR could use dynamic length command blocks, as derived from the opCode, e.g.:

{ byte opCode

  byte[] operands

}

operand length is determined by opCode type/family.  So pen up/down would have no operands and take just 1 byte.  forward/back/left/right/buzz are all single operand - or 3 bytes total.  moveTo 5 bytes.

That approach is a little more complex, but is more flexible/generic and could fit nicely into a general framework for storing macros in EEPROM.

Macro header:

{

  byte charLength;

  char[] macroName

  long commandStart

}

Macro headers could be populated from start of EEPROM up.  Command blocks from end of EEPROM down. To allow for faster parsing.  Macro headers can be loaded into memory at startup for fast lookup.

Thus, we can load the EEPROM with an alphabet via a web utility, or a user can choose to overwrite the alphabet with something else entirely.

With a couple of pre-defined macros (e.g. hitLeft, hitRight, hitBoth) that gives a very simple event based framework to play with (and yes, I plan to keep banging this drum :) )

With that in mind, macros could be defined at run-time like this:

TO SQUARE

FD 10

RT 90

FD 10

RT 90

FD 10

RT 90

FD 10

END

then invoked:

SQUARE

changing macros at run-time does raise the problem of memory management/fragmentation, but I'm sure we can find a simple strategy for that.  After all, there'd be plenty of memory left to play with :)

[jmeosbn]

When I was playing around with Ardunio via make files it seemed the default behaviour was to include all the libraries *and not* optimise unused func/libs etc out during compile/link.

[jmeosbn]

I can do simple 😐

[Damian Axford]

Good shout.... found this handy list on an arduino forum:

1. Compile with full size optimization.
2. Use local variables whenever possible.
3. Use the smallest applicable data type. Use unsigned if applicable.
4. If a non-local variable is only referenced within one function, it should be declared static.
5. Collect non-local data in structures whenever natural. This increases the possibility of indirect addressing without pointer reload.
6. Use pointers with offset or declare structures to access memory mapped I/O.
7. Use for([font=Verdana];[/font][font=Verdana];[/font]) { } for eternal loops.
8. Use do { } while(expression) if applicable.
9. Use descending loop counters and pre-decrement if applicable.
10. Access I/O memory directly (i.e., do not use pointers).
11. Declare main as C_task if not called from anywhere in the program.
12. Use macros instead of functions for tasks that generates less than 2-3 lines assembly code.
13. Reduce the size of the Interrupt Vector segment (INTVEC) to what is actually needed by the application. Alternatively, concatenate all the CODE segments into one declaration and it will be done automatically.
14. Code reuse is intra-modular. Collect several functions in one module (i.e., in one file) to increase code reuse factor.
15. In some cases, full speed optimization results in lower code size than full size optimization. Compile on a module by module basis to investigate what gives the best result.
16. Optimize C_startup to not initialize unused segments (i.e., IDATA0 or IDATA1 if all variables are tiny or small).
17. If possible, avoid calling functions from inside the interrupt routine.
18. Use the smallest possible memory model.
19. If functions are only used within the current file declare them as static, this gives the compiler the option to inline them eliminating all the pushing and popping code.

Not sure how to actually do some of them with Arduino - more googling required :)

[Robert Longbottom]

I suspect it is being not as efficient as it could be and includes a load
of stuff Arduino think you might use anyway from the libraries.

I did notice it was doing some unused function removal as I was writing the
letter functions because I thought I was doing well on memory until I added
them all into the case statement so there was a chance they got called at
which time it gobbled a load of program memory.

> --
> You received this message because you are subscribed to the Google Groups
> "swindon-hackspace" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to swindon-hacksp...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[jmeosbn]

Damn, that's a long list - perhaps trim it down to the less fidley/more advantageous ones..

Wrt "12: use macros" wouldn't declaring a function as inline give the compiler the option to do this if worthwhile?

[Damian Axford]

as a quick test...  each of the write a letter functions appears to consume over 300 bytes of program memory.  that's an awful lot of space for very little code.  More testing required.

[Damian Axford]

lol - declaring all the write a letter functions as static reduces program size to 23,154 bytes - over 5k reduction!!

more to go...  

[jmeosbn]

That's good at least - the ide has started using the compiler a bit more intelligently in the last significant version upgrade. eg. It no longer does a full recompile each time (but does after a restart of ide)

[jmeosbn]

Please record the savings against that list (then we can throw out the more esoteric ones that don't help much).

[Damian Axford]

 - removing the local x,y,w variables increases code size

 - removing the nextLetter macro increases code size

[jmeosbn]

Does anyone have any spare parts to make a logobot for the Hackspace?

I could then use it to do the "simple" coding. 😀😲

[Robert Longbottom]

Nice :-)

On 24 July 2015 14:48:19 Damian Axford <dam...@axford.me.uk> wrote:

lol - declaring all the write a letter functions as static reduces program size to 23,154 bytes - over 5k reduction!!

more to go...  

--

[Damian Axford]

only the really cheap bits:

• battery box
• microswitches
• LEDs

need to order the arduino and stepper motors, then print the relevant parts

[jmeosbn]

Looking forward to looking through the commit(s) for these optimisations (keep em seperate from any other changes pls)

[jmeosbn]

Oh dear - looks like the Google group mobile web app doesn't work very well at all. My email is actually broken on EE so may give up at this point - see you on telegram! 😉

Yes, the Hackspace needs to order a load of bits if we've finalised the hardware component BOM.

[Damian Axford]

have committed the "static" keywords...  

[Damian Axford]

[Damian Axford]

and have rewritten the collision handling...  fingers crossed it actually works :)

[Robert Longbottom]

Bad news, collision code no worky :-( 

But for a really wierd reason, abort() is some kind of built in C function that apparantly aborts the program(?), so I'm not sure what that means on Arduino.  But the result was that though it goes into the collision stuff perfectly and appears to stop dead, it wasn't doing the buzz or backoff and turn actions.  So I've renamed abort() to emergencyStop() - which is a better name anyway.  Also tweaked the logic to remove code duplication and save a few more precious bytes.

And I've implemented the logo command SE - Stop Emergency!.

But, that doesn't work either :-(  Because it gets added to the end of the command queue and so by the time it gets to run the logobot is stopped anyway. (doh)

So we need to think of a cunning plan for that.  We could either have some code to prioritse ST and SE commands and put them at the front of the queue, and somehow also abort the current action.  Or I was wondering about something more generic and if you receive a logo command with an exclaimation mark at the front - eg !SE, then it would insertCmd() rather than pushCmd() whatever the command and then somehow immediately action that command rather that finishing the current action before reading the next command from the queue.

The web interface could then always send SE and ST as !SE and !ST and we could leave being able to prioritse other commands as an easter egg.

Also I have a cool video, but its taking forever to upload!

On 24/07/2015 16:01, Damian Axford wrote:

and have rewritten the collision handling...  fingers crossed it actually works :)

[Damian Axford]

damn it...  stupid built-in functions....  surely the compiler should tell me I've been a moron and tried to override a built-in.  

I like the idea of ! meaning do first, rather than queue up.  Could also extend the meaning to: abort current command and do this one right now.  It would be a simple tweak to the serial processor to check if the new cmd starts with an "!" and thereby invoke the emergencyStop + insertCmd approach.

...want video

[Damian Axford]

have committed an update that includes that form of ! handling...  seems to fit in nicely - test please? :)

[Robert Longbottom]

Looks like it should work, just need to also strip off the ! before queueing the command though.

Will test it in a bit.

On 24 July 2015 6:51:42 pm Damian Axford <dam...@axford.me.uk> wrote:

have committed an update that includes that form of ! handling...  seems to fit in nicely - test please? :)

--

[Damian Axford]

Oh yeah... Forgot that :)

[Robert Longbottom]

Yep that works nicely with the addition of .substring(1) :-)

The fact it has to do an emergency stop to clear the queue in order to process the emergency stop command is a bit crazy, but there isn't a lot that can be done about that.  Also it makes !ST a bit jerky, which is odd.  It does however mean that you can be going along in a striaght line and break out to do an immediate turn.

On 24/07/2015 18:51, Damian Axford wrote:

have committed an update that includes that form of ! handling...  seems to fit in nicely - test please? :)

[Damian Axford]

cool :)

and just found the issue with the !ST jitter...  if stop is called immediately after setCurrentPosition, then current speed isn't cleared, so it tries to deaccelerate to stop.  Have committed a simple fix.

[Damian Axford]

committed a draft implementation of arcTo()  and associated ARC command.  It's a direct port from the simulator code, so should be fairly close to working...  

[Robert Longbottom]

I'll give it a try.

In the mean time here is the video at last https://youtu.be/P9kLOJGm6V8

On 25 July 2015 01:04:38 Damian Axford <dam...@axford.me.uk> wrote:

committed a draft implementation of arcTo()  and associated ARC command.  It's a direct port from the simulator code, so should be fairly close to working...  

--

[Damian Axford]

Sweet :) impressed, especially with how well is stays on a line!

[Robert Longbottom]

Yes, it drifts up and down a bit, but somehow the errors cancel out over about 4-5 letters.  I think it's quite good that it's a little quaint :-)

The backlash code doesn't appear to work quite right.  Redoing the calibration test is okay, the dots end up pretty darn close (the difference there now is down to play in the pen lift) but it makes a mess of writing.  Lower line was from last night, upper line this morning with latest code.

Looking at the changes you made isn't it just adding the backlash correction on every time?  When what you want is to only add on the backlash correction when the motor direction has changed? (I may be reading the code wrong, I've not looked at accelstepper in any detail)

Also I cant make ARC do anything sensible.  Whatever parameters I pass it just makes a tiny (few mm) move.  What are they supposed to be?  The logo spec says ARC a r.  Where a is the angle, r is the radius.  Yours appears to be draw an ARC to some x,y coords? (Which may be more useful for drawing text, but I think we should call it something else in that case)  But even doing a reset followed by ARC 10 10 it barely moves.

I'll have more of an investigate later....

On 25 July 2015 09:19:09 Damian Axford <dam...@axford.me.uk> wrote:

> Sweet :) impressed, especially with how well is stays on a line!
>

[Damian Axford]

Hmm... It should only be adding when direction changes, assuming I got the logic right. I think the logic is in the move function... Will take a look later.

Arc is more of an arcto command. It takes x y coordinates, and tries to calculate an appropriate move. If it's only moving a short distance, I've probably screwed up a conversion factor (deg to rad, wheel diameter, etc)

[Robert Longbottom]

Oh right, okay. Backlash stuff could be general wierdness this
morning. I tried just writing an "R" on it's own after that mail and it
came out fine. Will play with it some more later on.

btw, whatever editor you are using keeps "helpfully tidying" line
endings and whitespace which makes it really hard to spot what has
actually been changed. If you could tell it not to or commit the tidies
separate from the actual change that would make it easier to follow
whats a relevant change and what isn't. eg:
https://github.com/snhack/LogoBot/commit/9bf5844c85f277ff9b5c2829a24eadb97782c275

[Damian Axford]

Might be worth setting backlash to zero in setup and just see if arc works on its own.

Atom is clearly having fun with the code :). Will see what I can do to stop the silliness...

[Damian Axford]

found a bug in arcTo() function...  fixed with latest commit.  tidied a few other bits of math.

[Damian Axford]

Rob and I discovered a fundamental issue with using two independent stepper driver objects...  they can't do synchronous moves with acceleration.  So, I've started writing a differential drive class that borrows a chunk of goodness from the AccelStepper library, but blending in synchronous moves, acceleration and look-ahead planning.  It's in a DifferentialStepper branch of Logobot and will no doubt take a few days to reach any kind of usable status.

So far, I've got some basic setup in place (pin definitions, enabling outputs, etc) and the ability to step either motor.  Next is a local command queue (ring buffer) that will allow for look-ahead planning.  Then comes the actual look-ahead bit that will compute the acceleration profiles for each line segment in the buffer.  It's not the easiest algo to explain in words, but is fairly straight-forward when accompanied by pictures.  Plus, I'll be borrowing quite a bit of it from the Marlin printer firmware :)

Once the planning bit is done, it should be fairly easy to write the run() routine to bring it all together.  

Will try and have something working by Wed...

[Robert Longbottom]

How we discovered this / the reason it would be nice to be able to do this is to draw arcs.

If you want to draw an arc to the right (for example) you need to drive the left wheel further than the right wheel, which sounds simple, just stepperLeft.move(nSteps = 1000) stepperRight.move(nSteps = 500).  However because both steppers run at the same speed, you end up driving forward for 500 steps, then turning right - doh!

So in this case, you'd really want the right stepper to run at half the speed, so that it takes just as long as the left stepper to complete it's steps.  This is possible with AccelStepper, but you have to loose acceleration support, which seems a shame.

Obviously depending on the arc it isn't just as simple as running one motor at half speed and those kind of details are left as an exercise for the reader [or Damian ;-) ]

[Damian Axford]

What Rob said... The calcs for how much to drive each wheel can be very well approximated with some simple geometry. Based on the two wheels defining the surface of a cone that rolls around the effective centet of rotation.

Will draw a pic on wed for anyone that cares...

[Robert Longbottom]

I'd be interested to know why a cone and not just two arc segments.

Unrelated code changes I made, the Esp8266 libs now include a DNS server,
though it doesn't work very well :-( but with a minor change which I've
include in our libs folder it works. So logobot is now accessible via
http://logo.bot once you have connected to its WiFi. And I found a bug
raised against the Dnsserver library so hopefully they will fix it in a
future release and we can just use that rather than having our own copy.

[Damian Axford]

this might help explain it...

This diagram illustrates working from known wheel movements (in terms of distance to move, dR and dL) to determine the final pen/robot position.  The same calculations work backwards, if you have a known final position and want to determine the wheel movements (i.e. an ARC command).

Approach:

• Use the wheel movements to "construct" two discs, sized proportionate to the wheel movements.  Imagine the discs as being cross-sections through a cone, that lies on the ground plane with the tip of the cone along the axis between the two wheels.  The tip of the cone is the effective centre of rotation for the robot motion.
• The distance to the tip of the cone can be determined by intersecting the line through the two "discs" with the ground plane.  This is a linear solution (easy equation) and can be derived from the wheel spacing and required movement distances.
• Once you have the tip of the cone, you know the radius of the arc the robot will move through and the centre point of the arc (in the robots coordinate frame).  You can calculate the angle of the arc (alpha) by dividing one of the wheel distances by the equivalent circumference of a circle at that location (2 *PI * r).
• From that point, you can calculate anything else you need -  final pen position, final wheel positions, etc

In reverse (for an arc command), may be aided by one more diagram:

• To calculate the arc centre for a target pen position: we take the line connecting the current pen position and the target pen position, bisect it and intersect the resulting line with the axis the wheels sit on.  This is the same equation used to calculate where the tip of the cone lies.
• From there we can calculate alpha (the angle for the arc) and the circumferences of the circles the two wheels must move along
• Then we can calculate the required wheel motions by multiplying the circumferences by alpha/360

This approach works for any required target position (except for where it's a straight forward/backward move, as the cone has infinite length!) and correctly produces positive and negative wheel motions.

...simples :)

[Robert Longbottom]

Good explanation and pictures, I was thinking you were driving the robot round the cone, but the cone represents the robots wheels, which makes a lot more sense. 

However I still don't really see what the cone is doing for you.  It doesn't really model the robots wheels because IRL they are both the same diameter, in the cone model they aren't.

To calculate dR and dL "all" you need (and appear to be using?) is some circle segment geometry.

Hmm, maybe the cone is more useful when you know the wheel moves and want to work out the final position, which is the opposite of what we are need to do. Yeah, that makes sense.

[Damian Axford]

yep - cone visualisation is only really useful when trying to intuitively understand what happens when you know the wheel motions.  It's strictly a double-cone, especially when you include negative wheel motions (i.e. one cone that rolls above the ground, one under it).  I ended up doing this first to get the simulator to model arbitrary wheel movements.  

either way, the maths is surprisingly easy... solve a linear line equation, an arctan and a teeny tiny bit of vector math (bisector)

...as an aside, the conic approach is the general solution for modelling the motion of a tilted wheel/disc... just project a line along the wheel axis to intersect with the ground plane, and "roll" the resulting conic around that point.  It's also the geometric basis of ackerman steering for cars, etc.

[Robert Longbottom]

How did the differential stepper driver work out?

I had a look at splitting some code out into libraries last night while sitting on the sofa feeling sorry for myself.  Nothing committed (yet).

It looks fairly simple to split out the command queue into a library with minimal changes (though some method name changes would be nice to reduce repetition since you'd be calling methods on an object already called cmdQ, so pushCmd() is repetitive).  You'd end up with code something like:

 

#include <CommandQueue.h>

CommandQueue cmdQ;

 

void someMethod() {

cmdQ.push("FD 50");

if (cmdQ.pending() > 0)

String nextCmd = cmdQ.pop();

 

....etc.

Could possibly also pass the COMMAND_QUEUE_SIZE when you create the object, i.e. CommandQueue cmdQ(20) to make a more "configurable" command queue.  There's nothing really logobot specific about the command queue which is quite nice.  So I think this would be a good move, and the changes are pretty non-invasive to the current code.

@Damian, are you happy if I do the commandQ extraction?  I dont think it should cause any merge difficulties with your stepper stuff.

I also had a go at splitting out the text writing functions (actually I looked at this first and realised that the commandQ changes would have to be done first...), Text writing takes a fair bit of ram and it would be nice to be able to easily rip them out if you don't want them, either via a #include or just by removing code.  This proved to be more tricky for a couple of reasons; it needs to be able to push stuff onto the command queue, so needs to know about that, it also needs to know about logobots current position.  Current position seems best passed in at the minute which is fairly simple, just pass in state.x and state.y, so writeChar(char c) becomes writeChar(char c, float x, float y)

Passing in the cmdQ proved more tricky.  Holding it at class level on a LogobotText class (which is fairly elegant from a code point of view) results in blowing up memory usage because you have to remove static from the writeA(), writeB() calls.  I think maybe the solution is to hold it at class level, but keep the write() calls static and pass in the commandQ to each, which is kind of messy, but at least keeps down program size which is more important.  The only function exposed by the LogobotText class would be writeChar().  I didn't quite get as far trying this last night, but will at some point.

Other things:

 - A LogoBot class would be nice.  Logobot.turn(), Logobot.drive(), etc.

 - I was looking at providing position feedback to the web page, which is working okay, but it reports either Logobots position (when stopped) or his target position (when moving) due to the way the position is updated at the start of a move.  To make this better, we'd probably need to move the position tracking support into the stepper code.... 

Rob.

[Damian Axford]

brought the wrong box last night - so ended up with no logobot to test with :(

on the flip side - I've written enough of Diff stepper class such that it should actually work (albeit with no acceleration) - feel free to try it :)

as to library splitting...

commandQueue:

• agree with what you've said, and yes, happy for you to split it out - rock on
• it would be great if you could incorporate the dynamic size bit...  should be fairly straightforward
• this has further application for macros (and repeats) - so good to make it nice and modular
• given it's a FIFO queue, not a stack, might be worth renaming push/pop to enqueue/dequeue to be consistent with general practise (i really should have done that straight away)

Text writing:

• wrapping into a class (non-instantiated?) makes sense
• it could contain a setup method that stores a pointer to the relevant command queue for later use within writeChar
• similarly, the setup method could be passed a pointer to the Logobot state structure - also for later use
• then writeChar stays pretty much as is

Logobot class:

• yes
• it would be nice if the logobot class only "talks" logo...  and encapsulates everything else
• Logobot events (bumper hit) could be assigned callbacks that can change behaviour by feeding fresh Logo commands back (pretty much how handle collisions works already)
• this means the serial block gets simplified and the command parsing moves into the Logobot class
• Logobot class should expose state info (read only), e.g. to allow for passing back state info over wifi

State info updating each step:

• hmm....  bit of a challenge - would significantly slow down the run/step loop
• could make it something that's updated at a lower freq - e.g. every 500ms - freq could be settable
• if exposed via Logobot class, it could be assigned a callback (e.g. onStateChange) fired when: position has changed ( no more than once every 500ms) or when a collision occurs.  then the "users" onStateChange handler includes a Serial.println bit to send the updates back to the webpage

[Damian Axford]

while we're talking major changes...  the diff stepper library is designed to do look-ahead acceleration planning, however, that requires feeding it multiple moves at a time.  As it stands, fresh commands are only popped/parsed once stepper moves are completed, thus it'll never get a chance to do the look-ahead bit.

Look-ahead is cool and will help it go faster (for text, etc), so I'm keen to find a sensible way to make this work - options that spring to mind:

1. Parse the command type at the time it's added to the queue, and only store the parameter bit in the cmd string - this way we can race ahead queuing up contiguous movement commands to the diff stepper.  pen up/down, etc can be treated as blocking commands, so will wait for the stepper queue to empty.
   
2. Parse the full command (type and parameters) to try and save memory - ala previous conversations - more complex, when handling "WT" commands with variable length parameters
   

thoughts?  I'm leaning towards option 1 for simplicity, although option 2 has more potential, especially if we add stuff like "REPEAT x [ ]" support - which would be cool, and allow for spirograph type stuff

[Damian Axford]

Option 2 would be easier if the WT command only accepted a single letter... The Web UI could easily generate a set of WT commands for a given bit of text, but the command queue size might have to be increased a little.

Having pondered that, it sounds like a good trade off... Thoughts?

Ps - everyone other than rob, you're welcome to join in on this discussion :)

[Robert Longbottom]

Doh.  Wrong box. :-)

Okay, will split out cmdq. Good point about enqueue, dequeue, will do that too.

TextClass, yeah I did think about just passing a pointer to the state object.  I guess I was thinking that may change at some point, plus you'd need to move the struct defn into an .h file to be able to pass it and I see that as part of Logobot.h (the logobot library) and that's not there yet.  But we could that later.

Logobot class, only speaks logo, hmm, yeah.  I wasn't thinking about taking it that far at the minute, but we could do that.  Maybe Logobot is a bad name for what I'm thinking.  I guess I was thinking more just Bot.  So you could use the Bot class to play around with driving about and reacting to bumpers while totally ignoring the "logo" thing.  I guess in that case Logobot would potentially extend Bot.  More complexity :-)

State info, yes agree it would hurt to update it every step, I saw it as more of a request.  So it updates when you ask for it, rather than recalcing all the time.  Though thats probably quite tricky to work out.  Once every 500ms would work too, any more often and the ESP will probably struggle as well.  I'm not even sure what, if any use it has, except to provide a funky display of position.  Also if we start updating that all the time we'd have to be careful about adding letters since that is part if the input to generating commands.  Let's worry about this later! 

[Robert Longbottom]

Hmm, yes.  I go for simplicity for now.

I like that WT takes a word.  It makes it usable over the Arduino Serial monitor if you're connected and dont have a WiFi module.  Having to pass one per letter is painful.  I think also the command q would get full too soon.  Given A-z would take 26 instead of just 1 that seems like a backward step (no pun intended) to me.

If the stepper lib has a queue of moves, don't we just need to speed along the cmdq until we hit a PU or PD or the stepper queue fills up and then wait until there is space in the stepper queue again, or its empty if the next command is PU/PD ?

On a similar vein I introduced the concept of an immediately actioned command for the STATus command.  I think we need to add stop and emergency stop into this category and do a bit more magic in those commands like (clear the text buffer for example or sending SE simply moves on to the next letter :-/)

Maybe we need to sit down and rework the processing of commands now we have more stuff going on....

[Damian Axford]

I like Bot and Logobot as sep classes - nice and clean...    thus, we would end up with:

• DifferentialStepper
• Implements synchronous differential drive using stepper motors (several types supported), inc. motion queuing and look ahead planning
• at some point, I'd like to break this out into separate classes for the differential/path planning bit vs the motor control to allow future support for alternate motor types (e.g. servos)
• Bot
• Implements the basic bot control stuff, including collision handling, movements, etc (no queue)
• CommandQueue
• Implements a simple FIFO queue of commands (currently strings)
• LogoBotText
• Implements the text writing extension(s)...  mainly interacting with the LogoBot command queue
• LogoBot
• Adds Logo command parsing to the basic Bot, incorporating a commandQueue and optional LogoBotText extension

Main program:

Passes stuff back/forward via serial, implements callbacks for special stuff

[Robert Longbottom]

Yeah, let's head in that direction and see what happens :-)

I also see Bot being used in some of the simpler examples maybe.  Eg:

DrawSquare.ino

Bot logobot;

void loop() {
   logobot.drive(10);
   logobot.turn(90);
  ....

--

[Damian Axford]

cool.... and yes, agreed.

guess we should move these out into the libraries directory as we go then.  I'll do that with DifferentialStepper on next commit.

[Robert Longbottom]

So, latest on the firmware.  Last night myself and Damian split out some code into some libraries, so we now have two "new" libraries in the code:

• CommandQueue - generic command queue for queuing arbitrary string commands
• LogobotText - all the text writing functions for Logobot, requires the Command Queue so it can queue up commands to write the text.

Also tested Damians new DifferentialStepper library, which seems to be working well after some debugging.  Just needs a bit more testing because it was making a mess of some letters, but I suspect that was maybe low batteries, cables getting in the way, or other randomness.  I will try and do some more testing on this tonight.

There's also still the issue of it not disabling the motor coils for one stepper while stopped, which means that it keeps chewing battery power when not doing anything, but that should be easy enough to fix.  This is still all on the branch.

I've also now converted LogobotText to use namespaces to create a "static class" like construct which has saved a reasonable amount of program memory.  Works quite nicely and means you don't need to declare all the writeA(), writeB(), etc methods as static.  The only drawback is you have to use :: to call the functions in the namespace, which isn't very "Arduino".  There must be a "trick" to work around this, but my C isn't good enough / my google-foo isn't working well enough to find this right now!  I.e. in LogoBotWifiScribbler.ino:

LogobotText::begin(cmdQ);        // should be LogobotText.begin(cmdQ);

LogobotText::writeChar('A');     // should be LogobotText.writeChar('A');

 

I've not tested this on hardware yet, but it builds, so I'm assuming it will work :-|

The savings are worth the extra colons:

Before:
Binary sketch size: 28,616 bytes (used 93% of a 30,720 byte maximum) (1.36 secs)
Minimum Memory Usage: 587 bytes (29% of a 2048 byte maximum)

After:
Binary sketch size: 24,756 bytes (used 81% of a 30,720 byte maximum) (0.92 secs)
Minimum Memory Usage: 587 bytes (29% of a 2048 byte maximum)

[Damian Axford]

good work on the namespace - that's a hefty saving indeed! 

just ordered a whole bunch of parts for new logobots (10x arduinos, 20x steppers) - half from UK distros, rest from China.  At least the UK portion should arrive in time for Bristol.

[Robert Longbottom]

Cool, I have 3 spare steppers we could use to build another one and a 5v pro mini.  Might print another set of parts anyway.

On 31 July 2015 10:28:49 Damian Axford <dam...@axford.me.uk> wrote:

good work on the namespace - that's a hefty saving indeed! 

just ordered a whole bunch of parts for new logobots (10x arduinos, 20x steppers) - half from UK distros, rest from China.  At least the UK portion should arrive in time for Bristol.

[Damian Axford]

have merged DifferentialStepper into the master branch - still standalone, subject to more testing.  I've also added a basic example for DifferentialStepper, it'll show up in the Arduino IDE under examples.  

Rob - the namespace stuff has now hidden fontsize :(  would be fun if that can be exposed, with a suitable command to alter it :)

[Robert Longbottom]

Cool, I'll try and test something later today.

Have added LogobotText::setFontSize() method and associated logo extension command "FS".

Costs what seems like a lot in memory because I've had to un-static the font size variables.  But we're still "saving" so far today :-)

On 31 July 2015 12:38:40 Damian Axford <dam...@axford.me.uk> wrote:

have merged DifferentialStepper into the master branch - still standalone, subject to more testing.  I've also added a basic example for DifferentialStepper, it'll show up in the Arduino IDE under examples.  

Rob - the namespace stuff has now hidden fontsize :(  would be fun if that can be exposed, with a suitable command to alter it :)

[Robert Longbottom]

Tonights firmware testing seems good.  Everything still working, the results from the text size changes were good, you can write at different font sizes.  It struggles with the smaller sizes, and obviously at the larger sizes any small mistakes get amplified.  Dunno what went wrong with the B at size 20, but the "error" at 60 was because the batteries died, so maybe it was an earlier sign of that.



Also quickly hacked the DifferentialStepper into the latest logobot code for a test, and it does okay.  I had to fiddle about with accelleration (750) and setMaxSpeed (2000?) to make it move at anything more than a snails pace and I suspect I should have spent more time there.  It managed to write Logobot quite nicely, but I stuggled to get it to draw a decent arc.  Either one wheel lost traction part way through the move, or it seemed that one of the steppers glitched (I suspect this may just be down to getting the right speeds).  Accelleration works, but I don't think decelleration does, it seems to come to a very abrupt stop - see https://www.youtube.com/watch?v=VmqSA7aSFlA



I also randomly noticed that having the "new" status webpage open seems to cause movement glitches.  Probably while its processing serial code.  I'm wondering if we need to move the stepper.run() into an interrupt to make sure it gets done in a timely manner.  Or otherwise optimise the main loop.

Anywho, I probably wont have much chance to do anything with it this weekend, so more logobotting next week!

Rob.

[Jamie Osborne]

Ooh.. Will have to start printing parts for the Hackspace bot..

Jamie

[Damian Axford]

good stuff :)

will take a look at the run() loop and deceleration over the weekend.  Been playing with a pre-parsed command queue thing...  doesn't amount to anything yet, but might turn out to be useful.

[Robert Longbottom]

Hey,

I've created a new branch called BotLibrary, which extracts the "bot" functionality into Bot.h and Bot.c.  The core "robot" driving and control functions.

Good things:

• The things that worked before still work :-)
  
• Saves 3% program memory. 26,612bytes -> 25,942bytes (not sure how, but hurrah!)
• It quite nicely extracts things into calls like bot.drive(50), bot.turn(90), bot.stop().
• It holds the state of the bot (x, y, ang)
• It's simplified the main loop
  
• I've managed to implment a callback for the bumpers:

bot.setBumperCallback(handleCollision)
...
static void handleCollision(byte collisionData)
{
    ....

Things of dubious goodness (we could put all of these in a separate "config.h", "math.h")

• All pin config is now in bot.h, not in the main sketch
• The STEPS_PER_MM defines and associated stuff is in bot.h
• The Math stuff (DEGTORAD) had to move too (but can still be used in the main sketch)

Not so good (?)

• Can't move driveTo(x,y) because it needs to push a command onto the queue and I don't really want the queue in the bot library
  
• I've "broken" arcTo(x, y) because it needs to address individual steppers and they are now encapsulated in bot.  Although it didn't work anyway, because it needs the DifferentialStepper lib to work properly, so maybe thats okay.
  

Thoughts?

Rob.

[Jamie Osborne]

Looks awesome :)

I agree that the pin config and similar stuff shouldn't be hiding in a library folder...

Also, was going to say that should be Bot.cpp but it's right in the repo! 😉

Jamie

--
You received this message because you are subscribed to a topic in the Google Groups "swindon-hackspace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swindon-hackspace/IRnBNd07Qp4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swindon-hacksp...@googlegroups.com.

[Robert Longbottom]

Yes.  I think the only sane way we can do that is to have a dummy LogobotConfig library that contains the pins config.

It doesn't seem to like having LogobotConfig.h in the same directory as the sketch .ino file.  The build just hangs for me in the Arudino IDE (it works on the second attempt using Visual Micro, but thats not very useful really)

You received this message because you are subscribed to the Google Groups "swindon-hackspace" group.

To unsubscribe from this group and stop receiving emails from it, send an email to swindon-hacksp...@googlegroups.com.

[Jamie Osborne]

What about passing a struct from the sketch with the config (made itself from defines) or in the bot.h do an ifdef [then use the defines from elsewhere OR supply defaults]?

Jamie

[Robert Longbottom]

Yeah, I think something like that is probably the way to go.  The only pity about that is that you need more variables to hold parameters, but hopefully it shouldn't hurt memory too much.

For now (post discussion with Damian) I've merged that branch but will update it to move the pin definitions out of the library at some point and into some kind of config.h that lives in the sketch folder.

Rob.

[Jamie Osborne]

Yea, the less elegant method of defining defaults in the Bot.h that are overridden if already defined elsewhere may be worth a shot. :)

Jamie

[Robert Longbottom]

I've merged the changes to split out a Configuration.h file that lives in the sketch folder.  It's all still working after I fixed a few minor boo boo's

[Damian Axford]

Nice one :)

[Jamie Osborne]

Cool - commit wouldn't load on my phone (terrible service) but sounds great!

Jamie

> On 4 Aug 2015, at 19:29, Damian Axford <dam...@axford.me.uk> wrote:
>
> Nice one :)

[Robert Longbottom]

I've also soldered in the extra analog pin headers and moved the penlift
servo to A4 so that the three pins for the RGB led are free again.

In the process I discovered that A6 and A7 are Analog In only. (after
trying the servo one of those!) So they could be useful for distance
sensors, or an LDR, or something similar.

[Damian Axford]

coolio.... and how strange, I thought all ATMega pins could be digital IO, guess not.  Turns out the 3.3V pro mini's are ordered have the same pinouts as yours - with the 4 extra analog pins.

[Damian Axford]

after some good progress at hackspace this evening, we've:

• sig. reduced cumulative error in Logobots internal state tracking
• fixed the batch webpage buffering, and made a good start on avoiding over-stuffing the queue by reporting back free-blocks in the queue
• fixed and integrated DifferentialStepper into bot

and since getting home, I've made a few more refinements:

• added a pause function to bot - and a matching Logo command PF (Pause For) - just pass it a number of milliseconds to pause.  This is a non-blocking pause, which allows serial, collision detection, etc to continue working whilst paused (and therefore ! commands will also execute)
• moved driveTo and arcTo into bot

[Jamie Osborne]

Sounds like a very productive night (on the software at least) - nice work both of you! 👍🏻

I'm hoping to print various parts over the next week ready for a build on Wednesday, after which I'll start getting stuck into simple examples and ... LED light pipe... Er, how many Wednesdays we have before Bristol?

Jamie

--
You received this message because you are subscribed to a topic in the Google Groups "swindon-hackspace" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/swindon-hackspace/IRnBNd07Qp4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to swindon-hacksp...@googlegroups.com.

[Robert Longbottom]

Nice much better with driveTo and arcto in the bot and not needing to push back onto the queue.

Ill have a go with it tonight and see how it works.

[Damian Axford]

lunchtime brings a major rework to command parsing...  latest commit pre-parses the command type before queuing.  

The queue now stores the parsed command type as a uint8_t, and the parameters as a string (same as before).  Have updated all associated functions and put in some minor optimisations with the main script.  Compiles ok, hopefully will work in real life :)

This was all in readiness for look-ahead acceleration planning.... Now that the command types are pre-parsed, the main loop can "peek" at the next command and decide whether to queue it to DiffStepper or not.  Will hopefully write that later today.

PS - also found my Logobot - hiding on a shelf in the lounge, in a random shopping bag!

[Damian Axford]

and now added look-ahead queueing

up-next: acceleration planning :)

[Robert Longbottom]

So, just trying a few things with the latest firmware - video : https://www.youtube.com/watch?v=aX9sHDqbrLU

Differential stepper seems to be working fairly well now.  A couple of potential minor issues. 

-  at the very end of a deceleration it decellerates really slowly.  So slowly that you can see the leds changing on the driver boards, you can see this in the video.  This looks cool, but it generates a bit of a pause after each move.  Doesn't seem to have any impact on functionality, just slows it down a bit here an there.

- steppers sometimes "glitch" and one motor stops.  I suspect this is more a hardware / timing / logobot busy thinking about other things problem.  I did four PD, FD 150, RT 180, FD 150 tests to see if the angle calibration was correct - one of them came out absolutely spot on, the other three were 5-10mm off to the side when it got back to the starting point.  Distance was spot on.

Text still seems to write okay. : might probably be okay as just PD, PU, no line, bracket needs flattening really.  # I haven't managed to test because it doesn't send over wifi.

Bumpers - wierdness, seems to do actions for left and right bumpers when only left bumper is hit.  Same for right bumper

New Pause in PU & PD works nicely.  Just long enough for the pen to hit the ground.

Arc works and draws arcs reasonably well.  It seems to loose traction occasionally on tight-ish arcs - i.e where only one wheel is driving.  A few issues - arcs go the wrong way in the coordinate system, and Arc isn't updating position state - which is handy for drawing circles :-)  Just do 4x ARC 30 30's.   But not great for then doing something else after.

I'll have more of a play later to try and fix some stuff

On 06/08/2015 13:41, Damian Axford wrote:

and now added look-ahead queueing

up-next: acceleration planning :)

[Robert Longbottom]

Have fixed
 - bumper logic - it might be worth not calling the handler when colliding == 0, but also for consumers it might be nice to know when the collision has stopped so you can act accordingly as well.

Have half fixed
 - ARC - it now arcs in the correct direction, at least sometimes, and updates state.  But doesn't get the angle right in the state if you eg ARC 30 30, ARC 60 60.  State ends up as being 60 60 180 when it should be 60 60 0.  I think Arc needs some tlc :-)  Like being able to arc back to a coodinate with y=0 would be handy for drawing circles.  Its beyond my enthusiasm to sort it out right now, but I may look at it later.

Other bits
 - CS - clear screen - resets state to x=0, y=0, ang=0.  Previously you could "cheat" and "WT" nothing, but this is nicer.

[Damian Axford]

Nice one... Will take. Proper look once kids are in bed :)

[Robert Longbottom]

Think I've fixed ARC.  It now updates angle correctly and allows you to arc to y=0 points.

[Damian Axford]

nice one!  looks surprisingly simple :)

[Robert Longbottom]

Yes, I thought it seemed too simple, but it appears to work.  It struggles for traction a bit when the circle size means one wheel is moving slowly, but apart from that it's pretty good.

On 9 August 2015 1:25:16 pm Damian Axford <dam...@axford.me.uk> wrote:

nice one!  looks surprisingly simple :)

--

[Damian Axford]

should we add an infinity symbol...?    - easy now there's CIRC :)

[Damian Axford]

and start converting letters to use arcTo - they'll look nicer, write faster and take less program space :)

[Robert Longbottom]

Could do, just implement a LogobotTextCurvy class with the same interface and make them interchangeable.  I suspect it might be more error prone that straight lines and turns, but you never know until you try!

On 9 August 2015 13:35:14 Damian Axford <dam...@axford.me.uk> wrote:

and start converting letters to use arcTo - they'll look nicer, write faster and take less program space :)

--

[Damian Axford]

Curvy class = plan. Will have a play at some point :)

What's left todo for Bristol... ?

Just make more of them?

[Robert Longbottom]

Yeah, make some of the others do random cool stuff.

Mine seems to be writing text reasonably reliably.

I was thinking about about doing a printout with the logo commandset on
it if people want to get that involved.

Maybe a flyer about the Logobot?

[Damian Axford]

Command set = yes, good plan

Flyer also good plan... Might bring a printed copy of the assembly guide and wiring diagram... Perhaps a bunch of the pieces for people to fiddle with

Bot variants - in an ideal world we will have:

1) wifi scribbler
2) basic bot with bumpers, maybe a few of these in diff colours
3) line follower
4) ultrasonic follower

Will try and get a line follower working this week, then ultrasonic can be next week - needs 5v though. Want to try doing an ultrasonic variant? I've got a spare module...

There's also the LED to integrate somehow

[Jamie Osborne]

I'm wondering if we can get away with (ab)using the partly see through shells and just mount the led against the inside of the shell?

Once I have a bot to play with I'll have a decent go at this.

Jamie

[Jamie Osborne]

Perhaps line the shell with tissue paper and make a LampBot!

Jamie

[Robert Longbottom]

Ah yes, good plan on printing out instructions and also bits to play with.

I have a spare blue basic shell and some motor mounts (that are the
wrong size), a few pins, and a bumper stabiliser.

I would like to try the ultrasonic one, I have a sensor kicking around
too! I'd like to try something like, it sits still searching, looking
left and right, if you put your hand up to it, it will turn and head for
your hand, but not get too close. If you aggressively shove your hand
towards it, then it will back off and run away. I'm not sure I'll have
time to do all that before Bristol though!

LED, yeah, was going to do something with that, just not sure quite
what. On the ultrasonic one, I was thinking the colour could indicate
what it was up to, blue = searching for someone, green, happy to have
found someone, red afraid of person and running away. Other than that,
just make it change colours and look pretty.