SoR annoucement: microcontroller product

[Anoroc]

sweetness! I want one

[HDL_CinC_Dragon]

oh good, I just put a super charger and noss injector into my drewl engine a little bit ago. I knew there was a reason!

*DROOOOOOOOOOOL!*

[Admin]

hmmm apparently I can't spell the word 'drool' . . . so in my defence, I claim its a real word:
http://www.urbandictionary.com/define.php?term=drewl

[AndrewM]

hmmm apparently I can't spell the word 'drool' . . . so in my defence, I claim its a real word:
http://www.urbandictionary.com/define.php?term=drewl

In a year or two when you release the Axon II you can rename it "Drewl" and just say you were foreshadowing...

[bietz]

just one (maybe stupid) question: how is the Axon powered when it's not connected through usb? I didn't see any power header or something in the pictures...

[Admin]

Got some sort of bad news . . . it was a hard decision, but I've decided I wasn't fully happy with the design. I'm going to do another prototype, so this will push it back another two weeks or so.

Still working on documentation . . .

bietz, you can plug your battery into any of the non-regulated headers. I'm including an external on/off switch that you can connect anywhere on your robot chassis, then wire it to the Axon in seconds.

[bietz]

and about the propeller, I would have loved to have its multitasking capabilities on this board, although it could have caused some problems in openness (you must program in spin, not C, and the forthcoming C compiler will not be free, but spin is still pretty good).

What it allows you to do is to assign a 'cog' (processor, of which there are 8!) to each task. For instance, one cog would do all the low-level servo work (sending the right pulses), another one would get all the sensor inputs etc. and the main cog would orchestrate all the other cogs, without caring about the low-level stuff, nor being slowed down by it. In fact, the main cog can just change some RAM variables (for instance motor speeds), and the other cogs can immediately access the new values in the RAM, without any semaphore problems. So I think the propeller is an excellent chip for any robotics applications.

Maybe one day there'll be a prop-Axon?

Anyway, the actual one is still amazing!!

[Admin]

bietz, I've been seriously thinking about that . . .

Perhaps on the Axon II next year

As for the propeller, my complaint is that it is weak in I/O and UART, which is why I developed the Axon. But I do like the parallel processing concept, and I think its the right direction for robotics to go . . .

[bietz]

As for the propeller, my complaint is that it is weak in I/O and UART

I agree with that, especially the UART and serial communication, which takes one cog and isn't that much integrated. And since it's still in development, I do think one should wait some more time to use it at this scale.
Why not an Axon II next year 

[JesseWelling]

I don't think most people use all the processing power they have now.

It's not like you can't use a OS that does task managing on an AVR, PIC, or ARM as it is. I just don't get what exactly you would use the extra cores for as opposed to dedicated UART/I2C/PWM/A2D/Counter/Timer hardware on the an AVR or PIC which essentially makes it all parallel in the first place, with a very tiny amount of overhead for interrupt handlers. I mean that's why all that dedicated hardware is on there. Your processor can do other things while the dedicated hardware is pumping out bits, or waiting to capture an input condition. Then, Boom, your interrupt fires, does some minimal processing, and if need be resumes some task that was blocked waiting on that piece of hardware.

[bietz]

If you take the example of an extra cog for servos and one for, say, an ultrasonic sensor, here's what it allow you to do:
with a normal microcontroller, a normal robotics program would look like this:
* call a function that allows you to read the input value of the ultrasonic sensor (for instance, with a Ping you would send a pulse, then receive one, and maybe convert the input to an actual distance) and store that value
* do your calculations (the behavior of the robot, i.e. the most important part) using the inputs, and get the output values for the actuators (in this example, the servos)
* call a function that converts your output value to a raw value that can be sent to your servos, then send the appropriate commands to each servo (send one pulse per servo)
* goto start

The problem with this is that the first and the third steps are low-level things that only slow down the main part, which is the orchestration (the thinking). Moreover, when the behavior part is very long, it will diminish the rate of input readings, and especially the rate of pulses sent to the servos, which causes them to lag a bit.

Now what the propeller allows you to do is have a processor care for each of these two steps, so that they don't have to bother the actual brain part of the program, and themselves are not bothered by it. These processors would do just that, thereby doing it more rapidly and more efficiently. In fact, the servos cog would behave kind of like a complete servo controller, reading in ram the speeds or positions of each servo (expressed in a more user-friendly way, such as -100 to 100), converting them to raw values (pulse lengths) and sending the right pulses. All this in a loop by its own.
With this in mind, the main cog (the brain cog) only has to change the values of some variables (for outputs), or read some variables in the RAM (for inputs) and doesn't need any extra-processing at all. Even better, you don't have to care about mutual exclusivity because the propeller has a so-called 'hub' that makes sure each cog accesses the clock, the RAM and I/O one at a time, which means that there's no risk to have 2 processors access the same data simultaneously.

So that's the power of the propeller for robotics applications.

Now I know that many microcontrollers have dedicated hardware to handle some of that stuff (interrupts, counters and all that), but have an entire processor care about it is much more powerful. And one could also use an extra processor just for a specific algorithm, such as a PID controller or some recognition algorithms.

That's why there are so many people saying that multitasking will be at the heart of programming in the future 

But anyway, I agree that the processing power we have today can already allow to achieve pretty good stuff, especially for the kind of 'hobby' projects we do.

[JesseWelling]

In a RTOS this is what you would do:

Put the Ping sampling in one task. In it's own task loop it would send a pulse and start a timer and then block its self. The input from the ping would be tied to an interrupt that would that when brought high unblocks the Task. After the task is unblocked stop the timer and convert/store the value as the most current value. Here is a rough draft of the code:

Code: [Select]

static UInt16_T Distance_CM=0;
static Mutex Distance_Access_Mutex;

void PingTask(void)
{
   UInt32_T timer_value_nanoseconds=0; //or microseconds or whatever

   for(;;)
   {
      ResetTimer();
      SendPulse();
      StartTimer();
      BlockTask(); //In FreeRTOS you can put an upper limit on the amount of time to block
     
      //Processor runs other tasks while waiting
         
      timer_value_nanoseconds = StopAndReadTimer();
      timer_value_nanoseconds = ConvertTimeToDistance(timer_value_nanoseconds); //no sense it wasting space
      LockMutex(&Distance_Access_Mutex);
      Distance_CM = timer_value_nanoseconds; // might want to saturate timer_value_nanoseconds and avoid overflow.
      UnlockMutex(&Distance_Access_Mutex);
   }
}

UInt16_T getPingDistanceCM(void)
{
   UInt16_T return_value=0;
   LockMutex(&Distance_Access_Mutex);
   return_value = Distance_CM;
   UnlockMutex(&Distance_Access_Mutex);

   return return_value;
}

//Set up your interrupt function... not exactly syntactically correct but I'm lazy at the moment
_Interrupt (Whichever_PIN)
{
    Unblock(&PingTaskHandle);
}

Your main behavior goes in another task at a lower priority than your PingTask and is another for( ; ; ) loop that does it's own thing. Like you said you won't need another task to out put to a servo, you just need to set up the hardware and then all you have to do is make a function call that calculates from engineering units to raw units and writes that value to a register to change the PWM.

In this way you can see the very minimal processing that is needed when you properly use your hardware.

In addition, if the propeller has only limited access at any given time, you are essentially making a syncronized RTOS in hardware in which all tasks always get the same amount of time in a round robin fashion, which may not always be optimal. And because of this round robin fashion you will have reduced throughput in all tasks. So you are all ready hampered by the architecture.

I'll agree that it is a step forward in hardware ideas, but I think the implementation is lacking compared to modern software.

[JesseWelling]

Sorry for the OT post.... 

[Admin]

Like you said you won't need another task to out put to a servo, you just need to set up the hardware and then all you have to do is make a function call that calculates from engineering units to raw units and writes that value to a register to change the PWM.

This won't work if the number of servos exceeds the number of hardware PWM on the mcu. For bipeds or my ERP or my robot fish, a huge amount of cycles get wasted on servo PWM. Since the Axon can in theory do up to ~41 servos, this is a serious problem.

In the future I plan to write much better servo software that doesn't require wasting ~1.5ms per servo (like on the $50 robot). I have ideas, but not the time to try them out. It will probably involve timers and interrupts . . .

[JesseWelling]

I guess my head is stuck on getting a person like driving capability so I only ever need 2 for ackerman and no more than 4 for tanks

I guess the solution may be... Specialized Hardware... 

[AndrewM]

Or just throwing a second (or third) microcontroller onto the board that only handles the servos based on a simple command from the main mcu.

[bietz]

Or just throwing a second (or third) microcontroller onto the board that only handles the servos based on a simple command from the main mcu.

That is basically what the propeller does by assigning a cog to the task: it's like an MCU by its own, and best of all, you don't need to send any data between the two (no time sent with serial communication or whatever) because they both have access to the same RAM. The only problem would be that they access the hub one at a time, so they don't go at full speed, but that's ok since the propeller runs at 80MHz...

Anyways, since I don't know that much about timers and interrupts, and RTOS, I'll give it a look.

And I guess we're getting too much OT... 

[paulstreats]

In the future I plan to write much better servo software that doesn't require wasting ~1.5ms per servo (like on the $50 robot). I have ideas, but not the time to try them out. It will probably involve timers and interrupts .

Ive just done this in an interrupt base along with pwm for my motors, its set for a PIC but im sure you could easily modify the code.

the important part is the number 40 in the below line.

if (rangefinder.offduty>=40){

if its set too low, the servo will try moving too fast and spaz out, if its set too high, the servo turns off and it isnt very efficient. This value needs changeing depending on whats in the interrupt sequence along with it. The more processes in the interrupt, the lower this number needs to be.

The function that the interrupt runs from motor.c allows full speed control using modified pwm (i found that plain pwm produces a jittery motion). I decided not to use the pwm ports on the pic because they are all in silly places (like 1 on each port)

[Admin]

An update on the Axon . . .

I got the newest prototype PCB in the mail yesterday, and I just hand soldered it all today. I ran it through my tests, and it passed all of them.

I will now use it on my ERP for a week or so, and if no other problems show up, I will finally make the order for a large scale manufacturing run. I think we have a winner

Good chance it could be in your mail box by end of this month, but don't quote me on that . . .

Also, I decided I won't be shipping international directly, ever. Too much effort and shipping costs. But before you freak out, I already have an international distributor that I'm in the talks with. Those who are international will probably have to wait another ~month or so as I work out the details. Hopefully they can offer lower international shipping costs . . .

Anyway, I am setting up extra bonus features on the Axon. I will have a .hex file, that if you upload it, turns the Axon into a servo controller (up to ~40 servos) that can be used directly with a PC or anything else that has serial or USB.

I am also writing code that turns the Axon (also a .hex) directly into a highspeed data logger.

Don't remember if I mentioned this before or not, but the Blackfin camera interface code is done as well.

And I'm up for more ideas if anyone has any.

The documentation and tutorials are almost done. I'll release them in about two weeks.

[bietz]

Also, I decided I won't be shipping international directly, ever. Too much effort and shipping costs. But before you freak out, I already have an international distributor that I'm in the talks with. Those who are international will probably have to wait another ~month or so as I work out the details. Hopefully they can offer lower international shipping costs . . .

Yeah international shipping is really horrible... That's what blocks me from buying robotics/electronics in the US most often (which means at all, since there's almost no places here in France to find that stuff unless it's 3 times more expensive...).

I just ordered some stuff from digikey (AVR programmer and lots of other little stuff) and I had to spend $70 of UPS shipping, and an additional 50 euros ($77) of taxes here...
A while ago, I ordered some stuff from parallax for my robotics club, and I had the choice between $170 with UPS or about $50 with USPS, so of course I chose USPS, but since it's public, boom, 85 euros (130 dollars) of taxes here, for a total of $180 of shipping... It hurts... Fortunately, that time, the school was paying but still...

The thing is I can never buy a small amount of stuff because I prefer waiting to have more things so that I don't end up wasting $150 a time for shipping...

ok, the dollar is low and stuff, but still... it just bugs me. I wish I lived in the US even just for that...

Anyway, I am setting up extra bonus features on the Axon. I will have a .hex file, that if you upload it, turns the Axon into a servo controller (up to ~40 servos) that can be used directly with a PC or anything else that has serial or USB.

I am also writing code that turns the Axon (also a .hex) directly into a highspeed data logger.

Don't remember if I mentioned this before or not, but the Blackfin camera interface code is done as well.

And I'm up for more ideas if anyone has any.

The documentation and tutorials are almost done. I'll release them in about two weeks.

That is awesome!!! This is what will make it great!

Alberto

[scrvtch]

Sounds great. How much has changed since the last version? (A picture would be awesome)

For the servo control, will their be functions for modifying the timing and speed of a servo as well as just position?

I'm looking forward to taking a look at the documentation and tutorials!

[JesseWelling]

Modifying the timing or speed of a servo is pretty hard thing to do with out access to what the control loop of the servo is doing. The reason for this is that the servo has a pre-tuned gain (assuming just a P gain, some servos may have D gains) based on the response of the system. So it's designed to take you from angle X to angle Y as fast as possible with as little over shoot as possible. To change the speed at which it does that you would have to fiddle with those gains but as you can probably figure out there is no access to them. So you are kinda stuck trying to dither with an update of 50hz.

In other words, changing the speed of a servo is like like trying to get a race horse to trot.

But maybe I'm misunderstanding what you are after...

[Admin]

How much has changed since the last version? (A picture would be awesome)

Not much changed. Added a resistor and two diodes to fix some minor issues.

For the servo control, will their be functions for modifying the timing and speed of a servo as well as just position?

Initially, no, because its a bit complex - especially with 40 servos to keep track of. But yea its possible. The controller would need to slowly ramp up the PWM signal to get the servo to slowly change to a new position.

[Webbot]

Admin:
In the future I plan to write much better servo software that doesn't require wasting ~1.5ms per servo (like on the $50 robot). I have ideas, but not the time to try them out. It will probably involve timers and interrupts . . .

Here's a good starting point
http://www.societyofrobots.com/robotforum/index.php?topic=541.0

[GHF]

Admin:
In the future I plan to write much better servo software that doesn't require wasting ~1.5ms per servo (like on the $50 robot). I have ideas, but not the time to try them out. It will probably involve timers and interrupts . . .

Here's a good starting point
http://www.societyofrobots.com/robotforum/index.php?topic=541.0

I think Admin means that he doesn't want to have to "set pin X high - wait 1500uS - set pin X low" because that means a lot of time is wasted doing exactly nothing, and very little is accomplished. The better (but more complex) way is "set pin X high - set timer to cycles equal to 1500uS - turn on timer and timer interrupt - do useful things for 1500uS while timer counts - interrupt occurs when timer overflows - interrupt sets pin X low."

There are other schemes that use timers and a tight loop to do the "set pin X high" part for ALL the servos. After that, you turn on a timer, run in a tight loop, waiting for each servo's desired delay to come, and then set low the corresponding pin. This is the simultaneous way, vs. the back-to-back way.

-Xo W.

[JesseWelling]

AVRlib does the back to back way, but if you are only using one output compare you are limited to 25 (50ms/2ms) servos. But you could use up to 3 output compares on one timer. The only problem with that is you may have some jitter if it just so happens that 3 output compares cause over-lapping interrupts. But it really shouldn't be that bad...

[Webbot]

GHF - I don't think you checked out the link. which does EXACTLY what you are talking about - ie if you want to send a 1.5ms pulse to a servo then set the servo pin high and then schedule to be called back in 1.5ms time to change the pin low again. In the meantime get on with doing other stuff. There is NO blocking/delay of the main foreground task. Since the link provides the code to schedule callbacks for lots of tasks then this could be used to control lots of servos - subject to the granularity of the timer, number of servos etc.

[Admin]

I know you guys don't want to hear this . . . but I've decided to do yet another prototype. I had a talk with the experts over at Dimension Engineering and they found a bunch of ways I can reduce costs during manufacture. Tons of other advice, too.

Also, I want peoples thoughts on this. Instead of the ATmega2560, Im going to change it to the ATmega640 ($4 cheaper). Its exactly the same for everything with one exception - instead of 250kb flash memory, it only has 64k. I seriously doubt anyone will use more than ~6k memory, so its just a waste.

If someone still wants 250k, I can do a custom board for you . . . If anyone sees a problem with this, or needed that memory, speak now!!!

The changes make each Axon ~$7 cheaper, so if I make 1000 of them, thats a lot of money saved!

So how does this affect shipping date? Pushed back an extra 3 weeks probably . . . sorry!!!

[AndrewM]

Not that it should sway your decision on changing the processor, but I had planned for that extra flash memory for lookup tables for learning algorythms.  I can always just use an I2C or SPI memory board instead.  Of course 8bit might not be enough for the size of the tables when all is said and done anyway.

[airman00]

I would leave the 250 k if you want the axon to be known as teh "ultimate  board"

but 64k is fine , I dont mine at all