-
Notifications
You must be signed in to change notification settings - Fork 122
Refactoring
Fixed all immediate errors, merged into develop.
- Port Dropdown properties to YAML -> old properties link to a YAML file
- Add a method that uses a program + the robot name + a general default config to generate valid programs for integration tests
- Add a debug block for output without the need for an actor
- Pull up Jaxb2Ast of individual sensors to the generic one
- Fix package names (AST), same structure on all plugins
- Find a way to use expert toolboxes as a basis for actor/sensor tests
- Have a look at Ev3 sim's
LightSensor
- Check whether
NO_PORT
is really needed
Removed all errors from the refactoring branch. Started fixing tests for EV3.
- Extracted a lot of functionality of the transformers into helper classes.
- Generalized a lot of the transformers.
- Check the constructor of
ExprParam
- Remove general modes and replace them with properties -> currently worked around with a second
getEnumCode
- Check
UsedSensor
redundancies - Add a hidden field to blockly, that specifies if the configuration block is an actor or sensor
- Check whether the
reverse
field of motors in the configuration is really needed - Have a second look at the new JaxbTransformers
- Go through all actions and replace
getPort()
withgetUserDefinedPort()
Finished refactored configuration for NXT.
- Moved NXT configuration to the robot project
- Added ConfigurationComponent as a basis for all configuration blocks
- Moved ActorType and SensorType to properties
- Moved modes to properties
- Removed some inverse transformations
- Introduced new constants interface
SC
- NXT brick block is called EV3 brick block
- Check if configuration blocks exist with blockly names -> prevent injection when changing xml
- Endgoal: blockly blocks are created from properties
- Use Map directly for ConfigurationComponents instead of constructing it from lists
- Refactor BlocklyDropdown2EnumHelper and factory's methods to more generic ones
- Check user defined names against configuration in BlocklyDropdownFactory
- Have a look at new
SC
constants, try to autogenerate - Check usage of
MASMETHOD
in the NXT tests - Check test11 in the NXTSimulationVisitorTest
Finished moving sensor and dropdown modes to properties. Started rewriting configuration, starting with NXT as basis.
- Finished common handling of wait_until sensor block with properties
- Added a new configuration
- Decide on color vs colour
- Decide whether to rename OpenRobertaRobot to RobotCommon
- Write a unit test that loads all classes for reflection
- Make all of the modes in the new properties consistent, only include the needed ones
- Extract a sensible naming strategy for the properties
Started refactoring of the IRobotFactory
, split into BlocklyDropdownFactory
and IRobotFactory
. Moving the modes into the properties.
-
MicrobitFactory
now inherits fromAbstractMbedFactory
- Renamed
set
/getProgramText
togetSourceCode
in ICompilerWorkflow - Added new classes for dropdown maps
- Split
IRobotFactory
intoBlocklyDropdownFactory
andIRobotFactory
:- Static functions moved to helper
- moved dropdown specific stuff to the new factory
- Started to move enums to the properties
- Reconsider the EV3 predefined images: remove from server side/move to hal, only include if used
- Clean up
BlocklyConstants
, try to autogenerate it - Is
getCommandline
andgetSignature
inIRobotFactory
still needed? - Generalize dropdowns for sensors & actors
- Add constants to use in code generation for the new property based modes?
- Sort the sensors/actors in the properties
- Remove redundancy in Calliope and EV3 properties
- Extract interface from
AbstractEV3Factory
- Move usages of
BlocklyDropdownFactory
up
Refactoring of the actor visitors (1, 2)
- Split sound visitor into sound and speech visitors
- Split motor visitor into motor and differential motor visitors. Differential motor visitor extends the motor visitor
- Default implementations for not supported actors are in the robot specific interface
- Renamed communication visitor to bluetooth visitor
- Removed control visitor, moved relay action down to Arduino
- Added
IActors4AutonomousDriveRobots
as super interface for generic wheeled robots - Removed many empty return nulls or defaults and pulled them up to the robot specific interfaces to throw exceptions
- Revised common Arduino visitor
-
Discuss if a sensor hierarchy is possibleat this point of time we can not find any beneficial structure - Revise LEDs for Arduino
- Look at Mbed in general and improve it (Structure,
Motor
,SingleMotor
,BothMotor
, missing microbit methods) - Write a script that validates test xmls are actually used in tests
- Look at package names (actors vs action)
- Improve Arduino properties
Refactoring of the factory names, code generation visitors and used hardware visitors.
- Added
Abstract
to all touched abstract classes - Added
I
to all touched interfaces - Factories & compiler workflows now include the robot name in the class name
- Factories are in the
de.fhg.iais.roberta.factory
package - Compiler workflows are in the
de.fhg.iais.roberta.codegen
package - Same factory & compiler workflow package names and structure for all robot plugins
- Code generation & used hardware visitors now include the robot name in the class name
- All visitors can be found under the
visitor
package - Language specific visitors are in the
lang
package - Hardware specific visitors are in the
hardware
package - Used hardware collector visitors are in the
collect
package (not final structure, has to be refactored?) - Program checking visitors are in the
validate
package (not final structure, has to be refactored?) - Same code generation package names and structure for all robot plugins
- Timer & Bluetooth functions were moved down the simulation visitor chain (this has to be refactored)
- Have a look at the Guice modules (e.g.
Ev3GuiceModule
) and its package structure - Bob3, Botnroll & Mbot factories should be subclasses of
AbstractArduinoFactory
-
MicrobitFactory
should be subclass ofAbstractMbedFactory
- Refactor hardware specific parts in the simulation visitors, maybe split into lang / hardware as real robot ones
- All exception messages in
IActorVisitor
should be replaced - Should the
AbstractStackMachineVisitor
be moved to the robot project? - Final should be added to all leaf visitors to express they are leaves
- Add a general
IRobotVisitor
between robot specific ones andIActorVisitor
andISensorVisitor
? - Look at all of the visitors and replace
return null
with exception throws where adequate - All high level visitors need default implementations
- Look at
isXUsed
andUsedSensors
/UsedActors
structure and find a better (common, if possible) solution - Synchronise test packages with the new package structure
- Split checkers into similar
lang
/hardware
package structure, if possible - Look at "Brick vs Board", replace everywhere with more descriptive names
Home | Community | Installation | Team
Installation Tutorials
- Instructions to run a openroberta lab server using DOCKER
- Instructions to run the Open Roberta Lab Server natively on ubuntu ‐ not recommended
- Raspberry Pi 2/3/4 and the Open Roberta Lab
- EV3 and leJOS
- EV3 and ev3dev
- Creating the OR leJOS image
- Arduino Create Agent
- Mbed DAL: Generation and automation
Development
-
Workflows
-
Architecture
-
Blockly
-
Software engineering issues
-
Misc
-
Notes on robots
Textual Representation
Contribution
Discussions on future development