The 3.3.1 release of the Driver Suite is hopefully the last of the 3.x series. I’ve now started working on implementing a new architecture for Driver Suite 4.x. Some things will change, some remain the same:
- Sensor related data is now kept in structs, so buffers will no longer be shared by similar sensors.
- Local variables will be removed or a least kept to a minimum.
- Lots of use of function overloading, I’d like to get rid of the 3-5 letter prefix to all the function names, as much as that is possible.
- The sensor initialisation function will automatically set the sensor type correctly if it’s not optimal. This is one of the most frequently occurring problems that I get mailed about. I may make it possible to override it, as in, disable the check but it will be on by default. The initialisation function will also do whatever sensor configuration is necessary to make it work with reasonable default values. You can reconfigure the sensor with other values, if applicable, through other functions.
- Complete overhaul of the API, make everything more consistent.
- Migration from SVN to GIT, a public GIT branch will be made available in time. [partially done]
- The new Driver Suite will be called ROBOTC Driver Suite and is hosted on the same repository servers as ROBOTC’s own source code to make co-releases easier. [done]
- Restructuring of the directories in the Driver Suite [done]
This restructuring has the added effect of making the examples NOT work out of the box until the include file path has been configured correctly in ROBOTC. This will force people to set it up properly. - I’m going to work see if I can make working with the Mindsensors SensorMUX as transparent as with the HiTechnic one.
- The Driver Suite will continue to be made available via zip files on the official SourceForge page.
- If you have suggestions or comment, let me know by email, not by leaving a comment, that way I can archive them and keep them all in one place.
I’ve already got a working example and driver that seem to work quite nicely for the Dexter Industries Thermal Infrared Sensor. Please note that the function names have not been finalised yet, this is a proof of concept.
This is not an April Fool’s joke, by the way!
#pragma config(Sensor, S1, TIR, sensorI2CCustomFastSkipStates) //*!!Code automatically generated by 'ROBOTC' configuration wizard !!*// /** * dexterind-thermalir.h provides an API for the Dexter Industries Thermal Infrared Sensor. * This program demonstrates how to use that API. * * Changelog: * - 0.1: Initial release * * Credits: * - Big thanks to Dexter Industries for providing me with the hardware necessary to write and * test this. * * License: You may use this code as you wish, provided you give credit where it's due. * * THIS CODE WILL ONLY WORK WITH ROBOTC VERSION 3.60 AND HIGHER. * Xander Soldaat (xander_at_botbench.com) * 30 march 2013 * version 0.1 */ #include "dexterind-thermalir.h" task main () { // declare and initialise the sensor tTIR tir; initSensor(&tir, S1); nxtDisplayCenteredTextLine(0, "Dexter Industries"); nxtDisplayCenteredTextLine(1, "Thermal Infrared"); nxtDisplayCenteredTextLine(3, "Test 1"); nxtDisplayCenteredTextLine(5, "Connect sensor"); nxtDisplayCenteredTextLine(6, "to S1"); wait1Msec(2000); eraseDisplay(); // set emissivity for light skin setEmissivity(&tir, TIR_EM_SKIN_LIGHT); wait1Msec(200); nxtDisplayCenteredTextLine(0, "Dexter Industries"); nxtDisplayCenteredTextLine(1, "Thermal Infrared"); while (true) { // Read the currently detected ambient and object temp from the sensor sensorReadAll(&tir); nxtDisplayTextLine(3, "A: %3.2f", tir.ambientTemp); nxtDisplayTextLine(4, "O: %3.2f", tir.objectTemp); wait1Msec(100); } }
You must be on Holiday or something to undertake this task.
The “Local variables will be removed or a least kept to a minimum”, will hopefully help the Global Variable issues that I haven’t been able to get around with the NXT2WiFi Module.
Please let me know when you need some testing done.
All sounds great Xander.
It’ll be slow going to get this implemented, so no holidays. I will publish a git branch for all to play with once I have made some more progress.
Is there an ETA for this? Will it be ready for next FTC season (Sept 7)?
I hope so, but ROBOTC 4.x needs to be available first, at least as a preview, so I can make sure it works on that 🙂
Now that we know that RobotC 4 won’t be the primary release for this FTC season (see my comment on the RobotC 4 announcement post), are you still going to wait on it? If not, do you think you’ll be able to get the driver suite ready for the FTC season?
I am not sure I will have time to make all the changes, as the EV3 is taking up quite a bit of my time. I am working together with John Hansen to create a C-API, to allow you to access the hardware without the LEGO VM. It will also allow other programming languages to access the hardware.
[…] so badly that it will take a lot of work to get it up and running. However, I did mention in a previous post that I am also working on a massive rewrite of the suite to make it more struct-oriented. This is […]
I currently have ROBOTC 4.x, I have tried to use the ROBOTC Driver Suite 3.3.1 and it kept on saying it has a compiling error saying **Severe*:Couldn’t open ‘#include’ file ‘drivers/hitechnic-irseeker-v2.h’
I have checked the steps and I have put the directories in the correct place and I have checked to allow custom designed sensors.
Do you guys have any advice to what might be the issue? Is it because 3.x Driver Suite is not compatible with 4.x ROBOTC?
Thank you.
You should download the zip from here: https://github.com/botbench/robotcdriversuite. Follow the instructions on that page and you should be up and running in no time.
= Xander