Updated all makefiles. You may need to update the port settings to get your project to program the robots again.
Tested rangefinders to see if they are #define'd correctly. See data/rangefinder for details.
fixes #570 avrdude port detection
Made some small changes reading through the code, no mex file compiler at home so I might have broken it.. but probably not.
Added mapping data.
Put latest input.txt in matlab directory.
Smart run around FSM + mapping works!!! I don't know what I did.
Run around now uses R4 and R5.
Replaced old orb_enable() with new orb_init().
Sorry for uploading such a big file, hopefully I removed this before it was on too many computers.
Changes to the sensor modeling code. (Mostly from a better understanding of imtransform).
Fixes to the sensor mapping code. Works now! (Sort of)
Movie. Wanted to have it here for transfer to my computer.
Changed smart run-around from old version to new version, which seems kind of silly, since the rangefinder functions didn't actually change.
Smart run around produces more of a wall-following behavior at this point. Rangefinder readings are clearly not in cm. I have assumed that theygive the distance in mm but 50 mm too large. I don't think this is correct, but the robot does not crash, so I left. The states do what they are ...
Created new directory for development of new smart run around. Although thismakes no sense WRT the structure of the repository, it will allow autonomousmapping to continue to function during the development of the new smart runaround while still keeping the new smart run around conveniently close to...
Replace smart_run_around_fsm.c with the one that simulator has been using, which apparently uses the new rangefinder interface.
Some changes to match the updated library.
Added some papers guiding the current approach, and commented some.
Modified sensor_map to use 'model_sensor' to plug in a sensor model to map with. Model sensor is meant to be an array of sensor models, one for distances from 10cm to 70cm.
Committing some test files, as well as an updated version of the sensor mapping code.
Added a heavily modified version of map.m called sensor_map, which first constructs a sensor model, then maps data according to the sensor model. NEEDS to be converted to log-odds to speed up computation. There is still a transformation that needs to take place per datapoint per sensor, but ...
Put smart run around FSM in autonomous mapping programRobot goes into BACKWARDS mode a few seconds after starting up and apparently cannot be diverted
made packet group and packet type for odometry packets separate #defines
got rid of old stuff for driving from the computer
Cleaned up the code, someone help figure out the memory error!
First attempt at a probability density mapper. Unifinished.
Changed the robot dir to drive and added a dir to work on autonomous mapping
Small modifications to receive.c, corrected an errorin the ring buffer. Some commenting and cleaning.
Having trouble with wireless (I think) hopefully this will work by friday.
tested a bunch of different environments for mapping
Switched wl_init and wl_set_com_port in test.c (again?)
Changes all around. Matlab server is now passive, might work soon.
Added the data files for real this time
Ran some tests in different environments. Data is in 1, 2, 3.txt
calls to wl_init() and wl_set_com_port() were inverted
test takes an argument for the USB port #, but it doesn't commit a memory error like it did last time I committed
test now takes a second argument for the USB port number
sorry...didn't mean to commit odometry.c
minor changes to remote control / mapping code...wireless control works with libwireless reverted to rev. 887. code in odometry interrupt conflicts with motors, not allowing the robot to move motors in response to commands.
Wrote some code to test wireless communication between the computer andthe robot. Right now, it doesn't work.
Small changes - new file just waits for packets to bufferfor matlab, so the robots will decide when to send theirdata in this version.
Cleaned up test.c and robot_main.c in mapping.
Minor modifications and fixes. Haven't gotten it to work yet.
Small changes and comments.
Changed receive to work when there's no data,haven't tested for when there is,test.c works as expected,Makefile modified to work on receive.c on a linux machine with matlab.testing robots pending - not hopeful - see code.
Slight corrections to this file. I have no wayof testing without a computer with matlab/linux.
If anyone knows windows threading I'd be much obliged. Alternatively, if anyone knows if thereis an accessible build of gcc higher then version 4 on andrew unix let me know.
Just some test code to see how concurrency works in matlab functions.
Added some test code for the receive function - does not work asI can't get the token ring to start up. receive.c needs to be ona matlab computer to be compiled and run correctly (mex receive.c -lpthread)
Wrote mex file code to interface between matlab and the wireless library.
Added a odometry_velocity function that gives approximate speed of the robot in mm/s.
Added symbolic links to the odometry in mapping to the library, and provided documentation.
Odometry works!!
untested realtime ir plotting
Realtime position plotting
A working server, with debug printing, some mapping capabilitiesPartly for testing
sample maps created by pushing the robot around a table (3 or 4 walls)
Nothing was fixed nothing changed.
updated server-side mapping code (remote control, etc)
added odometry to robot mapping code via symlinks to justin's odometry code
Odometry committed. New version is more general, but still drifts to zero.
cleaning up robot code for mapping
Odometry will temporarily not work. Working code commented out. This commit is so the blight on the world that is colony math.h will be eradicated for all time.
added model, whoops
python stuff
driving code interprets odometry data correctly, uses non-blocking key listener and can receive packets continually
added ideas on multi-robot behaviorwill turn into actual code eventually
updated robot and server code to use odometry. having problems with theta because it is a double (4 bytes on robot, 8 bytes on server)
Odometry works but the precision is awful. Angles are measured fairly accurately, but distance readings are consistently lower then expected.
Robot sends updates 50 times per second. Robot remote control program doesn't mess up terminal upon exit.
fixed output filename and unsigned data
Realized local encoders file was still in the repository.
Quick update before I do something stupid.
remote control of robot and data output for matlab
Code that converts data from the robot into a plot
Compiles now. This code worked a while ago but I haven't touched it since early last semester.The idea was to do exactly what Abe is doing now... so it might be useful.
python thingy
added remote control to robot code that sends mapping data
Wireless output works.
robot_main.c sends the raw sensor data for mapping points to USB. Commented out is untested code to send it over wireless and utilize the (deprecated?) odometry functions.
Some changes.
Changed some odometry stuff. Interrupt is called now.Still some problem that is not updating x and y data.
Forgot to add these files to the repository.
odometry compiles - timer issues, interrupt never called.
Small modifications to odometry. I'm all but committed to using floating point.
Cleaning up, trying to be safe.
Minor changes (maybe).
More work on odometry code. (Really want to use floats but am avoiding temptation for now.)
Wrote some odometry code. I had the timers the way I wanted them a couple of days ago, but then subversion ate up my code. I have the right interrupt vector now though...
Maybe all of this nonsense will go away now?