The source code of Argon servo drive’s STM32F205 ARM Cortex M3 microcontroller has been released under GPL v2 license! What this means to the user is that now he/she can alter servo drive behavior and functionality.
For example, one can implement a pre-programmed motion sequences that are triggered by simple digital input state change (such as push-button interface) or add support for a custom feedback device. It’s also possible to implement highly advanced adaptive control where motor gains are varied depending on external variables.
Block diagram of Argon drive. The I/O side firmware runs on the ARM CPU which connects to all I/O, feedback device and SimpleMotion ports and acts as host/controller for GraniteCore motor control core through isolated communication link.
The source code is downloadable from Granite Devices GitHub page. Users are free to share and commit their changes so eventually everyone could enjoy them out of the box.
Hi
is what it means Granite Device stop the developement of Argon firmware ?
No, it was the plan from the beginning to open source the firmware to make Argon the most flexible drive. Development will continue normally.
Why should they stop developing newer firmware revisions? They are just getting started with this beast (I hope).
The programmable ARM really makes me love this thing as I’ve been waiting for a solution like this for a long, long time. The source code seems well documented at first glance and I’m sure either the community or even GD themselves will publich some example scenarios to help people get started with this.
Thank you GD for doing so unter an OpenSource license!
Good you liked it :) There will be more documentation (to at least give code overview) and modification examples later.
Particularly interesting would be e.g. how to add a new custom command to the SimpleMotion V2 library.
I’ve got to adjust the dampening factor more or less on the fly for my application (from under-dampened to crititcal dampening) as well as running some generated custom waveforms like sine or triangle shapes for example. It will be challenging, but at least he OpenSource architecture will give me the opportunity to do so.
Indeed, that should be possible. I’ll be pleased to assist you on that when needed. However, first we should check whether this is doable without any mods as it initially sounds standard stuff.
Thank you for offering the support. I still hope that I won’t need it as from my first quick looks on the source the FW seems very well structured and excellently documented. The most important thing for me at the moment is to add new method calls to the SimpleMotion V2 API and create the possiblity to change the PID parameters via an API call – and that seems really very doable. Everything else is just a bonus at the moment. I’ll dig through the API in detail the next few days at my holiday.
When I get to altering some of the stuff I will publish it under the GPL v2 (or compatible license) as this is a non-profit open-source project I’m working on in my free time.
It is already possible to alter any parameter of drive through SMV2 while drive is operating. However, changing some variables cause drive to reset state and may cause clitch. If that happens, there you probably will need my help.
So.. I actually need some help already doing some basic stuff..
I’ve dug through the simplemotion_defs.h file but I can’t find a parameter that lets me set a desired torque value. I’ve got 13 hits related to torque in that header file, but a bunch of them are for setting the limit in other modes and the other are marked as “readout”.
How do I actually set a desired torque in torque mode?
PS: again, great job on the V2 API, seems to cover about everything, just lacks some ‘Getting Started’ documentation ;)
PPS: happy holidays, sorry to bother you :)
Sorry, I’m a donkey.. I got carried away by the naming of the parameter.. maybe “ABSOLUTE_TARGET” and “INCREMENTAL_TARGET” or something more generic than ABSOLUTE_TARGET_POS would have been less confusing.. works like a charm btw. :D
Yes, clean-up of variable naming is one of the next tasks among documentation and more example apps. Most of parameter names are adopted from VSD-E but their meaning has evolved.
Great to hear you got it working :)
Hmm.. is there any way to speed up communication? No matter what I do, I can’t get the communication via SimpleMotion to work below 16ms.. For my servo wheel project to work recieving positioning and velocity data 16ms is way too slow, considering that I have to do calculations in between and then send the new setpoint value to the Argon.
Is there any way I can get that time down? I’d need it to be at LEAST down to 4ms, preferrably 2ms or even lower as the racing simulators output telemetry data respectively direct input commands at up to 400Hz. The slowest rate we have are at about 60Hz update rate, which I can’t even achieve with SMv2 communication, which makes using the drive stage for this project pretty much useless..
I really don’t want to use a microcontroller to send setpoint signals via PWM as this complicates the whole project and renders it (almost) useless..
What’s really bugging me is that the minimal time for communication seems to be 16ms, above that (using 4 parameters or more in a queue) it seems to scale accordingly (using 4 parameters takes about 20ms, using 6 parameters about 28ms).
Any ideas?
Ha! Just remebered that the FTDI default latency is 16ms after driver installation. Might be the reason for the big delay.. I’ll try it out and report back..
Btw. does your support ticket system work?
Ticket system works, but you seem to find answer sooner than we see the question there :)
I’ll post shortly latency optimization techniques.
Haha, yeah sorry about that.. But with fundamental things it’s often better to be documented too much than too little so other people can benefit from it..
Okay.. with reducing the FTDI latency I’ve gotten it down to <=4ms. That's at least a start.
Hopefully there are some tricks to get it down even further, <=1-2ms would be awesome. :D
btw is there any sense in reducing the read/write packet size down from 4096?
I made some tips here. It may look bit mysterious before I have time to make some intro documentation of SM library :)
http://granitedevices.com/wiki/Optimizing_SimpleMotion_V2_performance
You may try reducing buffer size. I think 256 or 512 bytes could be optimum.