Re: LynxARM example walkthrough?
- I think we've figured out the answer.
The plist under project/defaults is the all important file. :-)
--- In firstname.lastname@example.org, "Kim Wheeler" <kim.wheeler@...>
> I have another question.
> How do you associate a new target with a new hardware device for eg
> derived from SerialCommPort?
> We are following the LynxArm6 as an example but can't find the
> association between the LynxArm6 and the SSC32 driver. There is a
> plist file under defaults/ however it doesn't seem to load up.
> Thanks much! - Kim
> --- In email@example.com, Ethan Tira-Thompson <ejt@> wrote:
> > > But, we know enough of how Tekkotsu works now to trace out our
> > > problem and we look forward to getting the arm to work and in the
> > > future some cool humanoids integrated into Tekkotsu. =)
> > If you don't figure it out soon, feel free to write again with more
> > details... I've had to bang my head against various serial port
> > problems in the past, and there's an upgraded version of the
> > SerialCommPort code in CVS you could try too (although mostly just
> > handles portability issues on OS X and non-standard baud rates, so
> > probably not helpful in your case)
> > -Ethan
- You beat me to it, but here's some documentation on how the process works:
- Developer specifies target model to build system (e.g. via TEKKOTSU_TARGET_MODEL or 'make tekkotsu-LYNXARM6')
- Makefiles then pass compiler flag during build (e.g. -DTGT_LYNXARM6)
- Shared/RobotInfo.h selects corresponding header file based on which TGT_XXX is set for the target and imports it into the RobotInfo namespace (e.g. Shared/LynxArm6Info.h)
- The info file specifies the target model's capabilities and configuration, including a string name for the robot (e.g. "LynxArm6", although actually these are collected in RobotInfo.cc to avoid a bunch of one-liner .cc files)
- Once executed, the runtime looks for a file "hal-XXX.plist" in the project directory, where "XXX" is the robot's name.
- If you were to type 'save' at the command line, your current settings are saved to this file, thus overriding the defaults in next step for future launches
- If user settings (previous step) not found, the runtime then loads defaults/hal-common.plist and defaults/hal-XXX.plist in succession (the latter overrides any common settings from the former)
- Once the "RUNNING" runlevel is achieved, the Main process loads ms/config/tekkotsu.xml, which contains further configuration for everything else (all the non-hardware abstraction layer stuff, which is accessible to behaviors via 'config' global (Config class)I might eventually switch the ms/config/tekkotsu.xml to be a two-level thing like is used with the HAL defaults directory, we run into a bit of trouble because tekkotsu.xml internally stores different sections for different models' settings on some items, but if someone uses the editor under "File Access" menu it overwrites everything with just the current model (which is also a nuisance during upgrades if we introduce new settings...)Also, if changing settings from the tekkotsu command line, ideally everything should refresh/update dynamically, but this is a weakly tested feature... might also try saving the settings (e.g. 'save') and restarting the executable. If you find something that doesn't update dynamically properly, file a bug report: http://bugs.tekkotsu.org-Ethan